USB: ftdi_sio: sort PID/VID entries in new ftdi_sio_ids.h header

commit 4e092d110fe931db3878865db185be1c9df3e182 upstream.

This is a (almost) sort-only patch to sort FTDI device
product ID definitions in new ftdi_sio_ids.h header.

Advantage is that new device ID submissions will now have a specific (sorted)
position - less future merge conflicts.

Compile-tested, based on _current_ mainline git.
Minor checkpatch.pl warnings were eliminated whereever it made sense,
very minor text changes.

Signed-off-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: ftdi_sio: isolate all device IDs to new ftdi_sio_ids.h header

commit 31844d55800e1b93fe75c4d6188a4a44db2e1bbe upstream.

This is a strictly move-only patch to relocate all FTDI device
product ID definitions to their own ftdi_sio_ids.h header
(following the usual *_ids.h kernel tree convention, too),
thus correcting the slightly too messy appearance
(crucial driver defines were stuck somewhere in the decaying middle swamp
of the huge existing header).

Compile-tested, based on latest mainline git.

Signed-off-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Move hcd free_dev call into usb_disconnect to fix oops

commit f7410ced7f931bb1ad79d1336412cf7b7a33cb14 upstream.

USB: Move hcd free_dev call into usb_disconnect

I found a way to oops the kernel:

1. Open a USB device through devio.
2. Remove the hcd module in the host kernel.
3. Close the devio file descriptor.

The problem is that closing the file descriptor does usb_release_dev
as it is the last reference.  usb_release_dev then tries to invoke
the hcd free_dev function (or rather dereferencing the hcd driver
struct).  This causes an oops as the hcd driver has already been
unloaded so the struct is gone.

This patch tries to fix this by bringing the free_dev call earlier
and into usb_disconnect.  I have verified that repeating the
above steps no longer crashes with this patch applied.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove debugging message for uevent constructions

commit cceffe9348f93188d7811bda95924d4bd3040d0f upstream.

This patch (as1332) removes an unneeded and annoying debugging message
announcing all USB uevent constructions.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix crash in uhci_scan_schedule

commit d23356da714595b888686d22cd19061323c09190 upstream.

When hardware is removed on a Stratus, the system may crash like this:

ACPI: PCI interrupt for device 0000:7c:00.1 disabled
Trying to free nonexistent resource <00000000a8000000-00000000afffffff>
Trying to free nonexistent resource <00000000a4800000-00000000a480ffff>
uhci_hcd 0000:7e:1d.0: remove, state 1
usb usb2: USB disconnect, address 1
usb 2-1: USB disconnect, address 2
Unable to handle kernel paging request at 0000000000100100 RIP:
 [<ffffffff88021950>] :uhci_hcd:uhci_scan_schedule+0xa2/0x89c

 #4 [ffff81011de17e50] uhci_scan_schedule at ffffffff88021918
 #5 [ffff81011de17ed0] uhci_irq at ffffffff88023cb8
 #6 [ffff81011de17f10] usb_hcd_irq at ffffffff801f1c1f
 #7 [ffff81011de17f20] handle_IRQ_event at ffffffff8001123b
 #8 [ffff81011de17f50] __do_IRQ at ffffffff800ba749

This occurs because an interrupt scans uhci->skelqh, which is
being freed. We do the right thing: disable the interrupts in the
device, and do not do any processing if the interrupt is shared
with other source, but it's possible that another CPU gets
delayed somewhere (e.g. loops) until we started freeing.

The agreed-upon solution is to wait for interrupts to play out
before proceeding. No other bareers are neceesary.

A backport of this patch was tested on a 2.6.18 based kernel.
Testing of 2.6.32-based kernels is under way, but it takes us
forever (months) to turn this around. So I think it's a good
patch and we should keep it.

Tracked in RH bz#516851

Signed-Off-By: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix the idProduct value for USB-3.0 root hubs

commit cd780694920fbf869b23c8afb0bd083e7b0448c7 upstream.

This patch (as1346) changes the idProduct value for USB-3.0 root hubs
from 0x0002 (which we already use for USB-2.0 root hubs) to 0x0003.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: xhci: Fix finding extended capabilities registers

commit 05197921ff3dad52d99fd1647974c57d9c28d40e upstream.

According "5.3.6 Capability Parameters (HCCPARAMS)" of xHCI rev0.96 spec,
value of xECP register indicates a relative offset, in 32-bit words,
from Base to the beginning of the first extended capability.
The wrong calculation will cause BIOS handoff fail (not handoff from BIOS)
in some platform with BIOS USB legacy sup support.

Signed-off-by: Edward Shao <laface.tw@gmail.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

x86: Fix SCI on IOAPIC != 0

commit 18dce6ba5c8c6bd0f3ab4efa4cbdd698dab5c40a upstream.

Thomas Renninger <trenn@suse.de> reported on IBM x3330

booting a latest kernel on this machine results in:

PCI: PCI BIOS revision 2.10 entry at 0xfd61c, last bus=1
PCI: Using configuration type 1 for base access bio: create slab <bio-0> at 0
ACPI: SCI (IRQ30) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20090903/evevent-161)
ACPI: Unable to start the ACPI Interpreter

Later all kind of devices fail...

and bisect it down to this commit:
commit b9c61b70075c87a8612624736faf4a2de5b1ed30

    x86/pci: update pirq_enable_irq() to setup io apic routing

it turns out we need to set irq routing for the sci on ioapic1 early.

-v2: make it work without sparseirq too.
-v3: fix checkpatch.pl warning, and cc to stable

Reported-by: Thomas Renninger <trenn@suse.de>
Bisected-by: Thomas Renninger <trenn@suse.de>
Tested-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <1265793639-15071-2-git-send-email-yinghai@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

x86: Avoid race condition in pci_enable_msix()

commit ced5b697a76d325e7a7ac7d382dbbb632c765093 upstream.

Keep chip_data in create_irq_nr and destroy_irq.

When two drivers are setting up MSI-X at the same time via
pci_enable_msix() there is a race.  See this dmesg excerpt:

[   85.170610] ixgbe 0000:02:00.1: irq 97 for MSI/MSI-X
[   85.170611]   alloc irq_desc for 99 on node -1
[   85.170613] igb 0000:08:00.1: irq 98 for MSI/MSI-X
[   85.170614]   alloc kstat_irqs on node -1
[   85.170616] alloc irq_2_iommu on node -1
[   85.170617]   alloc irq_desc for 100 on node -1
[   85.170619]   alloc kstat_irqs on node -1
[   85.170621] alloc irq_2_iommu on node -1
[   85.170625] ixgbe 0000:02:00.1: irq 99 for MSI/MSI-X
[   85.170626]   alloc irq_desc for 101 on node -1
[   85.170628] igb 0000:08:00.1: irq 100 for MSI/MSI-X
[   85.170630]   alloc kstat_irqs on node -1
[   85.170631] alloc irq_2_iommu on node -1
[   85.170635]   alloc irq_desc for 102 on node -1
[   85.170636]   alloc kstat_irqs on node -1
[   85.170639] alloc irq_2_iommu on node -1
[   85.170646] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000088

