This pull request covers the major oopsing issues with OMAP, caused by
the lack of the TWL driver. Even when the TWL driver is not built in,
we shouldn't oops.
* 'omap-fixes-urgent' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: fix broken twl-core dependencies and ifdefs
ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found
Some code - especially the crypto layer - wants to use the x86
FP/MMX/AVX register set in what may be interrupt (typically softirq)
context.
That *can* be ok, but the tests for when it was ok were somewhat
suspect. We cannot touch the thread-specific status bits either, so
we'd better check that we're not going to try to save FP state or
anything like that.
Now, it may be that the TS bit is always cleared *before* we set the
USEDFPU bit (and only set when we had already cleared the USEDFP
before), so the TS bit test may actually have been sufficient, but it
certainly was not obviously so.
So this explicitly verifies that we will not touch the TS_USEDFPU bit,
and adds a few related sanity-checks. Because it seems that somehow
AES-NI is corrupting user FP state. The cause is not clear, and this
patch doesn't fix it, but while debugging it I really wanted the code to
be more obviously correct and robust.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It was marked asmlinkage for some really old and stale legacy reasons.
Fix that and the equally stale comment.
Noticed when debugging the irq_fpu_usable() bugs.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Conflicts:
sound/pci/hda/patch_realtek.c
Merged back the fix for Acer Aspire 6935 with ALC889 codec.
The fix commit was based on 3.2 kernel so that it can be applied to
stable kernel cleanly.
Since 3.2 kernel, the driver starts trying to assign the multi-io DACs
before the speaker, thus it assigns DAC2/3 for multi-io and DAC4 for
the speaker for a standard laptop setup like a HP, a speaker, a mic-in
and a line-in. However, on Acer Aspire 6935, it seems that the
speaker pin 0x14 must be connected with either DAC1 or 2; otherwise it
results in silence by some reason, although the codec itself allows
the routing to DAC3/4.
As a workaround, the connection list of each pin is reduced to be
mapped to either only DAC1/2 or DAC3/4, so that the compatible
assignment as in kernel 3.1 is achieved.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42740
Cc: <stable@kernel.org> [v3.2+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
VT1705 codec has two ADCs where the secondary ADC has no MUX but only
a fixed connection to the mic pin. This confused the driver and it
tries always overriding the input-source selection by assumption of
the existing MUX for the secondary ADC, resulted in resetting the
input-source at each time PM (including power-saving) occurs.
The fix is simply to check the existence of MUX for secondary ADCs in
the initialization code.
Tested-by: Anisse Astier <anisse@astier.eu>
Cc: <stable@kernel.org> [v3.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: drivers/mfd/built-in.o(.devinit.text+0x258): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
The function __devinit twl_probe() references
a function __init twl4030_power_init().
If twl4030_power_init is only used by twl_probe then
annotate twl4030_power_init with a matching annotation.
twl4030_power_init() references other __init marked functions, so
these too must become __devinit.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On my OMAP4 platform, I'm getting this error message repeated several
times at boot:
omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.
This doesn't help identify what the problem is. Fix this message to
be more informative:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
This allows us to identify which voltage domains have a problem, and
what the I2C configuration state (a boolean, i2c_high_speed) setting
being used actually is.
From this we find that omap4_core_pmic has i2c_high_speed false, but
omap4_iva_pmic and omap4_mpu_pmic both have it set true.
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While testing on my OMAP3430 platform, this error message was emitted:
omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Trying to find this message was difficult because it was wrapped across
several lines. It also mis-spells "required", doesn't read very well,
and has spaces lacking. Let's replace it with a more concise:
omap_vc_init_channel: No PMIC info for vdd_core
While we're here, fix a simple spelling error in a comment.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When CONFIG_OF is disabled, the compile fails with:
arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Says Jens:
"Time to push off some of the pending items. I really wanted to wait
until we had the regression nailed, but alas it's not quite there yet.
But I'm very confident that it's "just" a missing expire on exit, so
fix from Tejun should be fairly trivial. I'm headed out for a week on
the slopes.
- Killing the barrier part of mtip32xx. It doesn't really support
barriers, and it doesn't need them (writes are fully ordered).
- A few fixes from Dan Carpenter, preventing overflows of integer
multiplication.
- A fixup for loop, fixing a previous commit that didn't quite solve
the partial read problem from Dave Young.
- A bio integer overflow fix from Kent Overstreet.
- Improvement/fix of the door "keep locked" part of the cdrom shared
code from Paolo Benzini.
- A few cfq fixes from Shaohua Li.
- A fix for bsg sysfs warning when removing a file it did not create
from Stanislaw Gruszka.
- Two fixes for floppy from Vivek, preventing a crash.
- A few block core fixes from Tejun. One killing the over-optimized
ioc exit path, cleaning that up nicely. Two others fixing an oops
on elevator switch, due to calling into the scheduler merge check
code without holding the queue lock."
* 'for-linus' of git://git.kernel.dk/linux-block:
block: fix lockdep warning on io_context release put_io_context()
relay: prevent integer overflow in relay_open()
loop: zero fill bio instead of return -EIO for partial read
bio: don't overflow in bio_get_nr_vecs()
floppy: Fix a crash during rmmod
floppy: Cleanup disk->queue before caling put_disk() if add_disk() was never called
cdrom: move shared static to cdrom_device_info
bsg: fix sysfs link remove warning
block: don't call elevator callbacks for plug merges
block: separate out blk_rq_merge_ok() and blk_try_merge() from elevator functions
mtip32xx: removed the irrelevant argument of mtip_hw_submit_io() and the unused member of struct driver_data
block: strip out locking optimization in put_io_context()
cdrom: use copy_to_user() without the underscores
block: fix ioc locking warning
block: fix NULL icq_cache reference
block,cfq: change code order
11a3122f6c "block: strip out locking optimization in put_io_context()"
removed ioc_lock depth lockdep annoation along with locking
optimization; however, while recursing from put_io_context() is no
longer possible, ioc_release_fn() may still end up putting the last
reference of another ioc through elevator, which wlil grab ioc->lock
triggering spurious (as the ioc is always different one) A-A deadlock
warning.
As this can only happen one time from ioc_release_fn(), using non-zero
subclass from ioc_release_fn() is enough. Use subclass 1.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Quoth David:
1) GRO MAC header comparisons were ethernet specific, breaking other
link types. This required a multi-faceted fix to cure the originally
noted case (Infiniband), because IPoIB was lying about it's actual
hard header length. Thanks to Eric Dumazet, Roland Dreier, and
others.
2) Fix build failure when INET_UDP_DIAG is built in and ipv6 is modular.
From Anisse Astier.
3) Off by ones and other bug fixes in netprio_cgroup from Neil Horman.
4) ipv4 TCP reset generation needs to respect any network interface
binding from the socket, otherwise route lookups might give a
different result than all the other segments received. From Shawn
Lu.
5) Fix unintended regression in ipv4 proxy ARP responses, from Thomas
Graf.
6) Fix SKB under-allocation bug in sh_eth, from Yoshihiro Shimoda.
7) Revert skge PCI mapping changes that are causing crashes for some
folks, from Stephen Hemminger.
8) IPV4 route lookups fill in the wildcarded fields of the given flow
lookup key passed in, which is fine most of the time as this is
exactly what the caller's want. However there are a few cases that
want to retain the original flow key values afterwards, so handle
those cases properly. Fix from Julian Anastasov.
9) IGB/IXGBE VF lookup bug fixes from Greg Rose.
10) Properly null terminate filename passed to ethtool flash device
method, from Ben Hutchings.
11) S3 resume fix in via-velocity from David Lv.
12) Fix double SKB free during xmit failure in CAIF, from Dmitry
Tarnyagin.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (72 commits)
net: Don't proxy arp respond if iif == rt->dst.dev if private VLAN is disabled
ipv4: Fix wrong order of ip_rt_get_source() and update iph->daddr.
netprio_cgroup: fix wrong memory access when NETPRIO_CGROUP=m
netprio_cgroup: don't allocate prio table when a device is registered
netprio_cgroup: fix an off-by-one bug
bna: fix error handling of bnad_get_flash_partition_by_offset()
isdn: type bug in isdn_net_header()
net: Make qdisc_skb_cb upper size bound explicit.
ixgbe: ethtool: stats user buffer overrun
ixgbe: dcb: up2tc mapping lost on disable/enable CEE DCB state
ixgbe: do not update real num queues when netdev is going away
ixgbe: Fix broken dependency on MAX_SKB_FRAGS being related to page size
ixgbe: Fix case of Tx Hang in PF with 32 VFs
ixgbe: fix vf lookup
igb: fix vf lookup
e1000: add dropped DMA receive enable back in for WoL
gro: more generic L2 header check
IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses
zd1211rw: firmware needs duration_id set to zero for non-pspoll frames
net: enable TC35815 for MIPS again
...
Commit 653241 (net: RFC3069, private VLAN proxy arp support) changed
the behavior of arp proxy to send arp replies back out on the interface
the request came in even if the private VLAN feature is disabled.
Previously we checked rt->dst.dev != skb->dev for in scenarios, when
proxy arp is enabled on for the netdevice and also when individual proxy
neighbour entries have been added.
This patch adds the check back for the pneigh_lookup() scenario.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fix a bug which introduced by commit ac8a4810 (ipv4: Save
nexthop address of LSRR/SSRR option to IPCB.).In that patch, we saved
the nexthop of SRR in ip_option->nexthop and update iph->daddr until
we get to ip_forward_options(), but we need to update it before
ip_rt_get_source(), otherwise we may get a wrong src.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the netprio_cgroup module is not loaded, net_prio_subsys_id
is -1, and so sock_update_prioidx() accesses cgroup_subsys array
with negative index subsys[-1].
Make the code resembles cls_cgroup code, which is bug free.
Origionally-authored-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
So we delay the allocation till the priority is set through cgroup,
and this makes skb_update_priority() faster when it's not set.
This also eliminates an off-by-one bug similar with the one fixed
in the previous patch.
Origionally-authored-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
# mount -t cgroup xxx /mnt
# mkdir /mnt/tmp
# cat /mnt/tmp/net_prio.ifpriomap
lo 0
eth0 0
virbr0 0
# echo 'lo 999' > /mnt/tmp/net_prio.ifpriomap
# cat /mnt/tmp/net_prio.ifpriomap
lo 999
eth0 0
virbr0 4101267344
We got weired output, because we exceeded the boundary of the array.
We may even crash the kernel..
Origionally-authored-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stop reusing dquots from the freelist when allocating new ones directly, and
implement a shrinker that actually follows the specifications for the
interface. The shrinker implementation is still highly suboptimal at this
point, but we can gradually work on it.
This also fixes an bug in the previous lock ordering, where we would take
the hash and dqlist locks inside of the freelist lock against the normal
lock ordering. This is only solvable by introducing the dispose list,
and thus not when using direct reclaim of unused dquots for new allocations.
As a side-effect the quota upper bound and used to free ratio values in
/proc/fs/xfs/xqm are set to 0 as these values don't make any sense in the
new world order.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/radeon: do not continue after error from r600_ib_test
drivers/gpu/drm/drm_ioc32.c: initialize all fields
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix double start/stop in x86_pmu_start()
perf evsel: Fix an issue where perf report fails to show the proper percentage
perf tools: Fix prefix matching for kernel maps
perf tools: Fix perf stack to non executable on x86_64
perf: Remove deprecated WARN_ON_ONCE()
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
"subbuf_size" and "n_subbufs" come from the user and they need to be
capped to prevent an integer overflow.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80KZgACgkQMUfUDdst+yk0HgCeIdU3VTWqdxZDXp3G1sFIXZ1b
47YAnRAMAar+/aLaNhqGrcz7aa5y2cUU
=8sr8
-----END PGP SIGNATURE-----
Merge tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Serial/TTY fixes for the 3.3-rc3 tree
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
m32r: relocate drivers back out of 8250 dir
tty: fix a build failure on sparc
serial: samsung: Add support for EXYNOS5250
serial: samsung: Add support for EXYNOS4212 and EXYNOS4412
drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer
Big things here is the deletion of the Android pmem driver, as it's
obsolete and no one uses it, the gma500 driver as it's already in the
drm portion of the kernel tree, and the pohmelfs filesystem as it's
obsolete and a rewritten version is being proposed for the fs/ section
of the kernel.
Other than that, a smattering of different bugfixes and regressions, and
some omap drm api merge fixups that were needed due to api changes in
the main portion of the drm tree, allowing this code to build properly
again.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80KLYACgkQMUfUDdst+ykhiwCg2ctSu4umygA1ErAedAA+sJkv
psYAn20OZQDyuBcBAIzL2L+Y/BUz8bXt
=xvyx
-----END PGP SIGNATURE-----
Merge tag 'staging-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Staging tree patches for 3.3-rc3
Big things here is the deletion of the Android pmem driver, as it's
obsolete and no one uses it, the gma500 driver as it's already in the
drm portion of the kernel tree, and the pohmelfs filesystem as it's
obsolete and a rewritten version is being proposed for the fs/ section
of the kernel.
Other than that, a smattering of different bugfixes and regressions, and
some omap drm api merge fixups that were needed due to api changes in
the main portion of the drm tree, allowing this code to build properly
again.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'staging-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (28 commits)
staging: pohmelfs: remove drivers/staging/pohmelfs
staging: android/ram_console: Don't build on arches w/o ioremap
staging: r8712u: Use asynchronous firmware loading
staging: usbip: fix to prevent potentially using uninitialized spinlock
staging: r8712u: Fix problem when CONFIG_R8712_AP is set
staging: tidspbridge: fix incorrect free to drv_datap
staging: tidspbridge: fix bridge_open memory leaks
staging: android: lowmemorykiller: Don't wait more than one second for a process to die
MAINTAINERS: staging: iio: add iio information
staging: zcache: fix serialization bug in zv stats
staging: fix go7007-usb license
Staging: android: binder: Fix crashes when sharing a binder file between processes
Staging: android: Remove pmem driver
Staging: asus_oled: fix NULL-ptr crash on unloading
Staging: asus_oled: fix image processing
Staging: android: binder: Don't call dump_stack in binder_vma_open
staging: r8712u: Add new Sitecom UsB ID
zcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.
zcache: fix deadlock condition
staging: drm/omap: fix locking issue
...
A few fixes for kobject warnings that have popped up in the cpu hotplug path,
and a regression fix for the speed of the hotplug memory code.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80J1cACgkQMUfUDdst+ylYfgCcClIeUw4njh3Tup9BpRrdBprr
fBsAoLKKhaZDsnma85PJRDAvtM2guoi7
=0TZ9
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Driver core fixes for the 3.3-rc3 tree.
A few fixes for kobject warnings that have popped up in the cpu hotplug path,
and a regression fix for the speed of the hotplug memory code.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'driver-core-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
driver-core: cpu: fix kobject warning when hotplugging a cpu
ACPI: remove duplicated lines of merging problems with acpi_processor_add
docbook: fix fatal errors in device-drivers docbook and add DMA Management section
drivers/base/memory.c: fix memory_dev_init() long delay
driver core: cpu: remove kernel warning when removing a cpu
Nothing big here, some Kconfig fixes for the MISC_DEVICES config option
that was being used incorrectly, and some other minor bug fixes.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80HSAACgkQMUfUDdst+ymFsQCghwKbV9B9z5fgUXYwFQJ/pD2j
GhsAn3J2mhhHN/vtSPQAN9Vu59Xb/tCi
=VZaE
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Minor char-misc fixes for 3.3-rc3
Nothing big here, some Kconfig fixes for the MISC_DEVICES config option
that was being used incorrectly, and some other minor bug fixes.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'char-misc-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip
cs5535-mfgpt: don't call __init function from __devinit
vmw_balloon: fix for a -Wuninitialized warning
drivers: misc: Remove MISC_DEVICES config option
c2port: fix build error for duramar2150 due to missing header.
Here are a few minor USB fixes and a bunch of device id updates for the
USB drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80Ki4ACgkQMUfUDdst+ymp3wCfUG2LtQOC2qpzpnl1bcivSA18
11gAn09DbcldfH4k12HyCr7PuBnjILQh
=vfEv
-----END PGP SIGNATURE-----
Merge tag 'usb-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
USB fixes for 3.3-rc3
Here are a few minor USB fixes and a bunch of device id updates for the
USB drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'usb-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: usbserial: add new PID number (0xa951) to the ftdi driver
usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
usb: musb: fix a build error on mips
uwb & wusb & usb wireless controllers: fix kconfig error & build errors
usb: Skip PCI USB quirk handling for Netlogic XLP
powerpc/usb: fix issue of CPU halt when missing USB PHY clock
usb: otg: mv_otg: Add dependence
usb: host: Distinguish Kconfig text for Freescale controllers
USB: add new zte 3g-dongle's pid to option.c
usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
USB: qcserial: don't enable autosuspend
USB: qcserial: add several new serial devices
usb: otg: mv_otg: Add dependence
usb: gadget: zero: fix bug in loopback autoresume handling
The current error handling doesn't work because we flash_part is a u32
so the checks for negative error codes don't work. I considered making
things signed but I don't know the hardware enough to say if that's a
problem. Really, we don't use the error codes so just returning zero
for all problems is fine.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We use len to store the return value from eth_header(). eth_header()
can return -ETH_HLEN (-14). We want to pass this back instead of
truncating it to 65522 and returning that.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Treat pwmX as a measured value, not as a (mostly static) limit value, so
that it is updated more frequently from the device register.
Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Just like skb->cb[], so that qdisc_skb_cb can be encapsulated inside
of other data structures.
This is intended to be used by IPoIB so that it can remember
addressing information stored at hard_header_ops->create() time that
it can fetch when the packet gets to the transmit routine.
Signed-off-by: David S. Miller <davem@davemloft.net>
The receive FIFO wakeup latency estimate in the omap-serial driver is
three orders of magnitude too small. This effectively prevents the
MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a
major power management regression and masks some other FIFO-related
bugs in the driver.
Fix by correcting the most egregious problem in the RX wakeup latency
estimate. There are several other flaws in the estimator; these will
be fixed by a separate patch series intended for 3.4.
The difference in low-power states with this patch can be observed via
debugfs in pm_debug/count.
This estimate does not have any effect when CONFIG_CPU_IDLE=n.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode. This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached. This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode. The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.
This fix changes the erratum i291 DMA idle workaround. Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle. The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.
This fix should work on all OMAP UARTs. Future patches intended for
the 3.4 merge window will make this workaround conditional on a
"feature" flag, and will use the OMAP36xx+ TX event wakeup support.
Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the (default) PIO mode, use a one-byte RX FIFO threshold. The OMAP
UART IP blocks do not appear to be capable of waking the system under
an RX timeout condition. Since the previous RX FIFO threshold was 16
bytes, this meant that omap-serial.c did not become aware of any
received data until all those bytes arrived or until another UART
interrupt occurred. This made the serial console and presumably other
serial applications (GPS, serial Bluetooth) unusable or extremely
slow. A 1-byte RX FIFO threshold also allows the MPU to enter a
low-power consumption state while waiting for the FIFO to fill.
This can be verified using the serial console by comparing the
behavior when "0123456789abcde" is pasted in from another window, with
the behavior when "0123456789abcdef" is pasted in. Since the former
string is less than sixteen bytes long, the string is not echoed for
some time, while the latter string is echoed immediately.
DMA operation is unaffected by this patch.
Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_parse_integer() does one or two division instructions (which are slow)
per digit parsed to perform the overflow check.
Furthermore, these are particularly expensive examples of division
instruction as the number of clock cycles required to complete them may
go up with the position of the most significant set bit in the dividend:
if (*res > div_u64(ULLONG_MAX - val, base))
which is as maximal as possible.
Worse, on 32-bit arches, more than one of these division instructions
may be required per digit.
So, assuming we don't support a base of more than 16, skip the check if the
top nibble of the result is not set at this point.
Signed-off-by: David Howells <dhowells@redhat.com>
[ Changed it to not dereference the pointer all the time - even if the
compiler can and does optimize it away, the code just looks cleaner.
And edited the top nybble test slightly to make the code generated on
x86-64 better in the loop - test against a hoisted constant instead of
shifting and testing the result ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit aeb5032b3f, a dependency on IRQ_DOMAIN was added, which causes
regressions on previously working setups: a previously working non-DT
kernel configuration now loses its PMIC support. The lack of PMIC
support in turn causes the loss of other functionality the kernel had.
This dependency was added because the driver now registers its
interrupts with the IRQ domain code, presumably to prevent a build error.
The result is that OMAP3 oopses in the vp.c code (fixed by a previous
commit) due to the lack of PMIC support.
However, even with IRQ_DOMAIN enabled, the driver oopses:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 1 Not tainted (3.3.0-rc2+ #271)
PC is at irq_domain_add+0x1c/0x134
LR is at twl_probe+0xd0/0x370
pc : [<c007bad0>] lr : [<c029baac>] psr: 00000113
sp : df843c48 ip : df843c68 fp : df843c64
r10: c02b93e4 r9 : 00000000 r8 : c029b9dc
r7 : df9d8a00 r6 : c03bef90 r5 : 00000000 r4 : c03f5240
r3 : 00000000 r2 : c03f5240 r1 : 00000015 r0 : c03f5240
Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8000404a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xdf8422f0)
Stack: (0xdf843c48 to 0xdf844000)
3c40: 00000014 00000170 00000014 c03bef90 df843c9c df843c68
3c60: c029baac c007bac0 00000000 df9d8a20 00000001 c03cd238 c02b93e4 df9d8a20
3c80: df9d8a04 df9d8a00 c029b9dc df8cae08 df843cc4 df843ca0 c01eee70 c029b9e8
...
Backtrace:
[<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
r6:c03bef90 r5:00000014 r4:00000170
[<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4)
[<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x178)
r8:df8f0070 r7:c03cd238 r6:df9d8a20 r5:df9d8a20 r4:df9d8a20
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
r7:df843d18 r6:df9d8a20 r5:c03cd238 r4:df9d8a20
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d2148>] (__device_attach+0x44/0x48)
r5:df9d8a20 r4:c03cd238
[<c01d2104>] (__device_attach+0x0/0x48) from [<c01d0840>] (bus_for_each_drv+0x58/0x98)
r5:c01d2104 r4:00000000
[<c01d07e8>] (bus_for_each_drv+0x0/0x98) from [<c01d21f8>] (device_attach+0x80/0xac)
r7:df9d8a28 r6:df9d8a54 r5:c03cd978 r4:df9d8a20
[<c01d2178>] (device_attach+0x0/0xac) from [<c01d1430>] (bus_probe_device+0x34/0xa4)
r6:df9d8a20 r5:c03cd978 r4:df9d8a20
[<c01d13fc>] (bus_probe_device+0x0/0xa4) from [<c01cffb0>] (device_add+0x2a0/0x420)
r6:00000000 r5:df9d8a20 r4:df9d8a20
[<c01cfd10>] (device_add+0x0/0x420) from [<c01d0150>] (device_register+0x20/0x24)
r8:df9d8a00 r7:df9d8a04 r6:df8f0048 r5:df9d8a00 r4:df9d8a20
[<c01d0130>] (device_register+0x0/0x24) from [<c01ef8d4>] (i2c_new_device+0x118/0x180)
r4:df9d8a20
[<c01ef7bc>] (i2c_new_device+0x0/0x180) from [<c01efc88>] (i2c_register_adapter+0x140/0x204)
r8:c03cd970 r7:00000000 r6:df8f0070 r5:df8a6300 r4:df8f0048
[<c01efb48>] (i2c_register_adapter+0x0/0x204) from [<c01efe9c>] (i2c_add_numbered_adapter+0xb4/0xcc)
r8:df8a4c54 r7:df8cae00 r6:df843e2c r5:df8f0048 r4:00000000
[<c01efde8>] (i2c_add_numbered_adapter+0x0/0xcc) from [<c029ce1c>] (omap_i2c_probe+0x2f8/0x3b4)
r6:00000000 r5:df8f0000 r4:df8f0070
[<c029cb24>] (omap_i2c_probe+0x0/0x3b4) from [<c01d3484>] (platform_drv_probe+0x20/0x24)
[<c01d3464>] (platform_drv_probe+0x0/0x24) from [<c01d1f34>] (really_probe+0xa0/0x178)
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
r7:df843ef0 r6:c03cdb2c r5:c03cdb2c r4:df8cae08
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d20e0>] (__driver_attach+0x6c/0x90)
r5:df8cae3c r4:df8cae08
[<c01d2074>] (__driver_attach+0x0/0x90) from [<c01d08d8>] (bus_for_each_dev+0x58/0x98)
r6:c03cdb2c r5:c01d2074 r4:00000000
[<c01d0880>] (bus_for_each_dev+0x0/0x98) from [<c01d1d80>] (driver_attach+0x20/0x28)
r7:df880b80 r6:c03cdb2c r5:c03cdb2c r4:c0394f28
[<c01d1d60>] (driver_attach+0x0/0x28) from [<c01d115c>] (bus_add_driver+0xb4/0x230)
[<c01d10a8>] (bus_add_driver+0x0/0x230) from [<c01d278c>] (driver_register+0xc8/0x154)
[<c01d26c4>] (driver_register+0x0/0x154) from [<c01d37e4>] (platform_driver_register+0x4c/0x60)
r8:00000000 r7:00000013 r6:c00384c8 r5:c0395180 r4:c0394f28
[<c01d3798>] (platform_driver_register+0x0/0x60) from [<c038626c>] (omap_i2c_init_driver+0x14/0x1c)
[<c0386258>] (omap_i2c_init_driver+0x0/0x1c) from [<c00087b8>] (do_one_initcall+0x9c/0x164)
[<c000871c>] (do_one_initcall+0x0/0x164) from [<c036c2f4>] (kernel_init+0x90/0x138)
[<c036c264>] (kernel_init+0x0/0x138) from [<c00384c8>] (do_exit+0x0/0x2ec)
r5:c036c264 r4:00000000
<0>Code: e24dd004 e5903014 e1a04000 e5905010 (e5933000)
<4>---[ end trace 1b75b31a2719ed1c ]---
This happens because we try to register an IRQ domain with a NULL ops
structure, and the first thing irq_domain_add() does is try to
dereference this ops structure.
So, fix the problem by getting rid of the incorrect OF_IRQ ifdef and
wrapping the IRQ domain bits of the driver with an IRQ_DOMAIN ifdef
instead.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linus Torvalds