summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-12-08USB: EHCI: don't send Clear-TT-Buffer following a STALLAlan Stern
commit c2f6595fbdb408d3d6850cfae590c8fa93e27399 upstream. This patch (as1304) fixes a regression in ehci-hcd. Evidently some hubs don't handle Clear-TT-Buffer requests correctly, so we should avoid sending them when they don't appear to be absolutely necessary. The reported symptom is that output on a downstream audio device cuts out because the hub stops relaying isochronous packets. The patch prevents Clear-TT-Buffer requests from being sent following a STALL handshake. In theory a STALL indicates either that the downstream device sent a STALL or that no matching TT buffer could be found. In either case, the transfer is completed and the TT buffer does not remain busy, so it doesn't need to be cleared. Also, the patch fixes a minor flaw in the code that actually sends the Clear-TT-Buffer requests. Although the pipe direction isn't really used for control transfers, it should be a Send rather than a Receive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Javier Kohen <jkohen@users.sourceforge.net> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08speedstep-ich: fix error caused by 394122ab144dae4b276d74644a2f11c44a60ac5cRusty Russell
commit 8dca15e40889e5d5e9655b03ba79c26200f760ce upstream. "[CPUFREQ] cpumask: avoid playing with cpus_allowed in speedstep-ich.c" changed the code to mistakenly pass the current cpu as the "processor" argument of speedstep_get_frequency(), whereas it should be the type of the processor. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14340 Based on a patch by Dave Mueller. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Dominik Brodowski <linux@brodo.de> Reported-by: Dave Mueller <dave.mueller@gmx.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08ipv4: additional update of dev_net(dev) to struct *net in ip_fragment.c, ↵David Ford
NULL ptr OOPS commit bbf31bf18d34caa87dd01f08bf713635593697f2 upstream. ipv4 ip_frag_reasm(), fully replace 'dev_net(dev)' with 'net', defined previously patched into 2.6.29. Between 2.6.28.10 and 2.6.29, net/ipv4/ip_fragment.c was patched, changing from dev_net(dev) to container_of(...). Unfortunately the goto section (out_fail) on oversized packets inside ip_frag_reasm() didn't get touched up as well. Oversized IP packets cause a NULL pointer dereference and immediate hang. I discovered this running openvasd and my previous email on this is titled: NULL pointer dereference at 2.6.32-rc8:net/ipv4/ip_fragment.c:566 Signed-off-by: David Ford <david@blue-labs.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (13314): saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150Michael Krufky
commit 22370ef5035f206283505409c9a64a595c5c7320 upstream. The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit to be set in order to function properly. This change will work on the early revisions on the board as well, but the final revision will not function without this change. Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (13313): saa7134: add support for FORCE_TS_VALID mode for mpeg ts inputMichael Krufky
commit 4007a672abd88091e3cced158ec491d41c0c454c upstream. When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input without requiring TS_VALID set high. This is required for some new boards to function properly, due to the hardware design implementation. The configuration is toggled within the board setup configuration. Boards that do not have this bit set will function as before with no change. Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (13202): smsusb: add autodetection support for three additional ↵Michael Krufky
Hauppauge USB IDs commit 78c948ab0cc44f9c8ae397d7d9d217bb498bfa2f upstream. Add support for three new Hauppauge Device USB IDs: 2040:b900 2040:b910 2040:c000 Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-08sched: Fix isolcpus boot optionRusty Russell
commit bdddd2963c0264c56f18043f6fa829d3c1d3d1c0 upstream. Anton Blanchard wrote: > We allocate and zero cpu_isolated_map after the isolcpus > __setup option has run. This means cpu_isolated_map always > ends up empty and if CPUMASK_OFFSTACK is enabled we write to a > cpumask that hasn't been allocated. I introduced this regression in 49557e620339cb13 (sched: Fix boot crash by zalloc()ing most of the cpu masks). Use the bootmem allocator if they set isolcpus=, otherwise allocate and zero like normal. Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: peterz@infradead.org Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <200912021409.17013.rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Anton Blanchard <anton@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08sched: Fix boot crash by zalloc()ing most of the cpu masksRusty Russell
commit 49557e620339cb134127b5bfbcfecc06b77d0232 upstream. I got a boot crash when forcing cpumasks offstack on 32 bit, because find_new_ilb() returned 3 on my UP system (nohz.cpu_mask wasn't zeroed). AFAICT the others need to be zeroed too: only nohz.ilb_grp_nohz_mask is initialized before use. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Peter Zijlstra <peterz@infradead.org> LKML-Reference: <200911022037.21282.rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08sparc: Move of_set_property_mutex acquisition outside of devtree_lock grab.David S. Miller
[ Upstream commit 1c9d80ddc60f8ac26344ec3db9830e5f8016c16d ] Otherwise we try to sleep with preemption disabled, etc. Noticed by Thomas Gleixner. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08sparc64: replace parentheses in pmul()Roel Kluin
[ Upstream commit 88b938e63e68fd35e603421f722be0f35dde1016 ] `>>' has a higher precedence than `?' so src2 evaluated to either 16 or 0 dependent on the bits set in rs2. 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>
2009-12-08sfc: Set ip_summed correctly for page buffers passed to GROBen Hutchings
[ Upstream commit 345056af41feeda506a8993474b9cbb2c66bc9fb ] Page buffers containing packets with an incorrect checksum or using a protocol not handled by hardware checksum offload were previously not passed to LRO. The conversion to GRO changed this, but did not set the ip_summed value accordingly. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08bonding: Modify hash transmit policies to use the packet's source MAC addressJasper Spaans
[ Upstream commit d3da68310a2cf934c2ea8a99a519d8b1ccca4c56 ] Modify bonding hash transmit policies to use the psource MAC address of the packet instead of the MAC address configured for the bonding device. The old sitation conflicts with the documentation. Signed-off-by: Jasper Spaans <spaans@fox-it.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08net: fix sk_forward_alloc corruptionEric Dumazet
[ Upstream commit: 9d410c796067686b1e032d54ce475b7055537138 ] On UDP sockets, we must call skb_free_datagram() with socket locked, or risk sk_forward_alloc corruption. This requirement is not respected in SUNRPC. Add a convenient helper, skb_free_datagram_locked() and use it in SUNRPC Reported-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08pkt_sched: pedit use proper structJamal Hadi Salim
[ Upstream commit 53f7e35f8b7fc2f5620a863ac613bcf3080cb6ba ] This probably deserves to go into -stable. Pedit will reject a policy that is large because it uses the wrong structure in the policy validation. This fixes it. Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08acenic: Pass up error code from ace_load_firmware()Ben Hutchings
[ Upstream commit 6c60e0c30c80fcd53e61701b7865a85283f8a341 ] If ace_load_firmware() fails, ace_init() cleans up but still returns 0, leading to an oops as seen in <http://bugs.debian.org/521383>. It should pass the error code up. 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>
2009-12-08udp: Fix udp_poll() and ioctl()Eric Dumazet
[ Upstream commit 85584672012ee0c3b7b8e033a1ecf7c11878e45f ] udp_poll() can in some circumstances drop frames with incorrect checksums. Problem is we now have to lock the socket while dropping frames, or risk sk_forward corruption. This bug is present since commit 95766fff6b9a78d1 ([UDP]: Add memory accounting.) While we are at it, we can correct ioctl(SIOCINQ) to also drop bad frames. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08drm/i915: Fix IRQ stall issue on IronlakeNanhai Zou
commit 2d109a845dd3074885db726892c629ab73dd0ed8 upstream. The master irq control in DE must be disabled before irq handling, and enable after the process. This fixes the irq stall issue on Ironlake. Signed-off-by: Nanhai Zou <nanhai.zou@intel.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>
2009-12-08drm: work around EDIDs with bad htotal/vtotal valuesJesse Barnes
commit 7064fef56369c9e2c6e35ff6d6b4b63d42a859ce upstream. We did this on the userspace side, but we need a similar fix for the kernel. Fixes LP #460664. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08drm/i915: Select CONFIG_SHMEMChris Wilson
commit ca9ab10033d190c1ede85fdf456307bdfdabf079 upstream. The driver requires shmfs as the backing filesystem to handle the buffer objects, so ensure it is selected if the user chooses to build our driver. Fixes: Bug 14662 - Dell E5500 kernel panic with KMS http://bugzilla.kernel.org/show_bug.cgi?id=14662 The revealing nature of the panic is the NULL function pointer dereference in read_cache_page_async(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12696): gspca - sonixj / sn9c102: Two drivers for 0c45:60fc and ↵Jean-Francois Moine
0c45:613e. commit f077b0a64856c5b3bf346ae9fba8631c1fb210cf upstream. Let 0c45:60fc in sn9c102 and 0c45:613e in gspca-sonixj (sensor not supported). Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12691): gspca - sonixj: Don't use mdelay().Jean-Francois Moine
commit 1f78a976ce18bc98e8b509cee04c5b3756098614 upstream. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12501): gspca - sonixj: Do the ov7660 sensor work again.Jean-Francois Moine
commit 47f7f6fb7949b6546baf4b6f26bf0ca075d12759 upstream. - bad sensor power - bad edge gain/threshold - set back the auto gain - light frequency filter inverted Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12356): gspca - sonixj: Webcam 0c45:6148 addedDenis Loginov
commit 6baefab531b22288be3b4ddef5671ea6469b09f8 upstream. Signed-off-by: Denis Loginov <dinvlad@gmail.com> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12280): gspca - sonixj: Remove auto gain/wb/expo for the ov7660 sensor.Jean-Francois Moine
commit d8f400efc1ef7b344e07590fb6b77431bc358ba0 upstream. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (12948): v4l1-compat: fix VIDIOC_G_STD handlingHans Verkuil
commit 707ca1e30f087f9a6d144693dafc4b67880678c2 upstream. The VIDIOC_G_STD ioctl may not be present in the case of radio receivers. In that case G_STD will return an error. The v4l1-compat layer should not attempt to propagate that error to the caller, instead it should be ignored. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (13321): radio-gemtek-pci: fix double mutex_lockHans Verkuil
commit 3addbb8075c00e2a2408c192bd1002dead26b2aa upstream. Double mutexlock found by the Linux Driver Verification project and reported by Alexander Strakh. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08V4L/DVB (13436): cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 ↵Robert Lowery
(rev 1) commit 0bc3518019f917a370935055f07698a4e9b3ea20 upstream. Address yet another regression introduced by the introduction of the zl10353 disable_i2c_gate field. djh - I unmangled the patch which apparently got screwed up in the user's email client. Signed-off-by: Robert Lowery <rglowery@exemail.com.au> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08Enable ACPI PDC handshake for VIA/Centaur CPUsHarald Welte
commit d77b81974521c82fa6fda38dfff1b491dcc62a32 upstream. In commit 0de51088e6a82bc8413d3ca9e28bbca2788b5b53, we introduced the use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for VENDOR_INTEL. However, as it turns out, at least the Nano CPU's also need the PDC (processor driver capabilities) handshake in order to activate the methods required for acpi-cpufreq. Since arch_acpi_processor_init_pdc() contains another vendor check for Intel, the PDC is not initialized on VIA CPU's. The resulting behavior of a current mainline kernel on such systems is: acpi-cpufreq loads and it indicates CPU frequency changes. However, the CPU stays at a single frequency This trivial patch ensures that init_intel_pdc() is called on Intel and VIA/Centaur CPU's alike. Signed-off-by: Harald Welte <HaraldWelte@viatech.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08thinkpad-acpi: fix sign of ERESTARTSYS returnRoel Kluin
commit 80a8d1228e90349b4514e8c925c061fa5cbcea75 upstream. The returned error should be negative Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08rfkill: fix miscdev opsJohannes Berg
commit 45ba564d765d6165330e9bb14a197bdd348c114d upstream. The /dev/rfkill ops don't refer to the module, so it is possible to unload the module while file descriptors are open. Fix this oversight. Reported-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08b43: Work around mac80211 race conditionLarry Finger
commit 18c6951091eca7645005a71b556106cc99a6f4b1 upstream. As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497, mac80211 has a bug that allows a call to the TX routine after the queues have been stopped. This situation will only occur under extreme stress. Although b43 does not crash when this condition occurs, it does generate a WARN_ON and also logs a queue overrun message. This patch recognizes b43 is not at fault and logs a message only when the most verbose debugging mode is enabled. In the unlikely event that the queue is not stopped when the DMA queue becomes full, then a warning is issued. During testing of this patch with one output stream running repeated tcpperf writes and a second running a flood ping, this routine was entered with the DMA ring stopped about once per hour. The condition where the DMA queue is full but the ring has not been stopped has never been seen by me. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08mac80211: fix spurious delBA handlingJohannes Berg
commit 827d42c9ac91ddd728e4f4a31fefb906ef2ceff7 upstream. Lennert Buytenhek noticed that delBA handling in mac80211 was broken and has remotely triggerable problems, some of which are due to some code shuffling I did that ended up changing the order in which things were done -- this was commit d75636ef9c1af224f1097941879d5a8db7cd04e5 Author: Johannes Berg <johannes@sipsolutions.net> Date: Tue Feb 10 21:25:53 2009 +0100 mac80211: RX aggregation: clean up stop session and other parts were already present in the original commit d92684e66091c0f0101819619b315b4bb8b5bcc5 Author: Ron Rindjunsky <ron.rindjunsky@intel.com> Date: Mon Jan 28 14:07:22 2008 +0200 mac80211: A-MPDU Tx add delBA from recipient support The first problem is that I moved a BUG_ON before various checks -- thereby making it possible to hit. As the comment indicates, the BUG_ON can be removed since the ampdu_action callback must already exist when the state is != IDLE. The second problem isn't easily exploitable but there's a race condition due to unconditionally setting the state to OPERATIONAL when a delBA frame is received, even when no aggregation session was ever initiated. All the drivers accept stopping the session even then, but that opens a race window where crashes could happen before the driver accepts it. Right now, a WARN_ON may happen with non-HT drivers, while the race opens only for HT drivers. For this case, there are two things necessary to fix it: 1) don't process spurious delBA frames, and be more careful about the session state; don't drop the lock 2) HT drivers need to be prepared to handle a session stop even before the session was really started -- this is true for all drivers (that support aggregation) but iwlwifi which can be fixed easily. The other HT drivers (ath9k and ar9170) are behaving properly already. Reported-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08mac80211: fix two remote exploitsJohannes Berg
commit 4253119acf412fd686ef4bd8749b5a4d70ea3a51 upstream. Lennert Buytenhek noticed a remotely triggerable problem in mac80211, which is due to some code shuffling I did that ended up changing the order in which things were done -- this was in commit d75636ef9c1af224f1097941879d5a8db7cd04e5 Author: Johannes Berg <johannes@sipsolutions.net> Date: Tue Feb 10 21:25:53 2009 +0100 mac80211: RX aggregation: clean up stop session The problem is that the BUG_ON moved before the various checks, and as such can be triggered. As the comment indicates, the BUG_ON can be removed since the ampdu_action callback must already exist when the state is OPERATIONAL. A similar code path leads to a WARN_ON in ieee80211_stop_tx_ba_session, which can also be removed. Cc: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08ASoC: AIC23: Fixing infinite loop in resume pathAnuj Aggarwal
commit e9ff5eb2ae018fe2298c68746c873bf828c6b10e upstream. This patch fixes two issues: a) Infinite loop in resume function b) Writes to non-existing registers in resume function Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> 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>
2009-12-08ASoC: Fix suspend with active audio streamsMark Brown
commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829 upstream. When we get a stream suspend event force the power down since otherwise the stream would remain marked as active. In future we'll probably want to make this stream-specific and add an interface to make the power down of other widgets optional in order to support leaving bypass paths active while suspending the processor. Reported-by: Joonyoung Shim <jy0922.shim@samsung.com> Tested-by: Joonyoung Shim <jy0922.shim@samsung.com> 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>
2009-12-08fuse: reject O_DIRECT flag also in fuse_createCsaba Henk
commit 1b7323965a8c6eee9dc4e345a7ae4bff1dc93149 upstream. The comment in fuse_open about O_DIRECT: "VFS checks this, but only _after_ ->open()" also holds for fuse_create, however, the same kind of check was missing there. As an impact of this bug, open(newfile, O_RDWR|O_CREAT|O_DIRECT) fails, but a stub newfile will remain if the fuse server handled the implied FUSE_CREATE request appropriately. Other impact: in the above situation ima_file_free() will complain to open/free imbalance if CONFIG_IMA is set. Signed-off-by: Csaba Henk <csaba@gluster.com> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: Harshavardhana <harsha@gluster.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08NFSv4: Fix a cache validation bug which causes getcwd() to return ENOENTTrond Myklebust
commit 96d25e532234bec1a1989e6e1baf702d43a78b0d upstream. Changeset a65318bf3afc93ce49227e849d213799b072c5fd (NFSv4: Simplify some cache consistency post-op GETATTRs) incorrectly changed the getattr bitmap for readdir(). This causes the readdir() function to fail to return a fileid/inode number, which again exposed a bug in the NFS readdir code that causes spurious ENOENT errors to appear in applications (see http://bugzilla.kernel.org/show_bug.cgi?id=14541). The immediate band aid is to revert the incorrect bitmap change, but more long term, we should change the NFS readdir code to cope with the fact that NFSv4 servers are not required to support fileids/inode numbers. Reported-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08ima: replace GFP_KERNEL with GFP_NOFSMimi Zohar
commit c09c59e6a070d6af05f238f255aea268185273ef upstream. While running fsstress tests on the NFSv4 mounted ext3 and ext4 filesystem, the following call trace was generated on the nfs server machine. Replace GFP_KERNEL with GFP_NOFS in ima_iint_insert() to avoid a potential deadlock. ================================= [ INFO: inconsistent lock state ] 2.6.31-31.el6.x86_64 #1 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd2/75 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: [<ffffffff811edd5e>] jbd2_journal_start+0xfe/0x13f {RECLAIM_FS-ON-W} state was registered at: [<ffffffff81091e40>] mark_held_locks+0x65/0x99 [<ffffffff81091f31>] lockdep_trace_alloc+0xbd/0xf5 [<ffffffff81126fdd>] kmem_cache_alloc+0x40/0x185 [<ffffffff812344d7>] ima_iint_insert+0x3d/0xf1 [<ffffffff812345b0>] ima_inode_alloc+0x25/0x44 [<ffffffff811484ac>] inode_init_always+0xec/0x271 [<ffffffff81148682>] alloc_inode+0x51/0xa1 [<ffffffff81148700>] new_inode+0x2e/0x94 [<ffffffff811b2f08>] ext4_new_inode+0xb8/0xdc9 [<ffffffff811be611>] ext4_create+0xcf/0x175 [<ffffffff8113e2cd>] vfs_create+0x82/0xb8 [<ffffffff8113f337>] do_filp_open+0x32c/0x9ee [<ffffffff811309b9>] do_sys_open+0x6c/0x12c [<ffffffff81130adc>] sys_open+0x2e/0x44 [<ffffffff81011e42>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff irq event stamp: 90371 hardirqs last enabled at (90371): [<ffffffff8112708d>] kmem_cache_alloc+0xf0/0x185 hardirqs last disabled at (90370): [<ffffffff81127026>] kmem_cache_alloc+0x89/0x185 softirqs last enabled at (89492): [<ffffffff81068ecf>] __do_softirq+0x1bf/0x1eb softirqs last disabled at (89477): [<ffffffff8101312c>] call_softirq+0x1c/0x30 other info that might help us debug this: 2 locks held by kswapd2/75: #0: (shrinker_rwsem){++++..}, at: [<ffffffff810f98ba>] shrink_slab+0x44/0x177 #1: (&type->s_umount_key#25){++++..}, at: [<ffffffff811450ba>] Reported-by: Muni P. Beerakam <mbeeraka@in.ibm.com> Reported-by: Amit K. Arora <amitarora@in.ibm.com> Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08iwlwifi: Fix issue on file transfer stalled in HT modeWey-Yi Guy
commit d01032e4fd33110f9f3a085a36cb819c1dfc5827 upstream Turn on RTS/CTS for HT to prevent uCode TX fifo underrun This is fix for http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2103 Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Tested-by: Jiajia Zheng <jiajia.zheng@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08iwlwifi: Use RTS/CTS as the preferred protection mechanism for 6000 seriesWey-Yi Guy
commit 73871f7181a1406c67e93c8c83f5edb26057a2a6 upstream When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field in the HT Information Element to determine whether or not to use protection. The Operating Mode field has 4 possible settings: 0-3: Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT stations in a 20 MHz BSS Mode 1: used if there are non-HT stations or APs using the primary or secondary channels Mode 2: if only HT stations are associated in the BSS and at least one 20 MHz HT station is associated. Mode 3: used if one or more non-HT stations are associated in the BSS. When in operating modes 1 or 3, and the Use_Protection field is 1 in the Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or CTS-to-Self. By default, CTS-to-self is the preferred protection mechanism for less overhead and higher throughput; but using the full RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment. For 6000 series WIFI NIC, RTS/CTS protection mechanism is the recommended choice for HT traffic based on the HW design. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: xhci: Fix scratchpad deallocation.Sarah Sharp
commit 5294bea40666db5c5d6c336b8e4e55d69fa576ca upstream. The scratchpad_free() function uses xhci->page_size to free some memory with pci_free_consistent(). However, the page_size is set to zero before the call, causing kernel oopses on driver unload. Call scratchpad_free() before setting xhci->page_size to zero. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: John Youn <John.Youn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: xhci: Fix TRB physical to virtual address translation.Sarah Sharp
commit 2fa88daa6f299bfb83672c3b525d786ad03b4735 upstream. The trb_in_td() function in the xHCI driver is supposed to translate a physical transfer buffer request (TRB) into a virtual pointer to the ring segment that TRB is in. Unfortunately, a mistake in this function may cause endless loops as the driver searches through the linked list of ring segments over and over again. Fix a couple bugs that may lead to loops or bad output: 1. Bail out if we get a NULL pointer when translating the segment's private structure and the starting DMA address of the segment chunk. If this happens, we've been handed a starting TRB pointer from a different ring. 2. Make sure the function works when there's multiple segments in the ring. In the while loop to search through the ring segments, use the current segment variable (cur_seg), rather than the starting segment variable (start_seg) that is passed in. 3. Stop searching the ring if we've run through all the segments in the ring. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: xhci: Fix bug memory free after failed initialization.Sarah Sharp
commit d94c05e33d9212ee67b8d4998f984cc71df8168b upstream. If the xHCI driver fails during the memory initialization, xhci->ir_set may not be a valid pointer. Check that it points to valid DMA'able memory before writing to that address during the memory freeing process. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: cdc_acm: Fix race condition when opening ttyHenry Gebhardt
commit 18a77b5d237a67d2c621a46f5271a3b51da1b380 upstream. If acm_rx_tasklet() gets called before tty_port_block_til_ready() returns, then bulk IN urbs may not be sent. This fixes it. Signed-off-by: Henry Gebhardt <gebhardt@astro.uni-tuebingen.de> Acked-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: option.c: add support for D-Link DWM-162-U5Zhang Le
commit ff854ce0b17161a86b5ae444c6cb0aa221720fab upstream. Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device has 4 interfaces, of which 1 is handled by storage and the other 3 by option driver. The device appears first as CD-only 05c6:2100 device and must be switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch. The MessageContent for usb_modeswitch.conf is: "55534243e0c26a85000000000000061b000000020000000000000000000000" Signed-off-by: Zhang Le <r0bertz@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: usbmon: fix bug in mon_buff_area_shrinkAlan Stern
commit fca94748c5136ff390eadc443871b82f1f77dcd6 upstream. This patch (as1299b) fixes a bug in an error-handling path of usbmon's binary interface. The storage area for URB data is divided into fixed-size blocks. If an URB's data can't be copied, the area reserved for it should be decreased to the size of the truncated information (rounded up to a block boundary). Rounding up the amount to be removed and subtracting it from the reserved size is definitely the wrong thing to do. Also, when the data for an isochronous URB can't be copied, we can still copy the isoc packet descriptors. In fact the current code does copy the descriptors, but then sets the capture length to 0 so they remain inaccessible. The capture length should be reduced to the length of the descriptors, not set to 0. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08USB: ohci: quirk AMD prefetch for USB 1.1 ISO transferLibin Yang
commit a1f17a872bc7b1cb7efdd5486a2963e88a536e61 upstream. The following patch in the driver is required to avoid USB 1.1 device failures that may occur due to requests from USB OHCI controllers may be overwritten if the latency for any pending request by the USB controller is very long (in the range of milliseconds). Signed-off-by: Libin Yang <libin.yang@amd.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08tty: cp210x: Fix carrier handlingAlan Cox
commit d94c7bd4c1361cab58a21d530078c5673863dcc2 upstream. Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 9a68e39d4a701fb3be03cae9b462408664ebd205 broke carrier handling so that a cp210x setup which needed the carrier lines set up (non CLOCAL) which did not make a call which set the termios bits left the lines down even if CLOCAL was not asserted. Fix this not by reverting but by adding the proper dtr_rts and carrier_raised methods. This both sets the modem lines properly and also implements the correct blocking semantics for the port as required by POSIX. Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Karl Hiramoto <karl@hiramoto.org> Tested-by: Karl Hiramoto <karl@hiramoto.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08tty_port: If we are opened non blocking we still need to raise the carrierAlan Cox
commit 4175f3e31cc7157669aa66d46dc79de6ae0126ce upstream. Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 The tty_port code inherited a bug common to various drivers it was based upon. If the tty is opened O_NONBLOCK we do not wait for the carrier to be raised but we must still raise our modem lines if appropriate. (There is a second question here about whether we should do so if CLOCAL is set but that can wait) Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Karl Hiramoto <karl@hiramoto.org> Tested-by: Karl Hiramoto <karl@hiramoto.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08page allocator: always wake kswapd when restarting an allocation attempt ↵Mel Gorman
after direct reclaim failed commit cc4a6851466039a8a688c843962a05689059ff3b upstream. If a direct reclaim makes no forward progress, it considers whether it should go OOM or not. Whether OOM is triggered or not, it may retry the allocation afterwards. In times past, this would always wake kswapd as well but currently, kswapd is not woken up after direct reclaim fails. For order-0 allocations, this makes little difference but if there is a heavy mix of higher-order allocations that direct reclaim is failing for, it might mean that kswapd is not rewoken for higher orders as much as it did previously. This patch wakes up kswapd when an allocation is being retried after a direct reclaim failure. It would be expected that kswapd is already awake, but this has the effect of telling kswapd to reclaim at the higher order as well. Signed-off-by: Mel Gorman <mel@csn.ul.ie> Reviewed-by: Christoph Lameter <cl@linux-foundation.org> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-08 01:42:09 +0000