As you can see igb and ixgbe are both alternating on create_irq_nr()
via pci_enable_msix() in their probe function.

ixgbe: While looping through irq_desc_ptrs[] via create_irq_nr() ixgbe
choses irq_desc_ptrs[102] and exits the loop, drops vector_lock and
calls dynamic_irq_init. Then it sets irq_desc_ptrs[102]->chip_data =
NULL via dynamic_irq_init().

igb: Grabs the vector_lock now and starts looping over irq_desc_ptrs[]
via create_irq_nr(). It gets to irq_desc_ptrs[102] and does this:

cfg_new = irq_desc_ptrs[102]->chip_data;
if (cfg_new->vector != 0)
continue;

This hits the NULL deref.

Another possible race exists via pci_disable_msix() in a driver or in
the number of error paths that call free_msi_irqs():

destroy_irq()
dynamic_irq_cleanup() which sets desc->chip_data = NULL
...race window...
desc->chip_data = cfg;

Remove the save and restore code for cfg in create_irq_nr() and
destroy_irq() and take the desc->lock when checking the irq_cfg.

Reported-and-analyzed-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <1265793639-15071-3-git-send-email-yinghai@kernel.org>
Signed-off-by: Brandon Phililps <bphilips@suse.de>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

x86, xen: Disable highmem PTE allocation even when CONFIG_HIGHPTE=y

commit 817a824b75b1475f1b067c8cee318c7b4d66fcde upstream.

There's a path in the pagefault code where the kernel deliberately
breaks its own locking rules by kmapping a high pte page without
holding the pagetable lock (in at least page_check_address). This
breaks Xen's ability to track the pinned/unpinned state of the
page. There does not appear to be a viable workaround for this
behaviour so simply disable HIGHPTE for all Xen guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
LKML-Reference: <1267204562-11844-1-git-send-email-ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Pasi Kärkkäinen <pasik@iki.fi>
Cc: <xen-devel@lists.xensource.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

x86: Add iMac9,1 to pci_reboot_dmi_table

commit 0a832320f1bae6a4169bf683e201378f2437cfc1 upstream.

On the iMac9,1 /sbin/reboot results in a black mangled screen. Adding
this DMI entry gets the machine to reboot cleanly as it should.

Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
LKML-Reference: <1266362249-3337-1-git-send-email-justinmattock@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

x86, ia32_aout: do not kill argument mapping

commit 318f6b228ba88a394ef560efc1bfe028ad5ae6b6 upstream.

Do not set current->mm->mmap to NULL in 32-bit emulation on 64-bit
load_aout_binary after flush_old_exec as it would destroy already
set brpm mapping with arguments.

Introduced by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
mm: variable length argument support
where the argument mapping in bprm was added.

[ hpa: this is a regression from 2.6.22... time to kill a.out? ]

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
LKML-Reference: <1265831716-7668-1-git-send-email-jslaby@suse.cz>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ollie Wild <aaw@google.com>
Cc: x86@kernel.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ocfs2: Only bug out in direct io write for reflinked extent.

commit cbaee472f274ea9a98aabe47025f6e5551acadcb upstream.

In ocfs2_direct_IO_get_blocks, we only need to bug out
in case of we are going to write a recounted extent rec.

What a silly bug introduced by me!

Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

thinkpad-acpi: fix bluetooth/wwan resume

commit 08fedfc903c78e380b0baa7b57c52d367794d0a5 upstream.

Studying the DSDTs of various thinkpads, it looks like bit 3 of the
argument to SBDC and SWAN is not "set radio to last state on resume".
Rather, it seems to be "if this bit is set, enable radio on resume,
otherwise disable it on resume".

So, the proper way to prepare the radios for S3 suspend is: disable
radio and clear bit 3 on the SBDC/SWAN call to to resume with radio
disabled, and enable radio and set bit 3 on the SBDC/SWAN call to
resume with the radio enabled.

Also, for persistent devices, the rfkill core does not restore state,
so we really need to get the firmware to do the right thing.

We don't sync the radio state on suspend, instead we trust the BIOS to
not do anything weird if we never touched the radio state since boot.
Time will tell if that's a wise way of doing things...

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

thinkpad-acpi: make driver events work in NVRAM poll mode

commit 7f0cf712a74fcc3ad21f0bde95bd32c2f2cc3888 upstream.

Thadeu Lima de Souza Cascardo reports this:

Brightness notification does not work until the user writes to
hotkey_mask attribute.  That's because the polling thread will only run
if hotkey_user_mask is set and someone is reading the input device or
if hotkey_driver_mask is set.  In this second case, this condition is
not tested after the mask is changed, because the brightness and
volume drivers are started after the hotkey drivers.

Fix tpacpi_hotkey_driver_mask_set() to call hotkey_poll_setup(), so
that the poller kthread will be started when needed.

Reported-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Tested-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

thinkpad-acpi: document HKEY event 3006

commit bf8b29c8f7f8269e99eca8b19048ed5b34b51810 upstream.

Event 0x3006 is used to help power management of the ODD in the
UltraBay.  The EC generates this event when the ODD eject button is
pressed (even if the bay is powered down).

Normally, Linux doesn't need this as we keep the SATA link powered
up (which wastes power).  The EC powers up the bay by itself when the
ODD eject button is pressed, and the SATA PHY reports the hotplug.

However, we could also power that SATA link down (and for that matter,
also power down the Ultrabay) if the ODD is left idle for a while with
no disk inside, and use event 0x3006 to know when we need that SATA link
powered back up.

For now, just stop asking for more information when event 0x3006 is
seen, there is no point in pestering users about it anymore.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

thinkpad-acpi: R52 brightness_mode has been confirmed

commit 7d1894d8d1c411d2dad95abfe0f65bacf68c4afa upstream.

We can stop pestering users for confirmation of the brightness_mode
default for firmware TP-76.

While at it, add a few missing comments in that quirk table.

Reported-by: Whoopie <whoopie79@gmx.net>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

thinkpad-acpi: fix poll thread auto-start

commit b589ea4c44170d3f7a845684e2d1b3b9571663af upstream.

The driver was not starting the NVRAM polling thread if the input
device was bound immediately after registration.

This fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=15118

Reported-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sunxvr500: Additional PCI id for sunxvr500 driver

commit 275143e9b237dd7e0b6d01660fd9b8acd9922fa7 upstream.

Intergraph bought 3D Labs and some XVR-500 chips have Intergraph's
vendor id.

