Signed-off-by: Ben Collins <ben.c@servergy.com> Cc: Yuan Kang <Yuan.Kang@freescale.com> Acked-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC bug fixes from Olof Johansson:
"Mostly Renesas and Atmel bugfixes this time, targeting boot and build
problems. A couple of patches for gemini and kirkwood as well. On a
whole nothing very controversial."
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: gemini: fix the gemini build
ARM: shmobile: armadillo800eva: enable rw rootfs mount
ARM: Kirkwood: Fix 'SZ_1M' undeclared here for db88f6281-bp-setup.c
ARM: shmobile: mackerel: fixup usb module order
ARM: shmobile: armadillo800eva: fixup: sound card detection order
ARM: shmobile: marzen: fixup smsc911x id for regulator
ARM: at91/feature-removal-schedule: delay at91_mci removal
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source
ARM: mach-shmobile: armadillo800eva: Fix GPIO buttons descriptions
ARM: at91/dts: remove partial parameter in at91sam9g25ek.dts
ARM: at91/clock: fix PLLA overclock warning
ARM: at91: fix rtc-at91sam9 irq issue due to sparse irq support
ARM: at91: fix system timer irq issue due to sparse irq support
ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc
kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"
Fengguang Wu <fengguang.wu@intel.com> writes:
> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
> goto out;
>
> /* copy keys to file */
> - for (i = 0; i < env->envp_idx; i++)
> + dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
> + for (i = 0; i < env->envp_idx; i++) {
> + printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
> count += sprintf(&buf[count], "%s\n", env->envp[i]);
> + }
>
> Oops message, the env[] is again not properly initilized:
>
> [ 44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [ 44.069552] uevent 0 env[0]: (null)
This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away. I had a
hard time trying to disable it anyway ;-)
The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0. This is not true
if CONFIG_HOTPLUG is unset. So things like this end up overwriting
env->envp_idx because the array index is -1:
if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
len = input_print_modalias(&env->buf[env->buflen - 1],
sizeof(env->buf) - env->buflen,
dev, 0);
Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel. This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.
[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull a hwmon fix from Guenter Roeck:
"One patch, fixing DIV_ROUND_CLOSEST to support negative dividends.
While the changes are not in the drivers/hwmon directory, the problem
primarily affects hwmon drivers, and it makes sense to push the patch
through the hwmon tree."
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative dividends
Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull kbuild fixes from Michal Marek:
"These are two fixes that should go into 3.6. The link-vmlinux.sh one
is obvious.
The other one fixes make firmware_install with certain configurations,
where a file in the toplevel firmware tree gets installed first, and
$(INSTALL_FW_PATH)/$$(dir <file>) results in /lib/firmware/./, which
confuses make 3.82 for some reason."
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
firmware: fix directory creation rule matching with make 3.82
link-vmlinux.sh: Fix stray "echo" in error message
ALSA: usb-audio: Fix bogus error messages for delay accounting
The recent fix for the missing fine delayed time adjustment gives
strange error messages at each start of the playback stream, such as
delay: estimated 0, actual 352
delay: estimated 353, actual 705
These come from the sanity check in retire_playback_urb(). Before the
stream is activated via start_endpoints(), a few silent packets have
been already sent. And at this point the delay account is still in
the state as if the new packets are just queued, so the driver gets
confused and spews the bogus error messages.
For fixing the issue, we just need to check whether the received
packet is valid, whether it's zero sized or not.
ALSA: hda - Fix missing Master volume for STAC9200/925x
With the commit [2faa3bf: ALSA: hda - Rewrite the mute-LED hook with
vmaster hook in patch_sigmatel.c], the former Master volume control
was converted to PCM. This was supposed to be covered by the vmaster
control. But due to the lack of "PCM" slave definition, this didn't
happen properly. The patch fixes the missing entry.
Merge tag 'mmc-fixes-for-3.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
Pull MMC fixes from Chris Ball:
- a firmware bug on several Samsung MoviNAND eMMC models causes
permanent corruption on the device when secure erase and secure trim
requests are made, so we disable those requests on these eMMC devices.
- atmel-mci: fix a hang with some SD cards by waiting for not-busy flag.
- dw_mmc: low-power mode breaks SDIO interrupts; fix PIO error handling;
fix handling of error interrupts.
- mxs-mmc: fix deadlocks; fix compile error due to dma.h arch change.
- omap: fix broken PIO mode causing memory corruption.
- sdhci-esdhc: fix card detection.
* tag 'mmc-fixes-for-3.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
mmc: omap: fix broken PIO mode
mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.
mmc: dw_mmc: Disable low power mode if SDIO interrupts are used
mmc: dw_mmc: fix error handling in PIO mode
mmc: dw_mmc: correct mishandling error interrupt
mmc: dw_mmc: amend using error interrupt status
mmc: atmel-mci: not busy flag has also to be used for read operations
mmc: sdhci-esdhc: break out early if clock is 0
mmc: mxs-mmc: fix deadlock caused by recursion loop
mmc: mxs-mmc: fix deadlock in SDIO IRQ case
mmc: bfin_sdh: fix dma_desc_array build error
arch/um/os-Linux/time.c: In function 'deliver_alarm':
arch/um/os-Linux/time.c:117:3: error: too few arguments to function 'alarm_handler'
arch/um/os-Linux/internal.h:1:6: note: declared here
The error was introduced by commit d3c1cfcd ("um: pass siginfo to guest
process") in 3.6-rc1.
Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Benjamin Herrenschmidt:
"Here are a few fixes for 3.6 that were piling up while I was away or
busy (I was mostly MIA a week or two before San Diego).
Some fixes from Anton fixing up issues with our relatively new DSCR
control feature, and a few other fixes that are either regressions or
bugs nasty enough to warrant not waiting."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Don't use __put_user() in patch_instruction
powerpc: Make sure IPI handlers see data written by IPI senders
powerpc: Restore correct DSCR in context switch
powerpc: Fix DSCR inheritance in copy_thread()
powerpc: Keep thread.dscr and thread.dscr_inherit in sync
powerpc: Update DSCR on all CPUs when writing sysfs dscr_default
powerpc/powernv: Always go into nap mode when CPU is offline
powerpc: Give hypervisor decrementer interrupts their own handler
powerpc/vphn: Fix arch_update_cpu_topology() return value
Merge tag 'gpio-fixes-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"These are some GPIO regression fixes for v3.6:
- Erroneous debug message from of_get_named_gpio_flags()
- Make sure the MC9S08DZ60 GPIO driver depend on I2C being compiled
in (not module) or allmodconfig breaks.
- Check return value from irq_alloc_descs() in the Emma Mobile GPIO
driver.
- Assign the owner field for the rdc321x driver so the module won't
be removed if it has active GPIOs."
* tag 'gpio-fixes-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: rdc321x: Prevent removal of modules exporting active GPIOs
gpio: em: Fix checking return value of irq_alloc_descs
gpio: mc9s08dz60: Fix build error if I2C=m
gpio: Fix debug message in of_get_named_gpio_flags()
Merge tag 'sound-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"There are nothing scaring, contains only small fixes for HD-audio and
USB-audio:
- EPSS regression fix and GPIO fix for HD-audio IDT codecs
- A series of USB-audio regression fixes that are found since 3.5
kernel"
* tag 'sound-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: snd-usb: fix cross-interface streaming devices
ALSA: snd-usb: fix calls to next_packet_size
ALSA: snd-usb: restore delay information
ALSA: snd-usb: use list_for_each_safe for endpoint resources
ALSA: snd-usb: Fix URB cancellation at stream start
ALSA: hda - Don't trust codec EPSS bit for IDT 92HD83xx & co
ALSA: hda - Avoid unnecessary parameter read for EPSS
ALSA: hda - Do not set GPIOs for speakers on IDT if there are no speakers
Merge tag 'fbdev-fixes-for-3.6-1' of git://github.com/schandinat/linux-2.6
Pull fbdev fixes from Florian Tobias Schandinat:
- a fix by Paul Cercueil to prevent a possible buffer overflow
- a fix by Bruno Prémont to prevent a rare sleep in invalid context
- a fix by Julia Lawall for a double free in auo_k190x
- a fix by Dan Carpenter to prevent a division by zero in mb862xxfb
- a regression fix by Tomi Valkeinen for the SDI output in OMAP
- a fix by Grazvydas Ignotas to fix the console colors in OMAP
* tag 'fbdev-fixes-for-3.6-1' of git://github.com/schandinat/linux-2.6:
OMAPFB: fix framebuffer console colors
OMAPDSS: Fix SDI PLL locking
video: mb862xxfb: prevent divide by zero bug
drivers/video/auo_k190x.c: drop kfree of devm_kzalloc's data
fbcon: Fix bit_putcs() call to kmalloc(s, GFP_KERNEL)
fbcon: prevent possible buffer overflow.
Merge tag 'upstream-3.6-rc5' of git://git.infradead.org/linux-ubi
Pull ubi fix from Artem Bityutskiy:
"A single small fix for memory deallocation: we allocated memory using
'kmem_cache_alloc()' but were freeing it using 'kfree()' in some
cases. Now we fix this by using 'kmem_cache_free()' instead."
* tag 'upstream-3.6-rc5' of git://git.infradead.org/linux-ubi:
UBI: fix a horrible memory deallocation bug
Fix order of arguments to compat_put_time[spec|val]
Commit 644595f89620 ("compat: Handle COMPAT_USE_64BIT_TIME in
net/socket.c") introduced a bug where the helper functions to take
either a 64-bit or compat time[spec|val] got the arguments in the wrong
order, passing the kernel stack pointer off as a user pointer (and vice
versa).
Because of the user address range check, that in turn then causes an
EFAULT due to the user pointer range checking failing for the kernel
address. Incorrectly resuling in a failed system call for 32-bit
processes with a 64-bit kernel.
On odder architectures like HP-PA (with separate user/kernel address
spaces), it can be used read kernel memory.
Alan Stern [Tue, 4 Sep 2012 14:41:02 +0000 (10:41 -0400)]
USB: add device quirk for Joss Optical touchboard
This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
infrared touchboard device. The device doesn't like to be asked for
its interface strings.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: adam ? <adam3337@wp.pl> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Ferre [Wed, 29 Aug 2012 09:49:18 +0000 (11:49 +0200)]
USB: ohci-at91: fix PIO handling in relation with number of ports
If the number of ports present on the SoC/board is not the maximum
and that the platform data is not filled with all data, there is
an easy way to mess the PIO setup for this interface.
This quick fix addresses mis-configuration in USB host platform data
that is common in at91 boards since commit 0ee6d1e (USB: ohci-at91:
change maximum number of ports) that did not modified the associatd
board files.
Reported-by: Klaus Falkner <klaus.falkner@solectrix.de> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Stable <stable@vger.kernel.org> [3.4+] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horst Schirmeier [Thu, 30 Aug 2012 22:00:28 +0000 (00:00 +0200)]
USB: ftdi_sio: PID for NZR SEM 16+ USB
This adds the USB PID for the NZR SEM 16+ USB energy monitor device
<http://www.nzr.de>. It works perfectly with the GPL software on
<http://schou.dk/linux/sparometer/>.
USB: ftdi-sio: add support for more Physik Instrumente devices
Commit b69cc672052540 added support for the E-861. After acquiring a C-867, I
realised that every Physik Instrumente's device has a different PID. They are
listed in the Windows device driver's .inf file. So here are all PIDs for the
current (and probably future) USB devices from Physik Instrumente.
Compiled, but only actually tested on the E-861 and C-867.
Santiago Leon [Tue, 4 Sep 2012 14:41:37 +0000 (14:41 +0000)]
ibmveth: Fix alignment of rx queue bug
This patch fixes a bug found by Nish Aravamudan
(https://lkml.org/lkml/2012/5/15/220) where the driver is not following
the spec (it is not aligning the rx buffer on a 16-byte boundary) and the
hypervisor aborts the registration, making the device unusable.
The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461)
to replace the kmalloc+map for a single call to dma_alloc_coherent()
because that function always aligns to a 16-byte boundary.
The stable trees will run into this bug whenever the rx buffer kmalloc call
returns something not aligned on a 16-byte boundary.
Cc: <stable@vger.kernel.org> Signed-off-by: Santiago Leon <santil@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
tcp: fix possible socket refcount problem for ipv6
commit 144d56e91044181ec0ef67aeca91e9a8b5718348
("tcp: fix possible socket refcount problem") is missing
the IPv6 part. As tcp_release_cb is shared by both protocols
we should hold sock reference for the TCP_MTU_REDUCED_DEFERRED
bit.
Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dirk Behme [Fri, 31 Aug 2012 08:02:47 +0000 (10:02 +0200)]
tty: serial: imx: don't reinit clock in imx_setup_ufcr()
Remove the clock configuration from imx_setup_ufcr(). This
isn't needed here and will cause garbage output if done.
To be be sure that we only touch the bits we want (TXTL and RXTL)
we have to mask out all other bits of the UFCR register. Add
one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6).
Xinyu Chen [Mon, 27 Aug 2012 07:36:51 +0000 (09:36 +0200)]
tty: serial: imx: console write routing is unsafe on SMP
The console feature's write routing is unsafe on SMP with
the startup/shutdown call.
There could be several consumers of the console
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which open /dev/console and write with sys_write()
The shell goes into the normal uart open/write routing,
but the other two go into the console operations.
The open routing calls imx serial startup, which will write USR1/2
register without any lock and critical with imx_console_write call.
Add a spin_lock for startup/shutdown/console_write routing.
This patch is a port from Freescale's Android kernel.
usb: host: xhci: fix compilation error for non-PCI based stacks
For non PCI-based stacks, this function call
usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
made from xhci_shutdown is not applicable.
Ideally, we wouldn't have any PCI-specific code on
a generic driver such as the xHCI stack, but it looks
like we should just stub usb_disable_xhci_ports() out
for non-PCI devices.
[ balbi@ti.com: slight improvement to commit log ]
This patch should be backported to kernels as old as 3.0, since the
commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch
PPT ports to EHCI on shutdown.") was marked for stable.
Signed-off-by: Moiz Sonasath<m-sonasath@ti.com> Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
David S. Miller [Wed, 5 Sep 2012 19:11:18 +0000 (15:11 -0400)]
Merge branch 'fixes-for-3.6' of git://gitorious.org/linux-can/linux-can
Marc Kleine-Budde says:
====================
this patch is for the v3.6 release cycle. Benoît Locher fixed a repeated frame
bug in the mcp251x driver. He implemented the workaround suggested by the
errata sheet.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Ruchika Kharwar [Fri, 10 Aug 2012 06:58:30 +0000 (09:58 +0300)]
usb: host: xhci-plat: use ioremap_nocache
Use the ioremap_nocache variant of the ioremap API in
order to make sure our memory will be marked uncachable.
This patch should be backported to kernels as old as 3.4, that contain
the commit 3429e91a661e1f383aecc86c6bbcf65afb15c892 "usb: host: xhci:
add platform driver support".
Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Matthew Garrett [Tue, 14 Aug 2012 20:44:49 +0000 (16:44 -0400)]
xhci: Make handover code more robust
My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
crashes when booting via UEFI. I finally tracked this down to the xhci
handoff code. It seems that reads from the device occasionally just return
0xff, resulting in xhci_find_next_cap_offset generating a value that's
larger than the resource region. We then oops when attempting to read the
value. Sanity checking that value lets us avoid the crash.
I've no idea what's causing the underlying problem, and xhci still doesn't
actually *work* even with this, but the machine at least boots which will
probably make further debugging easier.
This should be backported to kernels as old as 2.6.31, that contain the
commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
and HW initialization."
Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Dan Carpenter [Mon, 13 Aug 2012 16:57:03 +0000 (19:57 +0300)]
xhci: Fix a logical vs bitwise AND bug
The intent was to test whether the flag was set.
This patch should be backported to stable kernels as old as 3.0, since
it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci:
Switch PPT ports to EHCI on shutdown.", which was marked for stable.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Seth Jennings [Wed, 29 Aug 2012 21:58:45 +0000 (16:58 -0500)]
staging: zcache: fix cleancache race condition with shrinker
This patch fixes a race condition that results in memory
corruption when using cleancache.
The race exists between the zcache shrinker handler,
shrink_zcache_memory() and cleancache_get_page().
In most cases, the shrinker will both evict a zbpg
from its buddy list and flush it from tmem before a
cleancache_get_page() occurs on that page. A subsequent
cleancache_get_page() will fail in the tmem layer.
In the rare case that two occur together and the
cleancache_get_page() path gets through the tmem
layer before the shrinker path can flush tmem,
zbud_decompress() does a check to see if the zbpg is a
"zombie", i.e. not on a buddy list, which means the shrinker
is in the process of reclaiming it. If the zbpg is a zombie,
zbud_decompress() returns -EINVAL.
However, this return code is being ignored by the caller,
zcache_pampd_get_data_and_free(), which results in the
caller of cleancache_get_page() thinking that the page has
been properly retrieved when it has not.
This patch modifies zcache_pampd_get_data_and_free() to
convey the failure up the stack so that the caller of
cleancache_get_page() knows the page retrieval failed.
This needs to be applied to stable trees as well.
zcache-main.c was named zcache.c before v3.1, so
I'm not sure how you want to handle trees earlier
than that.
Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Drake [Mon, 3 Sep 2012 19:49:09 +0000 (15:49 -0400)]
libertas sdio: fix suspend when interface is down
When the interface is down, the hardware is powered off.
However, the suspend handler currently tries to send host sleep commands
(when wakeup params are set) in this configuration, causing a system hang
when going into suspend (the commands will never complete).
Avoid this by detecting this situation and simply returning from
the suspend handler without doing anything special.
Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.
The fix was tested on the latest compat-wireless-3.5.1-1-snpc.
Cc: stable@vger.kernel.org Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix rfkill polling prior to interface start.
We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.
Reported-and-tested-by: Andreas Messer <andi@bastelmap.de> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix word size of rt2500usb MAC_CSR19 register.
The register is 16 bits wide, not 32.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hante Meuleman [Thu, 30 Aug 2012 08:05:37 +0000 (10:05 +0200)]
brcmfmac: fix get rssi by clearing getvar struct.
The function brcmf_cfg80211_get_station requests the RSSI from
the device. The complete structure used needs to be cleared
before sending the request to firmware. Otherwise the request
fails filling the logs with "Could not get rssi (-2)" messages.
Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hante Meuleman [Thu, 30 Aug 2012 08:05:36 +0000 (10:05 +0200)]
brcmfmac: fix race condition for rx and tx data.
On both rx and tx there is was a race condition on the queueing
of usb requests. When for example frame gets submitted it is
possible that complete function gets called even before
usb_submit_urb() returns. As a result it is possible that usb
requests get losts, which was noticed on OMAP4 pandaboard
platform. This patch fixes the race condition.
Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hante Meuleman [Thu, 30 Aug 2012 08:05:35 +0000 (10:05 +0200)]
brcmfmac: dont use ZERO flag for usb IN
URB_ZERO_PACKET should only be set or bulk OUT and this condition
is checked with a WARN_ON in usb_submit_urb(). This patch fixes
brcmfmac to get rid of this warning filling the logs.
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Arend van Spriel [Thu, 30 Aug 2012 08:05:34 +0000 (10:05 +0200)]
brcmfmac: fix use of dev_kfree_skb() in irq context
The USB part of the brcmfmac did a dev_kfree_skb() that resulted
in a warning in net/core/skbuff.c:
Jul 11 04:53:33 lb-bun-10 kernel: [53282.667745] WARNING: at
net/core/skbuff.c:490 skb_release_head_state+0xcc/0xe0()
The brcmutil modules provides brcmu_pkt_buf_free_skb() which takes
the context into account. This patch makes use of this function
instead of dev_kfree_skb().
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Generic timers for BTCOEX functionality is applicable
only for 3 WIRE BTCOEX (and MCI) chipsets.
Hence btcoex->no_stomp_timer is allocated only 3 WIRE
btcoex chipsets and in all the other cases its NULL.
Make sure we stop the generic timer only if
'btcoex->hw_timer_enabled' is true(only if its up and
running)
Felix Fietkau [Mon, 27 Aug 2012 15:00:08 +0000 (17:00 +0200)]
ath9k_hw: enable PA linearization
This feature had been disabled in ath9k because the code to support
it was incomplete, but now the code is in sync with the internal QCA
codebase, so it's time to enable it.
On many newer devices, the calibration is assumed to be done with PA
linearization enabled.
Tests with a particular AR933x device showed that the signal emitted
at full power was highly distorted and unreliable with PA linearization
disabled. With this patch, the signal becomes clear and stability
is improved.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Mon, 27 Aug 2012 15:00:07 +0000 (17:00 +0200)]
ath9k: fix PA linearization calibration related crash
Before PAPRD training can run, the card needs to have sent a packet for
thermal calibration. Sending a dummy packet with the PAPRD training flag
set causes a crash under some circumstance.
Fix the code by replacing the dummy tx with a delay that waits for a
real packet tx to have occurred.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Mon, 27 Aug 2012 15:00:03 +0000 (17:00 +0200)]
ath9k_hw: do not enable the MIB interrupt in the interrupt mask register
The interrupt is no longer handling it. While it shouldn't fire (wraparound
is highly unlikely), the consequences would be fatal (interrupt storm).
Disable the interrupt to prevent that from happening.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to the vendor driver v2.6.0.1, during the rf register init the SRAM
voltage should be increased to 1.35V and after 1ms decreased back to 1.2V. This
patch adds the field setting of LDO_CFG0_LDO_CORE_VLEVEL accordingly.
Cc: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stone Piao [Thu, 23 Aug 2012 03:26:31 +0000 (20:26 -0700)]
mwifiex: fix skb length issue when send a command to firmware
When we send a command to firmware, we assumed that cmd_size
will be always less than or equal to the structure size of
host_cmd_ds_command. However, this is no longer true after
we added AP support. There are some AP commands that Custom
IE TLVs are included in command buffer, hence the cmd_size
gets enlarged by the TLV data. We need to increase the skb
length for the extra data.
Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Various small fixes for cfg.c: mpath_set_pinfo()
Various small fixes for net/mac80211/cfg.c:mpath_set_pinfo():
Initialize *pinfo before filling members in, handle MESH_PATH_RESOLVED
correctly, and remove bogus assignment; result in correct display
of FLAGS values and meaningful EXPTIME for expired paths in iw utility.
Signed-off-by: Yoichi Shinoda <shinoda@jaist.ac.jp> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
powerpc: Don't use __put_user() in patch_instruction
patch_instruction() can be called very early on ppc32, when the kernel
isn't yet running at it's linked address. That can cause the !
is_kernel_addr() test in __put_user() to trip and call might_sleep()
which is very bad at that point during boot.
Use a lower level function instead for now, at least until we get to
rework ppc32 boot process to do the code patching later, like ppc64
does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Paul Mackerras [Tue, 4 Sep 2012 18:33:08 +0000 (18:33 +0000)]
powerpc: Make sure IPI handlers see data written by IPI senders
We have been observing hangs, both of KVM guest vcpu tasks and more
generally, where a process that is woken doesn't properly wake up and
continue to run, but instead sticks in TASK_WAKING state. This
happens because the update of rq->wake_list in ttwu_queue_remote()
is not ordered with the update of ipi_message in
smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
scheduler_ipi() is not ordered with the reading of ipi_message in
smp_ipi_demux(). Thus it is possible for the IPI receiver not to see
the updated rq->wake_list and therefore conclude that there is nothing
for it to do.
In order to make sure that anything done before smp_send_reschedule()
is ordered before anything done in the resulting call to scheduler_ipi(),
this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
The barrier in smp_muxed_message_pass() is a full barrier to ensure that
there is a full ordering between the smp_send_reschedule() caller and
scheduler_ipi(). In smp_ipi_demux(), we use xchg() rather than
xchg_local() because xchg() includes release and acquire barriers.
Using xchg() rather than xchg_local() makes sense given that
ipi_message is not just accessed locally.
This moves the barrier between setting the message and calling the
cause_ipi() function into the individual cause_ipi implementations.
Most of them -- those that used outb, out_8 or similar -- already had
a full barrier because out_8 etc. include a sync before the MMIO
store. This adds an explicit barrier in the two remaining cases.
These changes made no measurable difference to the speed of IPIs as
measured using a simple ping-pong latency test across two CPUs on
different cores of a POWER7 machine.
The analysis of the reason why processes were not waking up properly
is due to Milton Miller.
Cc: stable@vger.kernel.org # v3.0+ Reported-by: Milton Miller <miltonm@bga.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Anton Blanchard [Mon, 3 Sep 2012 16:51:10 +0000 (16:51 +0000)]
powerpc: Restore correct DSCR in context switch
During a context switch we always restore the per thread DSCR value.
If we aren't doing explicit DSCR management
(ie thread.dscr_inherit == 0) and the default DSCR changed while
the process has been sleeping we end up with the wrong value.
Check thread.dscr_inherit and select the default DSCR or per thread
DSCR as required.
This was found with the following test case, when running with
more threads than CPUs (ie forcing context switching):
Anton Blanchard [Mon, 3 Sep 2012 16:49:47 +0000 (16:49 +0000)]
powerpc: Fix DSCR inheritance in copy_thread()
If the default DSCR is non zero we set thread.dscr_inherit in
copy_thread() meaning the new thread and all its children will ignore
future updates to the default DSCR. This is not intended and is
a change in behaviour that a number of our users have hit.
We just need to inherit thread.dscr and thread.dscr_inherit from
the parent which ends up being much simpler.
Anton Blanchard [Mon, 3 Sep 2012 16:48:46 +0000 (16:48 +0000)]
powerpc: Keep thread.dscr and thread.dscr_inherit in sync
When we update the DSCR either via emulation of mtspr(DSCR) or via
a change to dscr_default in sysfs we don't update thread.dscr.
We will eventually update it at context switch time but there is
a period where thread.dscr is incorrect.
If we fork at this point we will copy the old value of thread.dscr
into the child. To avoid this, always keep thread.dscr in sync with
reality.
Anton Blanchard [Mon, 3 Sep 2012 16:47:56 +0000 (16:47 +0000)]
powerpc: Update DSCR on all CPUs when writing sysfs dscr_default
Writing to dscr_default in sysfs doesn't actually change the DSCR -
we rely on a context switch on each CPU to do the work. There is no
guarantee we will get a context switch in a reasonable amount of time
so fire off an IPI to force an immediate change.
This issue was found with the following test case:
Paul Mackerras [Thu, 26 Jul 2012 18:51:09 +0000 (18:51 +0000)]
powerpc/powernv: Always go into nap mode when CPU is offline
The CPU hotplug code for the powernv platform currently only puts
offline CPUs into nap mode if the powersave_nap variable is set.
However, HV-style KVM on this platform requires secondary CPU threads
to be offline and in nap mode. Since we know nap mode works just
fine on all POWER7 machines, and the only machines that support the
powernv platform are POWER7 machines, this changes the code to
always put offline CPUs into nap mode, regardless of powersave_nap.
Powersave_nap still controls whether or not CPUs go into nap mode
when idle, as before.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Paul Mackerras [Thu, 26 Jul 2012 13:56:11 +0000 (13:56 +0000)]
powerpc: Give hypervisor decrementer interrupts their own handler
At the moment the handler for hypervisor decrementer interrupts is
the same as for decrementer interrupts, i.e. timer_interrupt().
This is bogus; if we ever do get a hypervisor decrementer interrupt
it won't have anything to do with the next timer event. In fact
the only time we get hypervisor decrementer interrupts is when one
is left pending on exit from a KVM guest.
When we get a hypervisor decrementer interrupt we don't need to do
anything special to clear it, since they are edge-triggered on the
transition of HDEC from 0 to -1. Thus this adds an empty handler
function for them. We don't need to have them masked when interrupts
are soft-disabled, so we use STD_EXCEPTION_HV instead of
MASKABLE_EXCEPTION_HV.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Linus Walleij [Thu, 30 Aug 2012 17:22:36 +0000 (19:22 +0200)]
ARM: gemini: fix the gemini build
Test-compiling obscure machines I notice that the gemini (which
by the way lacks a defconfig) is broken since some time back.
Adding a simple missing include makes it build again.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
Keng-Yu Lin [Thu, 9 Aug 2012 17:39:23 +0000 (01:39 +0800)]
Intel xhci: Only switch the switchable ports
With a previous patch to enable the EHCI/XHCI port switching, it switches
all the available ports.
The assumption is not correct because the BIOS may expect some ports
not switchable by the OS.
There are two more registers that contains the information of the switchable
and non-switchable ports.
This patch adds the checking code for the two register so that only the
switchable ports are altered.
This patch should be backported to kernels as old as 3.0, that contain
commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Manoj Iyer [Wed, 22 Aug 2012 16:53:18 +0000 (11:53 -0500)]
xhci: Recognize USB 3.0 devices as superspeed at powerup
On Intel Panther Point chipset USB 3.0 devices show up as
high-speed devices on powerup, but after an s3 cycle they are
correctly recognized as SuperSpeed. At powerup switch the port
to xHCI so that USB 3.0 devices are correctly recognized.
Emil Goode [Fri, 17 Aug 2012 17:31:04 +0000 (19:31 +0200)]
staging: wlan-ng: Fix problem with wrong arguments
The function pointer scan in struct cfg80211_ops is not
supposed to be assigned a function with a struct net_device
pointer as an argument. Instead access the net_device struct
in the following way:
struct net_device *dev = request->wdev->netdev;
sparse gives these warnings:
drivers/staging/wlan-ng/cfg80211.c:726:17: warning:
incorrect type in initializer (incompatible argument 2
(different base types))
expected int ( *scan )( ... )
got int ( extern [toplevel] *<noident> )( ... )
drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
initialization from incompatible pointer type [enabled by default]
drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
(near initialization for ‘prism2_usb_cfg_ops.scan’)
[enabled by default]
Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In znet_probe(), strncmp() may access beyond 0x100000 and
trigger the below oops in kvm. Fix it by limiting the loop
under 0x100000-8. I suspect the limit could be further decreased
to 0x100000-sizeof(struct netidblk), however no datasheet at hand..
Ian Abbott [Fri, 31 Aug 2012 19:41:30 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AO output for das08jr-16-ao
Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
that knobbles the upper three-quarters of the output range for the
'das08jr-16-ao' board.
Ian Abbott [Fri, 31 Aug 2012 19:41:29 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AI encoding for das08jr-16-ao
The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
`ai_encoding` member set to `das08_encode12`. It should be set to
`das08_encode16` same as the 'das08jr/16' board. After all, this board
has 16-bit AI resolution.
The description of the A/D LSB register at offset 0 seems incorrect in
the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
resolution is only 12 bits. The diagrams of the A/D LSB and MSB
registers show 15 data bits and a sign bit, which matches what the
software expects for the `das08_encode16` AI encoding method.
Ian Abbott [Mon, 3 Sep 2012 15:39:43 +0000 (16:39 +0100)]
staging: comedi: das08: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`das08_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `das08_find_pci()`). It is decremented when the `detach` hook
(`das08_detach()`) is called to detach the device. However, when the
PCI device is attached automatically via the `attach_pci` hook
(`das08_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `das08_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:42 +0000 (16:39 +0100)]
staging: comedi: amplc_pci230: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pci230_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pci230_find_pci_dev()`). It is decremented when the `detach`
hook (`pci230_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pci230_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pci230_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:41 +0000 (16:39 +0100)]
staging: comedi: amplc_pc263: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pc263_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc263_find_pci_dev()`). It is decremented when the `detach`
hook (`pc263_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc263_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pc263_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:40 +0000 (16:39 +0100)]
staging: comedi: amplc_pc236: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pc236_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc236_find_pci_dev()`). It is decremented when the `detach`
hook (`pc236_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc236_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pc236_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:39 +0000 (16:39 +0100)]
staging: comedi: amplc_dio200: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`dio200_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `dio200_find_pci_dev()`). It is decremented
when the `detach` hook (`dio200_detach()`) is called to detach the
device. However, when the PCI device is attached automatically via the
`attach_pci` hook (`dio200_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `dio200_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:38 +0000 (16:39 +0100)]
staging: comedi: amplc_pci224: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pci224_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `pci224_find_pci_dev()`). It is decremented
when the `detach` hook (`pci224_detach()`) is called to detach the
device. However, when the PCI device is attached automatically via the
`attach_pci` hook (`pci224_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pci224_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
xfrm: Workaround incompatibility of ESN and async crypto
ESN for esp is defined in RFC 4303. This RFC assumes that the
sequence number counters are always up to date. However,
this is not true if an async crypto algorithm is employed.
If the sequence number counters are not up to date on sequence
number check, we may incorrectly update the upper 32 bit of
the sequence number. This leads to a DOS.
We workaround this by comparing the upper sequence number,
(used for authentication) with the upper sequence number
computed after the async processing. We drop the packet
if these numbers are different.
To do this, we introduce a recheck function that does this
check in the ESN case.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
[ 2.086181] Waiting for root device /dev/mmcblk0p1...
[ 2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000
[ 2.331451] Internal error: : 406 [#1] ARM
[ 2.335784] Modules linked in:
[ 2.339050] CPU: 0 Not tainted (3.6.0-rc3 #60)
[ 2.344146] PC is at default_idle+0x28/0x30
[ 2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0
...
This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c. (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)
The PIO code, added with the rest of the driver in commit 730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ("[MMC] Add OMAP MMC host
driver"), confused bytes with 16-bit words. This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes. The driver also did not increment the buffer
pointer after the transfer occurred. This bug resulted in data
corruption during any transfer larger than 64 bytes.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Ian Chen [Wed, 29 Aug 2012 06:05:36 +0000 (15:05 +0900)]
mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.
For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim. For these specific MoviNAND devices, we skip
these operations.
Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.
projects / karo-tx-linux.git / log