1) Some little fixes for the ad5064 dac driver.
2) A build warning 'fix' for a false positive in st_sensors
3) A couple of missing dependencies on IIO_BUFFER.
So nothing major and these mostly showed the advantages of the randconfig
builds various people have performed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRNjamAAoJEFSFNJnE9BaIUwMP/jed+bdUW1fYtGjv6vRmG9fj
XQK7pMIrk5STiE8UJAMf4vavtXA8lSKK32cAVeUaOXh2huxIXXG+6X/fIu0pfQ+F
CZNtnl41WVfp0sYA7Pw+on9bXMv8HajJKlbzbe9sBKKyqkpO3EvUZpWyKEBt5cQi
HMa6gmrditBzkjSXabDH/7lrQE0kN4jSFZUAdRYCVt5oxTs+OzdjH4sUjfwX4/Pg
YzdZKnqdqftuV/o7Mf1B0D7/7bc15KhNA+QAdBf7tuncvCmGFm2hdLf6DHAdHXsQ
D0ZcVo5Txg+Md4J3ZOvy45pO667l9KSETLXQq2cBMRMZt0ARCOyxGjxxmYpqUxKO
r369/tkL/LAV1BOvWZmK9j5W2KOwXtYSigtjZbVPjnYPYCPOlVwgxPZj7J9N8vb/
nM08QAV6oj9R9UZ4K06K4BoV4W4VD3xaHSTJyxMujlr7R7Eh9aUNH+xsbvkXEDnt
A8e/n2CLqBjl9M0uTydG5eX9aDzq21ykz/xF1qnz2BsB53zaxizexw2ywXIdAQvD
waFBUORnUBSZor4cUbO63njhr02NXqA87M+0C3OE/Xvfmn5ygjnPMe1fjcGHeyf+
fcE7EPzG23ChMZzoNdTDgpjGddvqCTQ95JGUKR55AETt8hv5PpUeUd3B1d5s7tGZ
LuM8g3lZhYho+RVYkLC5
=hA1D
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.9a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
"First round of iio fixes post the 3.9 merge window.
1) Some little fixes for the ad5064 dac driver.
2) A build warning 'fix' for a false positive in st_sensors
3) A couple of missing dependencies on IIO_BUFFER.
So nothing major and these mostly showed the advantages of the randconfig
builds various people have performed."
From the docs:
"IIR can queue up to two interrupt events. When the IIR is cleared,
it will set itself again after one clock if a second event was
stored."
"Only the rising edge of the PCH Display interrupt will cause the
North Display IIR (DEIIR) PCH Display Interrupt even bit to be set,
so all PCH Display Interrupts, including back to back interrupts,
must be cleared before a new PCH Display interrupt can cause DEIIR
to be set".
The current code works fine because we don't get many interrupts, but
if we enable the PCH FIFO underrun interrupts we'll start getting so
many interrupts that at some point new PCH interrupts won't cause
DEIIR to be set.
The initial implementation I tried was to turn the code that checks
SDEIIR into a loop, but we can still get interrupts even after the
loop is done (and before the irq handler finishes), so we have to
either disable the interrupts or mask them. In the end I concluded
that just disabling the PCH interrupts is enough, you don't even need
the loop, so this is what this patch implements. I've tested it and it
passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce:
the "ironlake_crtc_disable" case and the "wrong watermarks" case.
In other words, here's how to reproduce the problem fixed by this
patch:
1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+)
2 - Boot the machine
3 - While booting we'll get tons of PCH FIFO underrun interrupts
4 - Plug a new monitor
5 - Run xrandr, notice it won't detect the new monitor
6 - Read SDEIIR and notice it's not 0 while DEIIR is 0
Q: Can't we just clear DEIIR before SDEIIR?
A: It doesn't work. SDEIIR has to be completely cleared (including the
interrupts stored on its back queue) before it can flip DEIIR's bit to
1 again, and even while you're clearing it you'll be getting more and
more interrupts.
Q: Why does it work by just disabling+enabling the south interrupts?
A: Because when we re-enable them, if there's something on the SDEIIR
register (maybe an interrupt stored on the queue), the re-enabling
will make DEIIR's bit flip to 1, and since we'll already have
interrupts enabled we'll get another interrupt, then run our irq
handler again to process the "back" interrupts.
v2: Even bigger commit message, added code comments.
Note that this fixes missed dp aux irqs which have been reported for
3.9-rc1. This regression has been introduced by switching to
irq-driven dp aux transactions with
commit 9ee32fea5f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 13:53:48 2012 +0100
drm/i915: irq-drive the dp aux communication
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html
References: https://lkml.org/lkml/2013/2/26/769
Tested-by: Imre Deak <imre.deak@intel.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp commit message with references for the dp aux irq
timeout regression this fixes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 24542bf7ea changed preallocation of
extents to cap the max size we try to allocate. It's a valid change,
but the extent reservation code is also used by balance, and that
can't tolerate a smaller extent being allocated.
__btrfs_prealloc_file_range already has a min_size parameter, which is
used by relocation to request a specific extent size. This commit
adds an extra check to enforce that minimum extent size.
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Reported-by: Stefan Behrens <sbehrens@giantdisaster.de>
Commit 51482be9 (ARM: OMAP: USB: Add phy binding information) forgot to
add phy binding for RX-51, and as a result USB does not work anymore on
3.9-rc1. Add the missing binding.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When a value of a vmaster slave control is changed, the ctl change
notification is sometimes ignored. This happens when the master
control overrides, e.g. when the corresponding master control is
muted. The reason is that slave_put() returns the value of the actual
slave put callback, and it doesn't reflect the virtual slave value
change.
This patch fixes the function just to return 1 whenever a slave value
is changed.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 10b63956 ("UAPI: Plumb the UAPI Kbuilds into the user header
installation and checking") introduced a dependency of make 3.81
due to use of $(or ...)
We do not want to lift the requirement to gmake 3.81 just yet...
Included are a straightforward conversion to $(if ...)
Bisected-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: <stable@vger.kernel.org> [v3.7+]
Signed-off-by: Michal Marek <mmarek@suse.cz>
Fix the following sparse warning:
drivers/usb/musb/omap2430.c:54:33: warning: symbol '_glue' was not \
declared. Should it be static?
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Commit 80ab72e1 (usb: musb: omap2430: fix the readiness check
in omap_musb_mailbox) made the check incorrect, as we will lose the
glue/link status during the normal built-in probe order (twl4030_usb is
probed after musb omap2430, but before musb core is ready).
As a result, if you boot with USB cable on and load g_ether, the
connection does not work as the code thinks the cable is off and the
phy gets powered down immediately. This is a major regression in 3.9-rc1.
So the proper check should be: exit if _glue is NULL, but if it's
initialized we memorize the status, and then check if the musb core
is ready.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When running 100 randconfig iterations, I found
the following warning:
drivers/usb/musb/musb_core.c: In function ‘musb_init_controller’:
drivers/usb/musb/musb_core.c:1981:1: warning: label ‘fail5’ defined \
but not used [-Wunused-label]
this patch fixes it by removing the unnecessary
ifdef CONFIG_SYSFS.
Signed-off-by: Felipe Balbi <balbi@ti.com>
those are quite unnecessary, the only thing
we need to be careful about is USB_OTG_UTILS
which get properly selected by PHY drivers.
For now, MUSB will select only USB_OTG_UTILS
until we add stubs for the cases when PHY
layer isn't enabled.
Signed-off-by: Felipe Balbi <balbi@ti.com>
A few trivial fixes for composite driver:
Warning(include/linux/usb/composite.h:165): No description found for parameter
'fs_descriptors'
Warning(include/linux/usb/composite.h:165): Excess struct/union/enum/typedef
member 'descriptors' description in 'usb_function'
Warning(include/linux/usb/composite.h:321): No description found for parameter
'gadget_driver'
Warning(drivers/usb/gadget/composite.c:1777): Excess function parameter 'bind'
description in 'usb_composite_probe'
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Kosina <trivial@kernel.org>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes a lockdep warning in igb_get_i2c_client by
refactoring the initialization and usage of the i2c_client
completely. There is no on the fly allocation of the single
client needed today.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
We need it to restore the ilk rc6 context, since the gpu wait no
requires interrupts. But in general having interrupts around should
help in code sanity, since more and more stuff is interrupt driven.
This regression has been introduced in
commit 3e9605018a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 27 16:22:54 2012 +0000
drm/i915: Rearrange code to only have a single method for waiting upon the ring
Like in the driver load code we need to make sure that hotplug
interrupts don't cause havoc with our modeset state, hence block them
with the existing infrastructure. Again we ignore races where we might
loose hotplug interrupts ...
Note that the driver load part of the regression has already been
fixed in
commit 52d7ecedac
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 21:03:22 2012 +0100
drm/i915: reorder setup sequence to have irqs for output setup
v2: Add a note to the commit message about which patch fixed the
driver load part of the regression. Stable kernels need to backport
both patches.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
Cc: stable@vger.kernel.org (for 3.8 only, plese backport
52d7ecedac first)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-and-Tested-by: Ilya Tumaykin <itumaykin@gmail.com>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch changes the setup copper link function to use a switch
statement for the PHY id's available for the given PHY types. It
also adds a case for the I210 PHY id, so the appropriate setup link
function is called for it.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
On s390 the igb driver was throwing a build error due to the fact that a frame
built using build_skb would be larger than 2K. Since this is not likely to
change at any point in the future we are better off just dropping the check
since we already had a check in igb_set_rx_buffer_len that will just disable
the usage of build_skb anyway.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some
reason this avoids the gen6_gt_check_fifodbg.isra warnings and
associated GPU lockups, which makes my ivy bridge machine stable.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At 1000Mbps link speed, one of the MAC's internal clocks can be stopped for
up to 4us when entering K1 (a power mode of the MAC-PHY interconnect). If
the MAC is waiting for completion indications for 2 DMA write requests into
Host memory (e.g. descriptor writeback or Rx packet writing) and the
indications occur while the clock is stopped, both indications will be
missed by the MAC causing the MAC to wait for the completion indications
and be unable to generate further DMA write requests. This results in an
apparent hardware hang.
Work-around the issue by disabling the de-assertion of the clock request
when 1000Mbps link is acquired (K1 must be disabled while doing this).
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
misc regression fixes from Ben.
* 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50-: prevent some races between modesetting and page flipping
drm/nouveau/i2c: drop parent refcount when creating ports
drm/nv84: fix regression in page flipping
drm/nouveau: Fix typo in init_idx_addr_latched().
drm/nouveau: Disable AGP on PowerPC again.
drm/nve0/graph: some random reg moved on kepler
We support DSCR (Data Stream Control Register) so we should make sure we set it
in the FSCR (Facility Status & Control Register) incase some firmwares don't
set it. If we don't set this, we'll take a facility unavailable exception when
using the DSCR.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This sets the DSCR (Data Stream Control Register) in the FSCR (Facility Status
& Control Register).
Also harmonise TAR (Target Address Register) FSCR bit definition too.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Currently we only set the FSCR (Facility Status and Control Register) when HV=1
but this feature is available when HV=0 also. This patch sets FSCR when HV=0.
Also, we currently only set the FSCR on the master CPU. This patch also sets
the FSCR on secondary CPUs.
Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Since kmp takes 2 unsigned long args there should be a compat wrapper.
Since one isn't provided I think it's safer just to hook this up to not
implemented. If we need it later we can do it properly then.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The BITOP_LE_SWIZZLE macro was used in the little-endian bitops functions
for powerpc. But these functions were converted to generic bitops and
the BITOP_LE_SWIZZLE is not used anymore.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Currently we use the link register to branch up high in the early MMU on
syscall entry path. Unfortunately, this trashes the link stack as the
address we are going to is not associated with the earlier mflr.
This patch simply converts us to used the count register (volatile over
syscalls anyway) instead. This is much better at predicting in this
scenario and doesn't trash link stack causing a bunch of additional
branch mispredicts later. Benchmarking this on POWER8 saves a bunch of
cycles on Anton's null syscall benchmark here:
http://ozlabs.org/~anton/junkcode/null_syscall.c
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
original implementation can not let hvcsd->p_location_code NUL terminated.
so need fix it (also can simplify the code)
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
the dest buf len is 80 (HVCS_CLC_LENGTH + 1).
the src buf len is PAGE_SIZE.
if src buf string len is more than 80, it will cause issue.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When building with CRYPTO_SHA1_PPC enabled we fail with:
powerpc/crypto/sha1-powerpc-asm.S: Assembler messages:
powerpc/crypto/sha1-powerpc-asm.S:116: Error: can't resolve `0' {*ABS* section} - `STACKFRAMESIZE' {*UND* section}
powerpc/crypto/sha1-powerpc-asm.S:116: Error: expression too complex
powerpc/crypto/sha1-powerpc-asm.S:178: Error: unsupported relocation against STACKFRAMESIZE
Use INT_FRAME_SIZE instead of STACKFRAMESIZE.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This register field is 11 bits wide, not 15 bits wide. Given the way
this value is currently, used, this patch has no practical effect.
However, it's still best if the value is correct.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
- A few sparse warning fixes
- Fix usb function regression caused by usb Kconfig option changes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJRNELIAAoJEFBXWFqHsHzOP/QH/jjE9MrvckPwb8h1I7R8a7yc
td3N5rikKiy2XN4snjIrPFaKi9JQ//I1oLvhsXNSD1uqWqqtRLg6lxzIdiheUJEd
NsAFLKTPMaJHJ/s3y0mLNRgyuBcyvDrF6jYJ8ncdGDCMAXBKifkTmrqqai2d0dZz
DiIiEW46PVhsQkoxdnLKw7xGScmXJpyqwshbi+zhAB17yE1FBLCCsZGD1jVr0v/y
Q6pnCjiJ8es9SAvmCvZ8cY1XxOxUMsCr2VhIy/QPF5HyuZPcRaV1nVGljfzo13J3
sPvBfmUZaY9ezqOVCUuYatQ3bAQ5f55KsLuGz+IHwMLHllXAML0Fw69/oDR86qs=
=JOus
-----END PGP SIGNATURE-----
Merge tag 'mxs-fixes-3.9' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
From Shawn Guo:
The mxs fixes for 3.9:
- A few sparse warning fixes
- Fix usb function regression caused by usb Kconfig option changes
* tag 'mxs-fixes-3.9' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: mxs: ocotp: Fix sparse warning
ARM: mxs: icoll: Fix sparse warning
ARM: mxs: mm: Fix sparse warning
ARM: mxs_defconfig: Make USB host functional again
Signed-off-by: Olof Johansson <olof@lixom.net>
- move early resume code out of .data section to fix allyesconfig
failure since c08e20d (arm: Add v7_invalidate_l1 to cache-v7.S)
gets merged
- Fix incorrect DISP1_DAT_21 number in imx53-mba53 disp1-grp1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJRND3rAAoJEFBXWFqHsHzOL2cH/je/02JztrorpD2k76mQLjo4
2hjfUwpYNvwEpwBCXo5NnDv5I4XrkJdHs7O2CHmigQOpDYSvq9qx3VcPQ0BX8cWU
3Qqb9tiglNsvD2NuxUYmG2CHFpGLp+lK3unkA/ZDXM2apjbacL1/wTgU81uthDwY
SLBBS7hSlBvuPdxoeIBeuOOBYnhbdaZCutgFVTF8rRT6RHmYjekga6OqF32Vp/og
Gxw50cj+smdW6wr1Na0zQJfMHTkm5hJ9s9iYHAbYNZplpl8VZJQAaCWgZhihZJYI
XULUCR0s8DLLUgj4IUgJS3Kc35G/2M1ovhxyw3hqDzOt+Miy8m4eYh21BL2iS8w=
=V76T
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-3.9' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
From Shawn Guo:
The imx fixes for 3.9:
- move early resume code out of .data section to fix allyesconfig
failure since c08e20d (arm: Add v7_invalidate_l1 to cache-v7.S)
gets merged
- Fix incorrect DISP1_DAT_21 number in imx53-mba53 disp1-grp1
* tag 'imx-fixes-3.9' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: dts: imx53-mba53: fix fsl,pins for disp1-grp1
ARM: mach-imx: move early resume code out of the .data section
Signed-off-by: Olof Johansson <olof@lixom.net>
Remove duplicate smp_twd clocks as these clocks are accessed using
DT now.
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
As DT support for clocks and smp_twd is enabled, add clock entry
for smp_twd clock to DT.
This fixes the following error while booting the kernel:
smp_twd: clock not found -2
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
[swarren: include kernel log spew that this fixes]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 5f300acd8a
(ARM: 7152/1: distclean: Remove generated .dtb files)
ensured that dtbs were cleaned up when they were in
arch/arm/boot.
However, with the following commit:
commit 499cd82986
(ARM: dt: change .dtb build rules to build in dts directory)
make clean now leaves dtbs in arch/arm/boot/dts/
untouched. Include dts directory so that clean-files rule
from arch/arm/boot/dts/Makefile is invoked when make
clean is done.
Cc: Dirk Behme <dirk.behme@de.bosch.com>
CC: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
BCM2835-ARM-Peripherals.pdf states that the I2C module's input clock is
nominally 150MHz, and that value is currently reflected in bcm2835.dtsi.
However, practical measurements show that the rate is actually 250MHz,
and this agrees with various downstream kernels.
Switch the I2C clock's frequency to 250MHz so that the generated bus
clock rate is accurate.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
In b1cffebf (ARM: GIC: remove direct use of gic_raise_softirq)
gic_raise_softirq() was moved inside arch/arm/common/gic.c but in the
process it reverted by mistake a change to that function made by
384a290 (ARM: gic: use a private mapping for CPU target interfaces).
This breaks multicluster systems on ARM.
This patch fixes the typo.
Signed-off-by: Javi Merino <javi.merino@arm.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a
couple of places, the driver compares the DMA address stored in a QH's
overlay region with the address of a particular qTD, in order to see
whether that qTD is the one currently being processed by the hardware.
(If it is then the status in the QH's overlay region is more
up-to-date than the status in the qTD, and if it isn't then the
overlay's value needs to be adjusted when the QH is added back to the
active schedule.)
However, DMA address in the overlay region isn't always valid. It
sometimes will contain a stale value, which may happen by coincidence
to be equal to a qTD's DMA address. Instead of checking the DMA
address, we should check whether the overlay region is active and
valid. The patch tests the ACTIVE bit in the overlay, and clears this
bit when the overlay becomes invalid (which happens when the
currently-executing URB is unlinked).
This is the second part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Reported-and-tested-by: Stephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers. After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see
http://marc.info/?l=linux-usb&m=135492071812265&w=2http://marc.info/?l=linux-usb&m=136182570800963&w=2
This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH. The extra IAA delay gives the
controller time to perform its final writeback.
Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently. More through luck than anything
else, it hasn't caused any apparent problems. However, it does
interact badly with the path that follows this one, so it needs to be
addressed.
This is the first part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Stephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A few drivers got their gadget->dev registration problems
exposed by the removal of ->start()/->stop() functions from
udc-core.c. All of such instances are now fixed.
We're also fixing chipidea's mistake of registering private
debugging sysfs files under the gadget's device. This is
in preparation to complete removal of gadget->dev handling
from all UDC drivers which will happen for v3.10 merge window.
MUSB's Kconfig got a fix to avoid a non-buildable selection
of its Kconfig choices.
Some extra devm_ioremap_resource() are added here because they
missed the merge window.
Finally, we have a temporary fix linking function drivers
before gadget drivers so they work fine when they're statically
linked to the kernel. We've done it so since the real fix wouldn't
fit the -rc cycle.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRNI3HAAoJEIaOsuA1yqREWzUQAJNQfEGnrc3RuUQi/TOHs77K
7mGSd9TAdkjbq++ToxBD7ofx6rt7WwkpHYreTFgde8lH9l9fmKdZp30T4WYNZIDp
tiiLPzyAqcaVW8iaEAyINTUgalfDBSJAYSLK4abb4KLVSq7ZEWsxTnGXoRyx/bRm
tjTXu2TDBQg6CjxXNyRC7hX1ErHz86mNQV5RU+uGoUzQLU6X3OQ3n1DrzVMC3wWP
llZcYIayZmsMocqgR5kAym8ujrjce5Qoww4vl/f+PpHAXS8lK/X0fZKn5sKPszIu
zUYDpFrJ62v8M1AzC9k4pIP5XLm2jA3bPO3UPeOjgmXGYy9iI9AVY0V9VtV4xFjQ
cYeNzE5vS97qwzqdz6WaxOnOEZgI0WgejKfiM/qNV6ov7lebkkhju6NoH0TDW5uS
llQceJJJIpVvJHbOVpZ8KRd3yOn/jZGAqQzpSla52U9L9zmDLY5RMZRtIPHGK8gn
Dnvq7+6R0IVT1RPYiXpJg7hEwbj3ywxT1c8kw1xJzFjYDeGoUWxVmKPNzTDLomJr
63gfJI2yqKKHPYumKIGSTYDHNca657XVR4qc9K7MgGyVJ51XIs8vbCtf0T26Q87K
PYvilB4BtIQuGD+CSjFSn/LIqaHRqD5NpxrkMX8GBz9DtOBxYnckMiIYnkx/zfKu
mQXNTa9O/3UCyZtgGST1
=mt8m
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
"usb: fixes for v3.9-rc2
A few drivers got their gadget->dev registration problems
exposed by the removal of ->start()/->stop() functions from
udc-core.c. All of such instances are now fixed.
We're also fixing chipidea's mistake of registering private
debugging sysfs files under the gadget's device. This is
in preparation to complete removal of gadget->dev handling
from all UDC drivers which will happen for v3.10 merge window.
MUSB's Kconfig got a fix to avoid a non-buildable selection
of its Kconfig choices.
Some extra devm_ioremap_resource() are added here because they
missed the merge window.
Finally, we have a temporary fix linking function drivers
before gadget drivers so they work fine when they're statically
linked to the kernel. We've done it so since the real fix wouldn't
fit the -rc cycle."
virtio_rng feeds the randomness buffer handed by the core directly
into the scatterlist, since commit bb347d9807.
However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
(at least on most archs). We could fix this in virtio_rng, but it's actually
far easier to just do it in the core as virtio_rng would have to allocate
a buffer every time (it doesn't know how much the core will want to read).
Reported-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Commit 5ac00add added a testnset mutex and code that disallows
running administrative tasks in parallel. It is prevented that
the device add/delete/balance/replace/resize operations are
started in parallel. By mistake, the defragmentation operation
was included in the check for mutually exclusiveness as well.
This is fixed with this commit.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Only let one trans handle to wait for other handles, otherwise we
will get ABBA issues.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Btrfs balance can easily hit BUG_ON in these places, but we want
to it bail out gracefully after we force the whole filesystem to
readonly. So we use btrfs_std_error hook in place of BUG_ON.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