Reported-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

netfilter: xt_recent: fix false match

commit 8ccb92ad41cb311e52ad1b1fe77992c7f47a3b63 upstream.

A rule with a zero hit_count will always match.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

netfilter: xt_recent: fix buffer overflow

commit 2c08522e5d2f0af2d6f05be558946dcbf8173683 upstream.

e->index overflows e->stamps[] every ip_pkt_list_tot packets.

Consider the case when ip_pkt_list_tot==1; the first packet received is stored
in e->stamps[0] and e->index is initialized to 1. The next received packet
timestamp is then stored at e->stamps[1] in recent_entry_update(),
a buffer overflow because the maximum e->stamps[] index is 0.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

b43/b43legacy: Wake queues in wireless_core_start

commit 0866b03c7d7dee8a34ffa527ecda426c0f405518 upstream.

If b43 or b43legacy are deauthenticated or disconnected, there is a
possibility that a reconnection is tried with the queues stopped in
mac80211. To prevent this, start the queues before setting
STAT_INITIALIZED.

In b43, a similar change has been in place (twice) in the
wireless_core_init() routine. Remove the duplicate and add similar
code to b43legacy.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ath5k: use correct packet type when transmitting

commit 2ac2927a953a01c83df255118922cce1523d1a18 upstream.

The hardware needs to know what type of frames are being
sent in order to fill in various fields, for example the
timestamp in probe responses (before this patch, it was
always 0).  Set it correctly when initializing the TX
descriptor.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ath9k: disable RIFS search for AR91xx based chips

commit 7bfbae10dc10a5c94a780d117a57e875d77e8e5a upstream.

While ath9k does not support RIFS yet, the ability to receive RIFS
frames is currently enabled for most chipsets in the initvals.
This is causing baseband related issues on AR9160 and AR9130 based
chipsets, which can lock up under certain conditions.

This patch fixes these issues by overriding the initvals, effectively
disabling RIFS for all affected chipsets.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ath9k: fix rate control fallback rate selection

commit 5c0ba62fd4b2dce08055a89600f1d834f9f0fe9e upstream.

When selecting the tx fallback rate, rc.c used a separate variable
'nrix' for storing the next rate index, however it did not use that as
reference for further rate index lowering. Because of that, it ended up
reusing the same rate for multiple multi-rate retry stages, thus
decreasing delivery probability under changing link conditions.

This patch removes the separate (unnecessary) variable and fixes
fallback the way it was intended to work.
This should result in increased throughput and better link stability.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ath9k: fix beacon timer restart after a card reset

commit d8728ee919282c7b01b65cd479ec1e2a9c5d3ba8 upstream.

In AP mode, ath_beacon_config_ap only restarts the timer if a TSF
restart is requested. Apparently this was added, because this function
unconditionally sets the flag for TSF reset.

The problem with this is, that ath9k_hw_reset() clobbers the timer
registers (specified in the initvals), thus effectively disabling the
SWBA interrupt whenever a card reset without TSF reset is issued
(happens in a few places in the code).

This patch fixes ath_beacon_config_ap to only issue the TSF reset flag
when necessary, but reinitialize the timer unconditionally. Tests show,
that this is enough to keep the SWBA interrupt going after a call to
ath_reset()

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

scm: Only support SCM_RIGHTS on unix domain sockets.

commit 76dadd76c265a0cdb5a76aa4eef03fcc9639b388 upstream.

We use scm_send and scm_recv on both unix domain and
netlink sockets, but only unix domain sockets support
everything required for file descriptor passing,
so error if someone attempts to pass file descriptors
over netlink sockets.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

pata_hpt3x2n: always stretch UltraDMA timing

commit 60661933995bc7a09686c901439e17c2a4ea7d5d upstream.

The UltraDMA Tss timing must be stretched with ATA clock of 66 MHz, but the
driver only does this when PCI clock is 66 MHz, whereas it always programs
DPLL clock (which is used as the ATA clock) to 66 MHz.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

hwmon: (tmp421) Restore missing inputs

commit 8d59582a867470a3e0c3eced4a01625ae8dc546b upstream.

An off-by-one error caused some inputs to not be created by the driver
when they should. TMP421 gets only one input instead of two, TMP422
gets two instead of three, etc. Fix the bug by listing explicitly the
number of inputs each device has.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Andre Prendel <andre.prendel@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

hwmon: (tmp421) Fix temperature conversions

commit a44908d742a577fb5ccb9a8c082326d4cea234c2 upstream.

The low bits of temperature registers are status bits, they must be
masked out before converting the register values to temperatures.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Andre Prendel <andre.prendel@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

gpiolib: Actually set output state in wm831x_gpio_direction_output()

commit 3383d23d86791503559cb87837491af37469d9e5 upstream.

wm831x_gpio_direction_output() ignored the state passed into it.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

p54pci: handle dma mapping errors

commit 288c8ce8047695fd8872dd5db3ef21a9679c402f upstream.

This patch adds error-paths to handle pci_dma_mapping errors.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

p54usb: Add the USB ID for Belkin (Accton) FD7050E ver 1010ec

commit 5b9a919a97ac8bdda8020c9b366491b5b91b196e upstream.

Yet another USB ID.

Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix I2C API usage in ohci-pnx4008.

commit 8740cc7d0c532e098cc428251c08befd14f087d8 upstream.

i2c_board_info doesn't contain a member called name. i2c_register_client
call does not exist.

Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: SIS USB2VGA DRIVER: support KAIREN's USB VGA adaptor USB20SVGA-MB-PLUS

commit bbcb8bbad52b8795912e8f02c2b319092b96078e upstream.

This patch adds the USB product ID of KAIREN's USB VGA Adaptor,
USB20SVGA-MB-PLUS, to sisusbvga work with it.

Signed-off-by: Tanaka Akira <akr@fsij.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: serial: sierra driver indat_callback fix

commit b87c6e86dac1bb5222279cc8ff7e09529e1c4ed9 upstream.

A crash has been reported with sierra driver on disconnect with
Ubuntu/Lucid distribution based on kernel-2.6.32.
The cause of the crash was determined as "NULL tty pointer was being
referenced" and the NULL pointer was passed by sierra_indat_callback().

This patch modifies sierra_indat_callback() function to check for NULL
tty structure pointer. This modification prevents a crash from happening
when the device is disconnected.

This patch fixes the bug reported in Launchpad:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/511157

Signed-off-by: Elina Pasheva <epasheva@sierrawireless.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

serial: imx: fix NULL dereference Oops when pdata == NULL

commit bbcd18d1b37413d25eaf4580682b1b8e4a09ff5e upstream.

The platform code doesn't have to provide platform data to get sensible
default behaviour from the imx serial driver.

This patch does not handle NULL dereference in the IrDA case, which still
requires a valid platform data pointer (in imx_startup()/imx_shutdown()),
since I don't know whether there is a sensible default behaviour, or
should the operation just fail cleanly.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Oskar Schirmer <os@emlix.com>
Cc: Fabian Godehardt <fg@emlix.com>
Cc: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

tty: Fix the ldisc hangup race

commit 638b9648ab51c9c549ff5735d3de519ef6199df3 upstream.

This was noticed by Matthias Urlichs and he proposed a fix. This patch
does the fixing a different way to avoid introducing several new race
conditions into the code.

The problem case is TTY_DRIVER_RESET_TERMIOS = 0. In that case while we
abort the ldisc change, the hangup processing has not cleaned up and restarted
the ldisc either.

We can't restart the ldisc stuff in the set_ldisc as we don't know what
the hangup did and may touch stuff we shouldn't as we are no longer
supposed to influence the tty at that point in case it has been re-opened
before we get rescheduled.

Instead do it the simple way. Always re-init the ldisc on the hangup, but
use TTY_DRIVER_RESET_TERMIOS to indicate that we should force N_TTY.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Driver-Core: devtmpfs - reset inode permissions before unlinking

commit 5e31d76f2817bd50258a092a7c5b15b3006fd61c upstream.

Before unlinking the inode, reset the current permissions of possible
references like hardlinks, so granted permissions can not be retained
across the device lifetime by creating hardlinks, in the unusual case
that there is a user-writable directory on the same filesystem.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

driver-core: fix race condition in get_device_parent()

commit 77d3d7c1d561f49f755d7390f0764dff90765974 upstream.

sysfs is creating several devices in cuse class concurrently and with
CONFIG_SYSFS_DEPRECATED turned off, it triggers the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
 IP: [<ffffffff81158b0a>] sysfs_addrm_start+0x4a/0xf0
 PGD 75bb067 PUD 75be067 PMD 0
 Oops: 0000 [#1] PREEMPT SMP
 last sysfs file: /sys/devices/system/cpu/cpu7/topology/core_siblings
 CPU 1
 Modules linked in: cuse fuse
 Pid: 4737, comm: osspd Not tainted 2.6.31-work #77
 RIP: 0010:[<ffffffff81158b0a>]  [<ffffffff81158b0a>] sysfs_addrm_start+0x4a/0xf0
 RSP: 0018:ffff88000042f8f8  EFLAGS: 00010296
 RAX: ffff88000042ffd8 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff880007eef660 RDI: 0000000000000001
 RBP: ffff88000042f918 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000001 R11: ffffffff81158b0a R12: ffff88000042f928
 R13: 00000000fffffff4 R14: 0000000000000000 R15: ffff88000042f9a0
 FS:  00007fe93905a950(0000) GS:ffff880008600000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000038 CR3: 00000000077c9000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process osspd (pid: 4737, threadinfo ffff88000042e000, task ffff880007eef040)
 Stack:
  ffff880005da10e8 0000000011cc8d6e ffff88000042f928 ffff880003d28a28
 <0> ffff88000042f988 ffffffff811592d7 0000000000000000 0000000000000000
 <0> 0000000000000000 0000000000000000 ffff88000042f958 0000000011cc8d6e
 Call Trace:
  [<ffffffff811592d7>] create_dir+0x67/0xe0
  [<ffffffff811593a8>] sysfs_create_dir+0x58/0xb0
  [<ffffffff8128ca7c>] ? kobject_add_internal+0xcc/0x220
  [<ffffffff812942e1>] ? vsnprintf+0x3c1/0xb90
  [<ffffffff8128cab7>] kobject_add_internal+0x107/0x220
  [<ffffffff8128cd37>] kobject_add_varg+0x47/0x80
  [<ffffffff8128ce53>] kobject_add+0x53/0x90
  [<ffffffff81357d84>] device_add+0xd4/0x690
  [<ffffffff81356c2b>] ? dev_set_name+0x4b/0x70
  [<ffffffffa001a884>] cuse_process_init_reply+0x2b4/0x420 [cuse]
  ...

The problem is that kobject_add_internal() first adds a kobject to the
kset and then try to create sysfs directory for it.  If the creation
fails, it remove the kobject from the kset.  get_device_parent()
accesses class_dirs kset while only holding class_dirs.list_lock to
see whether the cuse class dir exists.  But when it exists, it may not
have finished initialization yet or may fail and get removed soon.  In
the above case, the former happened so the second one ends up trying
to create subdirectory under NULL sysfs_dirent.

Fix it by grabbing a mutex in get_device_parent().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Colin Guthrie <cguthrie@mandriva.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ASoC: fix ak4104 register array access

commit e555317c083fda01f516d2153589e82514e20e70 upstream.

Don't touch the variable 'reg' to construct the value for the actual SPI
transport. This variable is again used to access the driver's register
cache, and so random memory is overwritten.
Compute the value in-place instead.

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda-intel: Add position_fix quirk for ASUS M2V-MX SE.

commit 0708cc582f0fe2578eaab722841caf2b4f8cfe37 upstream.

With PulseAudio and an application accessing an input device like `gnome-volume-manager` both have high CPU load as reported in [1].

Loading `snd-hda-intel` with `position_fix=1` fixes this issue. Therefore add a quirk for ASUS M2V-MX SE.

The only downside is, when now exiting for example MPlayer when it is playing an audio file a high pitched sound is outputted by the speaker.

$ lspci -vvnn | grep -A10 Audio
20:01.0 Audio device [0403]: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller) [1106:3288] (rev 10)
Subsystem: ASUSTeK Computer Inc. Device [1043:8290]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel

[1] http://sourceforge.net/mailarchive/forum.php?thread_name=1265550675.4642.24.camel%40mattotaupa&forum_name=alsa-user

Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda - Add position_fix quirk for HP dv3

commit 2f703e7a2ea5f6d5ea14a7b2cd0d31be07839ac6 upstream.

HP dv3 requires position_fix=1.

Reference: Novell bnc#555935
https://bugzilla.novell.com/show_bug.cgi?id=555935

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda - Add a position_fix quirk for MSI Wind U115

commit 45d4ebf1a6255f2234a041685789cbecac3453f1 upstream.

MSI Wind U115 seems to require position_fix=1 explicitly.
Otherwise it screws up PulseAudio.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda: Use LPIB for a Biostar Microtech board

commit 0321b69569eadbc13242922925a4316754c5f744 upstream.

BugLink: https://launchpad.net/bugs/523953
The OR has verified that position_fix=1 is necessary to work around
errors on his machine.

Reported-by: MMarking
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda: Use LPIB for Dell Latitude 131L

commit 9919c7619c52d01e89103bca405cc3d4a2b1ac31 upstream.

BugLink: https://launchpad.net/bugs/530346
The OR has verified that position_fix=1 is necessary to work around
errors on his machine.

Reported-by: Tom Louwrier
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: USB MIDI support for Access Music VirusTI

commit d39e82db73eb876c60d00f00219d767b3be30307 upstream.

Here's a patch that adds MIDI support through USB for one of the Access
Music synths, the VirusTI.

The synth uses standard USBMIDI protocol on its USB interface 3, although
it does signal "vendor specific" class. A magic string has to be sent on
interface 3 to enable the sending of MIDI from the synth (this string was
found by sniffing usb communication of the Windows driver). This is all
my patch does, and it works on my computer.

Please note that the synth can also do standard usb audio I/O on its
interfaces 2&3, which already works with the current snd-usb-audio driver,
except for the audio input from the synth. I'm going to work on it when I
have some time.

Signed-off-by: Sebastien Alaiwan <sebastien.alaiwan@gmail.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: pcm core - fix fifo_size channels interval check

commit 3be522a9514f58e0596db34898a514df206cadc5 upstream.

Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: via82xx: add quirk for D1289 motherboard

commit bf30a4309d4294d3eca248ea8a20c1c3570f5e74 upstream.

Add a headphones-only quirk for the Fujitsu Siemens D1289.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-and-tested-by: Marc Haber <mh+alsa201002@zugschlus.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ALSA: hda: Use 3stack quirk for Toshiba Satellite L40-10Q

commit ba579eb7b30791751f556ee01905636cda50c864 upstream.

BugLink: https://bugs.launchpad.net/bugs/524948
The OR has verified that the existing model=laptop-eapd quirk does not
function correctly but instead needs model=3stack.  Make this change
so that manual corrections to module-init-tools file(s) are not
required.

Reported-by: Lasse Havelund <lasse@havelund.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

oprofile/x86: fix msr access to reserved counters

commit cfc9c0b450176a077205ef39092f0dc1a04e020a upstream.

During switching virtual counters there is access to perfctr msrs. If
the counter is not available this fails due to an invalid
address. This patch fixes this.

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

oprofile/x86: use kzalloc() instead of kmalloc()

commit c17c8fbf349482e89b57d1b800e83e9f4cf40c47 upstream.

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

oprofile/x86: remove node check in AMD IBS initialization

commit 89baaaa98a10cad5cc8516c7208b02d9fc711890 upstream.

Standard AMD systems have the same number of nodes as there are
northbridge devices. However, there may kernel configurations
(especially for 32 bit) or system setups exist, where the node number
is different or it can not be detected properly. Thus the check is not
reliable and may fail though IBS setup was fine. For this reason it is
better to remove the check.

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

oprofile: remove tracing build dependency

commit 18b4a4d59e97e7ff13ee84b5bec79f3fc70a9f0a upstream.

The commit

 1155de4 ring-buffer: Make it generally available

already made ring-buffer available without the TRACING option
enabled. This patch removes the TRACING dependency from oprofile.

Fixes also oprofile configuration on ia64.

The patch also applies to the 2.6.32-stable kernel.

Reported-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

oprofile/x86: fix perfctr nmi reservation for mulitplexing

commit 68dc819ce829f7e7977a56524e710473bdb55115 upstream.

Multiple virtual counters share one physical counter. The reservation
of virtual counters fails due to duplicate allocation of the same
counter. The counters are already reserved. Thus, virtual counter
reservation may removed at all. This also makes the code easier.

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

macintosh/hwmon/ams: Fix device removal sequence

commit 98ceb75c7c14eada76b0aa9f03a635a735cee3cb upstream.

Some code that is in ams_exit() (the module exit code) should instead
be called when the device (not module) is removed. It probably doesn't
make much of a difference in the PMU case, but in the I2C case it does
matter.

I make no guarantee that my fix isn't racy, I'm not familiar enough
with the ams driver code to tell for sure.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Stelian Pop <stelian@popies.net>
Cc: Michael Hanselmann <linux-kernel@hansmi.ch>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

macintosh/therm_adt746x: Fix sysfs attributes lifetime

commit 33a470f6d5e1879c26f16f6b34dc09f82d44f6e9 upstream.

Looking at drivers/macintosh/therm_adt746x.c, the sysfs files are
created in thermostat_init() and removed in thermostat_exit(), which
are the driver's init and exit functions. These files are backed-up by
a per-device structure, so it looks like the wrong thing to do: the
sysfs files have a lifetime longer than the data structure that is
backing it up.

I think that sysfs files creation should be moved to the end of
probe_thermostat() and sysfs files removal should be moved to the
beginning of remove_thermostat().

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Colin Leroy <colin@colino.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

PM / Hibernate: Fix preallocating of memory

commit a9c9b4429df437982d2fbfab1f4b46b01329e9ed upstream.

The hibernate memory preallocation code allocates memory to push some
user space data out of physical RAM, so that the hibernation image is
not too large.  It allocates more memory than necessary for creating
the image, so it has to release some pages to make room for
allocations made while suspending devices and disabling nonboot CPUs,
or the system will hang due to the lack of free pages to allocate
from.  Unfortunately, the function used for freeing these pages,
free_unnecessary_pages(), contains a bug that prevents it from doing
the job on all systems without highmem.

Fix this problem, which is a regression from the 2.6.30 kernel, by
using the right condition for the termination of the loop in
free_unnecessary_pages().

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Alan Jenkins <sourcejedi.lkml@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

V4L/DVB (13148): uvcvideo: Handle V4L2_CTRL_TYPE_BUTTON control type in VIDIOC_QUERYCTRL

commit f4eabafeb3ea41801260fba624cbf2da971d19f8 upstream.

Return minimum, maximum and step set to 0 without querying the hardware.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

dvb-core: Fix DoS bug in ULE decapsulation code that can be triggered by an invalid Payload Pointer

commit 29e1fa3565a7951cc415c634eb2b78dbdbee151d upstream.

ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
has a bug that causes endless loop when Payload Pointer of MPEG2-TS
frame is 182 or 183.  Anyone who sends malicious MPEG2-TS frame will
cause the receiver of ULE SNDU to go into endless loop.

This patch was generated and tested against linux-2.6.32.9 and should
apply cleanly to linux-2.6.33 as well because there was only one typo
fix to dvb_net.c since v2.6.32.

This bug was brought to you by modern day Santa Claus who decided to
shower the satellite dish at Keio University with heavy snow causing
huge burst of errors.  We, receiver end, received Santa Claus's gift in
the form of kernel bug.

Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.

Signed-off-by: Ang Way Chuang <wcang79@gmail.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Staging: mimio: remove the mimio driver

commit e37bcc0de040127281de13a84a608570355c20eb upstream.

It turns out that Mimio has a userspace solution for this product using
libusb, and the in-kernel driver is just getting in the way now and
causing problems.  So they have asked that the in-kernel driver be
removed.  As the staging driver wasn't quite working anyway, and Mimio
supports their libusb solution for all distros, I am removing the
in-kernel driver.

The libusb solution can be downloaded from:
http://www.mimio.com/downloads/mimio_studio_software/linux.asp

Cc: <mwilder@cs.nmsu.edu>
Cc: Phil Hannent <phil@hannent.co.uk>
Cc: Marc Rousseau <Marc.Rousseau@mimio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Staging: hv: match on DMI values to know if we should run.

commit c22090facd354749cfe99a46e903449c7ac07788 upstream.

The HV core mucks around with specific irqs and other low-level stuff
and takes forever to determine that it really shouldn't be running on a
machine.  So instead, trigger off of the DMI system information and
error out much sooner.  This also allows the module loading tools to
recognize that this code should be loaded on this type of system.

Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Staging: hv: add a pci device table

commit 9a775dbd4e8c87b7d35549183145321c7205404e upstream.

This allows the HV core to be properly found and autoloaded
by the system tools.

It uses the Microsoft virtual VGA device to trigger this.

Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

SCSI: qla1280: Drop host_lock while requesting firmware

commit 2cec802980727f1daa46d8c31b411e083d49d7a2 upstream.

request_firmware() may sleep and it appears to be safe to release the
spinlock here.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

clocksource: Fix up a registration/IRQ race in the sh drivers.

commit da64c2a8dee66ca03f4f3e15d84be7bedf73db3d upstream.

All of the SH clocksource drivers follow the scheme that the IRQ is setup
prior to registering the clockevent. The interrupt handler in the
clockevent cases looks to the event handler function pointer being filled
in by the registration code, permitting us to get in to situations where
asserted IRQs step in to the handler before registration has had a chance
to complete and hitting a NULL pointer deref.

In practice this is not an issue for most platforms, but some of them
with fairly special loaders (or that are chain-loading from another
kernel) may enter in to this situation. This fixes up the oops reported
by Rafael on hp6xx.

Reported-and-tested-by: Rafael Ignacio Zurita <rafaelignacio.zurita@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

net/via-rhine: Fix scheduling while atomic bugs

commit c0d7a0212becebe11ffe6979ee3d6f1c4104568d upstream.

There are BUGs "scheduling while atomic" triggered by the timer
rhine_tx_timeout(). They are caused by calling napi_disable() (with
msleep()). This patch fixes it by moving most of the timer content to
the workqueue function (similarly to other drivers, like tg3), with
spin_lock() changed to BH version.

Additionally, there is spin_lock_irq() moved in rhine_close() to
exclude napi_disable() etc., also tg3's way.

Reported-by: Andrey Rahmatullin <wrar@altlinux.org>
Tested-by: Andrey Rahmatullin <wrar@altlinux.org>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

rndis_wlan: disable stall workaround

commit 77593ae28c4c134eaf28ef34ecac3cd4464ecd6e upstream.

Stall workaround doesn't work with bcm4320a devices like with bcm4320b.
This workaround actually causes more stalls/device freeze on bcm4320a.
Therefore disable stall workaround by default.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

rndis_wlan: fix buffer overflow in rndis_query_oid

commit c1f8ca1d837148bf061d6ffa2038366e3cf0e4d7 upstream.

rndis_query_oid overwrites *len which stores buffer size to return full size
of received command and then uses *len with memcpy to fill buffer with
command.

Ofcourse memcpy should be done before replacing buffer size.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

rndis_wlan: handle NL80211_AUTHTYPE_AUTOMATIC

commit 634a555ce3ee5ea1fdcaee8b4ac9ce7b54f301ac upstream.

rndis_wlan didn't know about NL80211_AUTHTYPE_AUTOMATIC and simple
setup with 'iwconfig wlan essid no-encrypt' would fail (ENOSUPP).

v2: use NDIS_80211_AUTH_AUTO_SWITCH instead of _OPEN.
    This will make device try shared key auth first, then open.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

tpm_tis: TPM_STS_DATA_EXPECT workaround

commit 3507d612366a4e81226295f646410130a1f62a5c upstream.

Some newer Lenovo models are shipped with a TPM that doesn't seem to set the TPM_STS_DATA_EXPECT status bit
when sending it a burst of data, so the code understands it as a failure and doesn't proceed sending the chip
the intended data. In this patch we bypass this bit check in case the itpm module parameter was set.

This patch is based on Andy Isaacson's one:

http://marc.info/?l=linux-kernel&m=124650185023495&w=2

It was heavily discussed how should we deal with identifying the chip in kernel space, but the required
patch to do so was NACK'd:

http://marc.info/?l=linux-kernel&m=124650186423711&w=2

This way we let the user choose using this workaround or not based on his
observations on this code behavior when trying to use the TPM.

Fixed a checkpatch issue present on the previous patch, thanks to Daniel Walker.

Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Tested-by: Seiji Munetoh <seiji.munetoh@gmail.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

offb: Add support for framebuffer handoff to offb.

commit ceae8cbe94f3127253110e2d01b9334069e93177 upstream.

This allows offb to be used for initial framebuffer,
and a kms driver to take over later in the boot sequence.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/i915: disable TV hotplug status check

commit 8fcc501831aa5b37a4a5a8cd9dc965be3cacc599 upstream.

As we removed TV hotplug, don't check its status ever.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/i915: fix get_core_clock_speed for G33 class desktop chips

commit 43bcd61fae05fc6062b4f117c5adb1a72c9f8c57 upstream.

Somehow the case for G33 got dropped while porting from ums code.
This made a 400MHz chip into a 133MHz one which resulted in the
unnecessary enabling of double wide pipe mode which in turn
screwed up the overlay code.

Nothing else (than the overlay code) seems to be affected.

This fixes fdo.org bug #24835

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

rtc-core: fix memory leak

commit 2a7a06a0cdd86d572e91657603180da5992be6d3 upstream.

The idr should be destroyed when the module is unloaded. Found with
kmemleak.

Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

SCSI: qla2xxx: Obtain proper host structure during response-queue processing.

commit a67093d46e3caed1a42d694a7de452b61db30562 upstream.

Original code incorrectly assumed only status-type-0
IOCBs would be queued to the response-queue, and thus all
entries would safely reference a VHA from the IOCB
'handle.'

Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/radeon: r6xx/r7xx possible security issue, system ram access

commit c8c15ff1e90bfc4a2db1ba77a01b3b2783e723fc upstream

This patch workaround a possible security issue which can allow
user to abuse drm on r6xx/r7xx hw to access any system ram memory.
This patch doesn't break userspace, it detect "valid" old use of
CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte
the address these registers are pointing to with the one of the
last color buffer. This workaround will work for old mesa &
xf86-video-ati and any old user which did use similar register
programming pattern as those (we expect that there is no others
user of those ioctl except possibly a malicious one). This patch
add a warning if it detects such usage, warning encourage people
to update their mesa & xf86-video-ati. New userspace will submit
proper relocation.

Fix for xf86-video-ati / mesa (this kernel patch is enough to
prevent abuse, fix for userspace are to set proper cs stream and
avoid kernel warning) :
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b
http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f

Abusing this register to perform system ram memory is not easy,
here is outline on how it could be achieve. First attacker must
have access to the drm device and be able to submit command stream
throught cs ioctl. Then attacker must build a proper command stream
for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to
overwrite the GPU GART which is in VRAM. To achieve so attacker
as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point
to the GPU GART, then it has to find a way to write predictable
value into those buffer (with little cleverness i believe this
can be done but this is an hard task). Once attacker have such
program it can overwritte GPU GART to program GPU gart to point
anywhere in system memory. It then can reusse same method as he
used to reprogram GART to overwritte the system ram through the
GART mapping. In the process the attacker has to be carefull to
not overwritte any sensitive area of the GART table, like ring
or IB gart entry as it will more then likely lead to GPU lockup.
Bottom line is that i think it's very hard to use this flaw
to get system ram access but in theory one can achieve so.

Side note: I am not aware of anyone ever using the GPU as an
attack vector, nevertheless we take great care in the opensource
driver to try to detect and forbid malicious use of GPU. I don't
think the closed source driver are as cautious as we are.

[bwh: Adjusted context for 2.6.32]
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/radeon/kms: r600/r700 don't test ib if ib initialization fails

commit db96380ea26fcc31ab37189aedeabd12894b1431 upstream

If ib initialization failed don't try to test ib as it will result
in an oops (accessing NULL ib buffer ptr).

[bwh: Adjusted context for 2.6.32]
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/radeon/kms: Forbid creation of framebuffer with no valid GEM object

commit 7e71c9e2e7704ebf044d4a964e02fbd2098a173f upstream.

This will avoid oops if at later point the fb is use. Trying to create
a framebuffer with no valid GEM object is bogus and should be forbidden
as this patch does.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sky2: fix transmit DMA map leakage

[ Upstream commit f6815077e75c5b7f55b56fc3788e328514d4e72a ]

The book keeping structure for transmit always had the flags value
cleared so transmit DMA maps were never released correctly.
Based on patch by Jarek Poplawski, problem observed by Michael Breuer.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drivers/net: ks8851_mll ethernet network driver

[ Upstream commit aeedba8bd2cf2f6f7b45bc7853754a03bc926797 ]

Hello David Miller,

I fix a bug in ks8851_mll driver, which has existed since 2.6.32-rc6.

>From : David J. Choi <david.choi@micrel.com>

Fix a bug that the data pointers in the interrupt handler are set wrong, which is related with the 5th parameter of request_irq().

Signed-off-by: David J. Choi <david.choi@micrel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ipv6: conntrack: Add member of user to nf_ct_frag6_queue structure

[ Upstream commit c92b544bd5d8e7ed7d81c77bbecab6df2a95aa53 ]

The commit 0b5ccb2(title:ipv6: reassembly: use seperate reassembly queues for
conntrack and local delivery) has broken the saddr&&daddr member of
nf_ct_frag6_queue when creating new queue.  And then hash value
generated by nf_hashfn() was not equal with that generated by fq_find().
So, a new received fragment can't be inserted to right queue.

The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.

Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

inet: Remove bogus IGMPv3 report handling

[ Upstream commit c6b471e6454c0e1c6d756672841cbaeae7c949f8 ]

Currently we treat IGMPv3 reports as if it were an IGMPv2/v1 report.
This is broken as IGMPv3 reports are formatted differently.  So we
end up suppressing a bogus multicast group (which should be harmless
as long as the leading reserved field is zero).

In fact, IGMPv3 does not allow membership report suppression so
we should simply ignore IGMPv3 membership reports as a host.

This patch does exactly that.  I kept the case statement for it
so people won't accidentally add it back thinking that we overlooked
this case.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

net: bug fix for vlan + gro issue

[ Upstream commit e76b69cc0133952c98aa1ad6330cacacd269fd64 ]

Traffic (tcp) doesnot start on a vlan interface when gro is enabled.
Even the tcp handshake was not taking place.
This is because, the eth_type_trans call before the netif_receive_skb
in napi_gro_finish() resets the skb->dev to napi->dev from the previously
set vlan netdev interface. This causes the ip_route_input to drop the
incoming packet considering it as a packet coming from a martian source.

I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7.
With this fix, the traffic starts and the test runs fine on both vlan
and non-vlan interfaces.

CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

net-sysfs: Use rtnl_trylock in wireless sysfs methods.

[ Upstream commit b8afe6416101549e877f8470f2a160df69676166 ]

The wireless sysfs methods like the rest of the networking sysfs
methods are removed with the rtnl_lock held and block until
the existing methods stop executing.  So use rtnl_trylock
and restart_syscall so that the code continues to work.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

net: Fix sysctl restarts...

[ Upstream commit 88af182e389097997c5e2a0b42285b3522796759 ]

Yuck.  It turns out that when we restart sysctls we were restarting
with the values already changed.  Which unfortunately meant that
the second time through we thought there was no change and skipped
all kinds of work, despite the fact that there was indeed a change.

I have fixed this the simplest way possible by restoring the changed
values when we restart the sysctl write.

One of my coworkers spotted this bug when after disabling forwarding
on an interface pings were still forwarded.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sparc64: Fix sun4u execute bit check in TSB I-TLB load.

[ Upstream commit 1f474646fdc36b457606bbcd6a3592e6cbd31ac4 ]

Thanks to testcase and report from Brad Spengler:

--------------------
#include <stdio.h>

typedef int (* _wee)(void);

int main(void)
{
        char buf[8] = { '\x81', '\xc7', '\xe0', '\x08', '\x81', '\xe8',
                        '\x00', '\x00' };
        _wee wee;
        printf("%p\n", &buf);
        wee = (_wee)&buf;
        wee();

        return 0;
}
--------------------

TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U bit,
but that's bit 12 so it gets sign extended all the way up to bit 63
and the test nearly always passes as a result.

Use sethi to fix the bug.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sparc: leds_resource.end assigned to itself in clock_board_probe()

[ Upstream commit 093171465235a8482fbf08a9a2e365247e1f7dd5 ]

It should be a 1 byte region.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sparc32: Fix struct stat uid/gid types.

[ Upstream commit 2531be413b3f2f64c0282073de89fe52bbcbbab5 ]

Commit 085219f79cad89291699bd2bfb21c9fdabafe65f
("sparc32: use proper types in struct stat")

Accidently changed the struct stat uid/gid members
to uid_t and gid_t, but those get set to
__kernel_uid32_t and __kernel_gid32_t respectively.
Those are of type 'int' but the structure is meant
to have 'short'.  So use uid16_t and gid16_t to
correct this.

Reported-by: Rob Landley <rob@landley.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sparc32: Fix page_to_phys().

[ Upstream commit 8654164f54bd02787ae91db8526dcae8e7e34eeb ]

It doesn't account for phys_base like it should, fix by using
page_to_pfn().

While we're here, make virt_to_page() use pfn_to_page() as well, so we
consistently use the asm/memory-model.h abstractions instead of
open-coding memory model assumptions.

Tested-by: Kristoffer Glembo <kristoffer@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

sparc: Align clone and signal stacks to 16 bytes.

[ Upstream commits f036d9f3985a529a81e582f68aa984eb7b20d54d
  and 440ab7ac2d6b735fb278a1ff1674f6716314c6bb ]

This is mandatory for 64-bit processes, and doing it also for 32-bit
processes saves a conditional in the compat case.

This fixes the glibc/nptl/tst-stdio1 test case, as well
as many others, on 64-bit.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Switch proc/self to nd_set_link()

commit 7fee4868be91e71a3ee8e57289ebf5e10a12297e upstream.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

idr: fix a critical misallocation bug, take#2

commit d2e7276b6b5e4bc2148891a056d5862c5314342d upstream.

This is retry of reverted 859ddf09743a8cc680af33f7259ccd0fd36bfe9d
("idr: fix a critical misallocation bug") which contained two bugs.

* pa[idp->layers] should be cleared even if it's not used by
  sub_alloc() because it's used by mark idr_mark_full().

* The original condition check also assigned pa[l] to p which the new
  code didn't do thus leaving p pointing at the wrong layer.

Both problems have been fixed and the idr code has received good amount
testing using userland testing setup where simple bitmap allocator is
run parallel to verify the result of idr allocation.

The bug this patch fixes is caused by sub_alloc() optimization path
bypassing out-of-room condition check and restarting allocation loop
with starting value higher than maximum allowed value.  For detailed
description, please read commit message of 859ddf09.

Signed-off-by: Tejun Heo <tj@kernel.org>
Based-on-patch-from: Eric Paris <eparis@redhat.com>
Reported-by: Eric Paris <eparis@redhat.com>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

airo: fix setting zero length WEP key

commit f09c256375c7cf1e112b8ef6306cdd313490d7c0 upstream.

Patch prevents call set_wep_key() with zero key length. That fix long
standing regression since commit c0380693520b1a1e4f756799a0edc379378b462a
"airo: clean up WEP key operations". Additionally print call trace when
someone will try to use improper parameters, and remove key.len = 0
assignment, because it is in not possible code path.

Reported-by: Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu>
Bisected-by: Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu>
Tested-by: Chris Siebenmann <cks@cs.toronto.edu>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

HID: usbhid: introduce timeout for stuck ctrl/out URBs

commit 858155fbcc0cd713f6382c527bb1c3abc0ed6d00 upstream.

Some devices do not react to a control request (seen on APC UPS's) resulting in
a slow stream of messages, "generic-usb ... control queue full".  Therefore
request needs a timeout.

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David Fries <david@fries.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

HID: add multi-input quirk for NextWindow Touchscreen.

commit 9db630b48a99adb4156e205b812fba8959644280 upstream.

These touchscreens are mounted onto HP TouchSmart and the Dell Studio One
19. Without a quirk they report a wrong button set and the x/y coordinates
through ABS_Z/ABS_RX, confusing the higher levels (most notably X.Org's
evdev driver).

Device id 0x003 covers models 1900, 2150, and 2700 [1] though testing could
only be performed on a model 1900.

[1] http://www.nextwindow.com/nextwindow_support/latest_tech_info.html

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

HID: remove TENX iBuddy from blacklist

commit 4bb9508bbbb06f10bc3e249dd34375b4a4d6bfc0 upstream.

There were multiple reports which indicate that vendor messed up horribly
and the same VID/PID combination is used for completely different devices,
some of them requiring the blacklist entry and other not.

Remove the blacklist entry for this combination of VID/PID completely, and let
the user decide and unbind the driver via sysfs eventually, if needed. Proper
fix would be fixing the vendor.

References:

http://lkml.org/lkml/2009/2/10/434
http://bugzilla.kernel.org/show_bug.cgi?id=13411

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

readahead: introduce FMODE_RANDOM for POSIX_FADV_RANDOM

commit 0141450f66c3c12a3aaa869748caa64241885cdf upstream.

This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM.

POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor performance:
a 16K read will be carried out in 4 _sync_ 1-page reads.

In other places, ra_pages==0 means
- it's ramfs/tmpfs/hugetlbfs/sysfs/configfs
- some IO error happened
where multi-page read IO won't help or should be avoided.

POSIX_FADV_RANDOM actually want a different semantics: to disable the
*heuristic* readahead algorithm, and to use a dumb one which faithfully
submit read IO for whatever application requests.

So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM.

Note that the random hint is not likely to help random reads performance
noticeably.  And it may be too permissive on huge request size (its IO
size is not limited by read_ahead_kb).

In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall
(NFS read) performance of the application increased by 313%!

Tested-by: Quentin Barnes <qbarnes+nfs@yahoo-inc.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: <qbarnes+nfs@yahoo-inc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

vfs: take f_lock on modifying f_mode after open time

commit 42e49608683ab25fbbbf9c40edb944601e543882 upstream.

We'll introduce FMODE_RANDOM which will be runtime modified.  So protect
all runtime modification to f_mode with f_lock to avoid races.

Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

V4L/DVB (13991): gspca_mr973010a: Fix cif type 1 cameras not streaming on UHCI controllers

commit 70136081fc67ea77d849f86fa323e5773c8e40ea upstream.

If you read the mail to Oliver Neukum on the linux-usb list, then you know
that I found a cure for the mysterious problem that the MR97310a CIF "type
1" cameras have been freezing up and refusing to stream if hooked up to a
machine with a UHCI controller.

Namely, the cure is that if the camera is an mr97310a CIF type 1 camera, you
have to send it 0xa0, 0x00. Somehow, this is a timing reset command, or
such. It un-blocks whatever was previously stopping the CIF type 1 cameras
from working on the UHCI-based machines.

Signed-off-by: Theodore Kilgore <kilgota@auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

mac80211: quit addba_resp_timer if Tx BA session is torn down

commit 3dc1de0bf23816ed557ac8addf680cd5ee57e805 upstream.

Make addba_resp_timer aware the HT_AGG_STATE_REQ_STOP_BA_MSK mask
so that when ___ieee80211_stop_tx_ba_session() is issued the timer
will quit. Otherwise when suspend happens before the timer expired,
the timer handler will be called immediately after resume and
messes up driver status.

Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>