summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2012-11-26Revert "serial: omap: fix software flow control"Felipe Balbi1-6/+6
commit a4f743851f74fc3e0cc40c13082e65c24139f481 upstream. This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Signed-off-by: Felipe Balbi <balbi@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Andreas Bießmann <andreas.devel@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26ACPI video: Ignore errors after _DOD evaluation.Igor Murzov1-4/+7
commit fba4e087361605d1eed63343bb08811f097c83ee upstream. There are systems where video module known to work fine regardless of broken _DOD and ignoring returned value here doesn't cause any issues later. This should fix brightness controls on some laptops. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47861 Signed-off-by: Igor Murzov <e-mail@date.by> Reviewed-by: Sergey V <sftp.mtuci@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
2012-11-26rbd: Fix ceph_snap_context size calculationYan, Zheng1-1/+1
(cherry picked from commit f9f9a1904467816452fc70740165030e84c2c659) ceph_snap_context->snaps is an u64 array Signed-off-by: Zheng Yan <zheng.z.yan@intel.com> Reviewed-by: Alex Elder <elder@inktank.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26rbd: store snapshot id instead of indexJosh Durgin1-22/+5
(cherry picked from commit 77dfe99fe3cb0b2b0545e19e2d57b7a9134ee3c0) When a device was open at a snapshot, and snapshots were deleted or added, data from the wrong snapshot could be read. Instead of assuming the snap context is constant, store the actual snap id when the device is initialized, and rely on the OSDs to signal an error if we try reading from a snapshot that was deleted. Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com> Reviewed-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Yehuda Sadeh <yehuda@hq.newdream.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26rbd: protect read of snapshot sequence numberJosh Durgin1-1/+3
(cherry picked from commit 403f24d3d51760a8b9368d595fa5f48c309f1a0f) This is updated whenever a snapshot is added or deleted, and the snapc pointer is changed with every refresh of the header. Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com> Reviewed-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Yehuda Sadeh <yehuda@hq.newdream.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26rbd: don't hold spinlock during messenger flushAlex Elder1-2/+2
(cherry picked from commit cd9d9f5df6098c50726200d4185e9e8da32785b3) A recent change made changes to the rbd_client_list be protected by a spinlock. Unfortunately in rbd_put_client(), the lock is taken before possibly dropping the last reference to an rbd_client, and on the last reference that eventually calls flush_workqueue() which can sleep. The problem was flagged by a debug spinlock warning: BUG: spinlock wrong CPU on CPU#3, rbd/27814 The solution is to move the spinlock acquisition and release inside rbd_client_release(), which is the spot where it's really needed for protecting the removal of the rbd_client from the client list. Signed-off-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Sage Weil <sage@newdream.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26drm/i915: fix overlay on i830MDaniel Vetter1-3/+11
commit a9193983f4f292a82a00c72971c17ec0ee8c6c15 upstream. The overlay on the i830M has a peculiar failure mode: It works the first time around after boot-up, but consistenly hangs the second time it's used. Chris Wilson has dug out a nice errata: "1.5.12 Clock Gating Disable for Display Register Address Offset: 06200h–06203h "Bit 3 Ovrunit Clock Gating Disable. 0 = Clock gating controlled by unit enabling logic 1 = Disable clock gating function DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." Now I've nowhere found that 0xc8 register and hence couldn't apply the l2 cache workaround. But I've remembered that part of the magic that the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache allocations so that the overlay scaler has some scratch space. And while pondering how that could explain the hang the 2nd time we enable the overlay, I've remembered that the old ums overlay code did _not_ issue the OVERLAY_OFF cmd. And indeed, disabling the OFF cmd results in the overlay working flawlessly, so I guess we can workaround the lack of the above workaround by simply never disabling the overlay engine once it's enabled. Note that we have the first part of the above w/a already implemented in i830_init_clock_gating - leave that as-is to avoid surprises. v2: Add a comment in the code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827 Tested-by: Rhys <rhyspuk@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - Adjust context - s/intel_ring_emit(ring, /OUT_RING(/] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26sky2: Fix for interrupt handlerMirko Lindner1-1/+3
commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream. Re-enable interrupts if it is not our interrupt Signed-off-by: Mirko Lindner <mlindner@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26usb: use usb_serial_put in usb_serial_probe errorsJan Safrata1-3/+3
commit 0658a3366db7e27fa32c12e886230bb58c414c92 upstream. The use of kfree(serial) in error cases of usb_serial_probe was invalid - usb_serial structure allocated in create_serial() gets reference of usb_device that needs to be put, so we need to use usb_serial_put() instead of simple kfree(). Signed-off-by: Jan Safrata <jan.nikitenko@gmail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Cc: Richard Retanubun <richardretanubun@ruggedcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26r8169: allow multicast packets on sub-8168f chipset.Nathan Walp1-0/+3
commit 0481776b7a70f09acf7d9d97c288c3a8403fbfe4 upstream. RTL_GIGA_MAC_VER_35 includes no multicast hardware filter. Signed-off-by: Nathan Walp <faceprint@faceprint.com> Suggested-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26r8169: Fix WoL on RTL8168d/8111d.Cyril Brulebois1-0/+2
commit b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd upstream. This regression was spotted between Debian squeeze and Debian wheezy kernels (respectively based on 2.6.32 and 3.2). More info about Wake-on-LAN issues with Realtek's 816x chipsets can be found in the following thread: http://marc.info/?t=132079219400004 Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19; more chipsets are likely affected. Tested on top of a 3.2.23 kernel. Reported-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr> Tested-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr> Hinted-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Cyril Brulebois <kibi@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26xen/events: fix RCU warning, or Call idle notifier after irq_enter()Mojiong Qiu1-1/+1
commit 772aebcefeff310f80e32b874988af0076cb799d upstream. exit_idle() should be called after irq_enter(), otherwise it throws: [ INFO: suspicious RCU usage. ] 3.6.5 #1 Not tainted ------------------------------- include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 1 RCU used illegally from extended quiescent state! 1 lock held by swapper/0/0: #0: (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140 stack backtrace: Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1 Call Trace: <IRQ> [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130 [<ffffffff810ea10c>] __atomic_notifier_call_chain+0x12c/0x140 [<ffffffff810e9fe0>] ? atomic_notifier_chain_unregister+0x90/0x90 [<ffffffff811216cd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810ea136>] atomic_notifier_call_chain+0x16/0x20 [<ffffffff810777c3>] exit_idle+0x43/0x50 [<ffffffff81568865>] xen_evtchn_do_upcall+0x25/0x50 [<ffffffff81aa690e>] xen_do_hypervisor_callback+0x1e/0x30 <EOI> [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20 [<ffffffff81075cfa>] ? default_idle+0xba/0x570 [<ffffffff810778af>] ? cpu_idle+0xdf/0x140 [<ffffffff81a4d881>] ? rest_init+0x135/0x144 [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8 [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a [<ffffffff82520356>] ? x86_64_start_reservations+0x131/0x135 [<ffffffff82524aca>] ? xen_start_kernel+0x465/0x46 Git commit 98ad1cc14a5c4fd658f9d72c6ba5c86dfd3ce0d5 Author: Frederic Weisbecker <fweisbec@gmail.com> Date: Fri Oct 7 18:22:09 2011 +0200 x86: Call idle notifier after irq_enter() did this, but it missed the Xen code. Signed-off-by: Mojiong Qiu <mjqiu@tencent.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26r8169: use unlimited DMA burst for TXMichal Schmidt1-1/+1
commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream. The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have a box where this prevents the interface from using the gigabit line to its full potential. This patch solves the problem by setting TX_DMA_BURST to unlimited. The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl (XID 0c900880). TSO is enabled. I used netperf (TCP_STREAM test) to measure the dependency of TX throughput on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024, '7'=unlimited). This chart shows the results: http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png Interesting points: - With the current DMA burst limit (1024): - at the default MTU=1500 I get only 842 Mbit/s. - when going from small MTU, the performance rises monotonically with increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's a sudden drop to 762 MBit/s from which the throughput rises monotonically again with further MTU increases. - With a smaller DMA burst limit (512): - there's a similar peak at MTU=1076 and another one at MTU=564. - With unlimited DMA burst: - at the default MTU=1500 I get nice 940 Mbit/s. - the throughput rises monotonically with increasing MTU with no strange peaks. Notice that the peaks occur at MTU sizes that are multiples of the DMA burst limit plus 52. Why 52? Because: 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52 The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too, except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes. CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B", i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs the smaller burst limit, or if any other versions have similar requirements. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26ttm: Clear the ttm page allocated from high memory zone correctlyZhao Yakui1-1/+4
commit ac207ed2471150e06af0afc76e4becc701fa2733 upstream. The TTM page can be allocated from high memory. In such case it is wrong to use the page_address(page) as the virtual address for the high memory page. bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50241 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26drm/radeon: fix logic error in atombios_encoders.cAlex Deucher1-1/+1
commit b9196395c905edec512dfd6690428084228c16ec upstream. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=50431 Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26USB: option: add Alcatel X220/X500D USB IDsDan Williams1-0/+2
commit c0bc3098871dd9b964f6b45ec1e4d70d87811744 upstream. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26USB: option: add Novatel E362 and Dell Wireless 5800 USB IDsDan Williams1-0/+7
commit fcb21645f1bd86d2be29baf48aa1b298de52ccc7 upstream. The Dell 5800 appears to be a simple rebrand of the Novatel E362. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26Revert "Staging: Android alarm: IOCTL command encoding fix"Colin Cross1-3/+1
commit d38e0e3fed4f58bcddef4dc93a591dfe2f651cb0 upstream. Commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 changed the ANDROID_ALARM_GET_TIME ioctls from IOW to IOR. While technically correct, the _IOC_DIR bits are ignored by alarm_ioctl, so the commit breaks a userspace ABI used by all existing Android devices for a purely cosmetic reason. Revert it. Cc: Dae S. Kim <dae@velatum.com> Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17USB: mos7840: remove unused variableJohan Hovold1-1/+0
Fix warning about unused variable introduced by commit e681b66f2e19fa ("USB: mos7840: remove invalid disconnect handling") upstream. A subsequent fix which removed the disconnect function got rid of the warning but that one was only backported to v3.6. Reported-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/i915: clear the entire sdvo infoframe bufferDaniel Vetter2-20/+44
commit b6e0e543f75729f207b9c72b0162ae61170635b2 upstream. Like in the case of native hdmi, which is fixed already in commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes we need to clear the entire sdvo buffer to avoid upsetting the display. Since infoframe buffer writing is now a bit more elaborate, extract it into it's own function. This will be useful if we ever get around to properly update the ELD for sdvo. Also #define proper names for the two buffer indexes with fixed usage. v2: Cite the right commit above, spotted by Paulo Zanoni. v3: I'm too stupid to paste the right commit. v4: Ben Hutchings noticed that I've failed to handle an underflow in my loop logic, breaking it for i >= length + 8. Since I've just lost C programmer license, use his solution. Also, make the frustrated 0-base buffer size a notch more clear. Reported-and-tested-by: Jürg Billeter <j@bitron.ch> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/i915: fixup infoframe support for sdvoDaniel Vetter2-4/+11
commit 81014b9d0b55fb0b48f26cd2a943359750d532db upstream. At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/radeon/si: add some missing regs to the VM reg checkerAlex Deucher2-0/+2
commit f418b88aad0c42b4caf4d79a0cf8d14a5d0a2284 upstream. This register is needed for streamout to work properly. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/radeon/cayman: add some missing regs to the VM reg checkerAlex Deucher2-0/+7
commit 860fe2f05fa2eacac84368e23547ec8cf3cc6652 upstream. These regs were being wronly rejected leading to rendering issues. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=56876 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memoryThomas Hellstrom1-1/+1
commit afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 upstream. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Dmitry Torokhov <dtor@vmware.com> Cc: linux-graphics-maintainer@vmware.com Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/vmwgfx: Fix hibernation device resetThomas Hellstrom1-0/+5
commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream. The device would not reset properly when resuming from hibernation. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Dmitry Torokhov <dtor@vmware.com> Cc: linux-graphics-maintainer@vmware.com Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17mmc: sdhci: fix NULL dereference in sdhci_request() tuningChris Ball1-10/+13
commit 14efd957209461bbdf285bf0d67e931955d04a4c upstream. Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning") introduced a NULL dereference at resume-time if an SD 3.0 host controller raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too. Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drivers/net/ethernet/nxp/lpc_eth.c: Call mdiobus_unregister before mdiobus_freePeter Senna Tschudin1-0/+1
[ Upstream commit 57c10b61c84bfed68b1b317d6f507a392724b9c4 ] Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0 Calling mdiobus_free without calling mdiobus_unregister causes BUG_ON(). This patch fixes the issue. The semantic patch that found this issue(http://coccinelle.lip6.fr/): // <smpl> @@ expression E; @@ ... when != mdiobus_unregister(E); + mdiobus_unregister(E); mdiobus_free(E); // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Tested-by: Roland Stigge <stigge@antcom.de> Tested-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17net: usb: Fix memory leak on Tx data pathHemant Kumar1-0/+3
[ Upstream commit 39707c2a3ba5011038b363f84d37c8a98d2d9db1 ] Driver anchors the tx urbs and defers the urb submission if a transmit request comes when the interface is suspended. Anchoring urb increments the urb reference count. These deferred urbs are later accessed by calling usb_get_from_anchor() for submission during interface resume. usb_get_from_anchor() unanchors the urb but urb reference count remains same. This causes the urb reference count to remain non-zero after usb_free_urb() gets called and urb never gets freed. Hence call usb_put_urb() after anchoring the urb to properly balance the reference count for these deferred urbs. Also, unanchor these deferred urbs during disconnect, to free them up. Signed-off-by: Hemant Kumar <hemantk@codeaurora.org> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17hwmon: (w83627ehf) Force initial bank selectionJean Delvare1-0/+1
commit 3300fb4f88688029fff8dfb9ec0734f6e4cba3e7 upstream. Don't assume bank 0 is selected at device probe time. This may not be the case. Force bank selection at first register access to guarantee that we read the right registers upon driver loading. Signed-off-by: Jean Delvare <khali@linux-fr.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm: restore open_count if drm_setup failsIlija Hadzic1-1/+4
commit 0f1cb1bd94a9c967cd4ad3de51cfdabe61eb5dcc upstream. If drm_setup (called at first open) fails, the whole open call has failed, so we should not keep the open_count incremented. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/udl: fix stride issues scanning out stride != width*bppDave Airlie3-8/+11
commit 3916e1d71b62b120888aa50bcc8d9a6200fc19a7 upstream. When buffer sharing with the i915 and using a 1680x1050 monitor, the i915 gives is a 6912 buffer for the 6720 width, the code doesn't render this properly as it uses one value to set the base address for reading from the vmap and for where to start on the device. This fixes it by calculating the values correctly for the device and for the pixmap. No idea how I haven't seen this before now. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17DRM/Radeon: Fix Load Detection on legacy primary DAC.Egbert Eich1-0/+1
commit 83325d072185899b706de2956170b246585aaec9 upstream. An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17target: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK pathSteve Hodgson1-3/+3
commit ab74b3d62f05192bf8fb8f169e7999d1183b2e08 upstream. This patch changes core_tmr_abort_task() to use spin_lock -> spin_unlock around se_cmd->t_state_lock while spin_lock_irqsave is held via se_sess->sess_cmd_lock. Signed-off-by: Steve Hodgson <steve@purestorage.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17iscsi-target: Fix missed wakeup race in TX threadRoland Dreier5-3/+26
commit d5627acba9ae584cf4928af19f7ddf5f6837de32 upstream. The sleeping code in iscsi_target_tx_thread() is susceptible to the classic missed wakeup race: - TX thread finishes handle_immediate_queue() and handle_response_queue(), thinks both queues are empty. - Another thread adds a queue entry and does wake_up_process(), which does nothing because the TX thread is still awake. - TX thread does schedule_timeout() and sleeps forever. In practice this can kill an iSCSI connection if for example an initiator does single-threaded writes and the target misses the wakeup window when queueing an R2T; in this case the connection will be stuck until the initiator loses patience and does some task management operation (or kills the connection entirely). Fix this by converting to wait_event_interruptible(), which does not suffer from this sort of race. Signed-off-by: Roland Dreier <roland@purestorage.com> Cc: Andy Grover <agrover@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17target: Avoid integer overflow in se_dev_align_max_sectors()Roland Dreier1-9/+9
commit 3e03989b5868acf69a391a424dc71fcd6cc48167 upstream. The expression (max_sectors * block_size) might overflow a u32 (indeed, since iblock sets max_hw_sectors to UINT_MAX, it is guaranteed to overflow and end up with a much-too-small result in many common cases). Fix this by doing an equivalent calculation that doesn't require multiplication. While we're touching this code, avoid splitting a printk format across two lines and use pr_info(...) instead of printk(KERN_INFO ...). Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17target: Don't return success from module_init() if setup failsRoland Dreier1-1/+2
commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream. If the call to core_dev_release_virtual_lun0() fails, then nothing sets ret to anything other than 0, so even though everything is torn down and freed, target_core_init_configfs() will seem to succeed and the module will be loaded. Fix this by passing the return value on up the chain. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17rt2800: validate step value for temperature compensationStanislaw Gruszka1-1/+1
commit bf7e1abe434ba9e22e8dc04a4cba4ab504b788b8 upstream. Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the EEPROM, but step is equal to 0xff. This results on ridiculous delta calculations and completely broke TX power settings. Reported-and-tested-by: Pavel Lucik <pavel.lucik@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17ath9k: Test for TID only in BlockAcks while checking tx statusSven Eckelmann1-2/+6
commit 6fe7cc71bbf3a0bc28c9cec3c00bc11e81344412 upstream. The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case only one frame is currently available. The client will then answer using a normal Ack instead of a BlockAck. This acknowledgement has no TID stored and therefore the hardware is not able to provide us the corresponding TID. The TID set by the hardware in the tx status descriptor has to be seen as undefined and not as a valid TID value for normal acknowledgements. Doing otherwise results in a massive amount of retransmissions and stalls of connections. Users may experience low bandwidth and complete connection stalls in environments with transfers using multiple TIDs. This regression was introduced in b11b160defc48e4daa283f785192ea3a23a51f8e ("ath9k: validate the TID in the tx status information"). Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17ath9k: fix stale pointers potentially causing access to free'd skbsFelix Fietkau1-0/+2
commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream. bf->bf_next is only while buffers are chained as part of an A-MPDU in the tx queue. When a tid queue is flushed (e.g. on tearing down an aggregation session), frames can be enqueued again as normal transmission, without bf_next being cleared. This can lead to the old pointer being dereferenced again later. This patch might fix crashes and "Failed to stop TX DMA!" messages. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17Input: tsc40 - remove wrong announcement of pressure supportRolf Eike Beer1-1/+0
commit 32ed1911fc79908d704023317d4ddeb3883fd07e upstream. The tsc40 driver announces it supports the pressure event, but will never send one. The announcement will cause tslib to wait for such events and sending all touch events with a pressure of 0. Removing the announcement will make tslib fall back to emulating the pressure on touch events so everything works as expected. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REFDavid Vrabel1-17/+19
commit a67baeb77375199bbd842fa308cb565164dd1f19 upstream. map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by gntdev_put_map(). Add a gntdev_free_map() helper function to free everything allocated by gntdev_alloc_map(). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05drm/nouveau: headless mode by default if pci class != vga displayBen Skeggs2-3/+3
This is to prevent nouveau from taking over the console on headless boards such as Tesla. Backport of upstream commit: e412e95a268fa8544858ebfe066826b290430d51 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05drm/nouveau: fix suspend/resume when in headless modeBen Skeggs1-7/+11
Backport of fixes from upstream commit: 9430738d80223a1cd791a2baa74fa170d3df1262 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05drm/nouveau: silence modesetting spam on pre-gf8 chipsetsBen Skeggs3-9/+9
commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05HID: microsoft: fix invalid rdesc for 3k kbdJiri Slaby1-5/+13
commit 3ccc60f9d8c39180c205dba1a020735bda1b2491 upstream. Microsoft Digital Media Keyboard 3000 has two interfaces, and the second one has a report descriptor with a bug. The second collection says: 05 01 -- global; usage page -- 01 -- Generic Desktop Controls 09 80 -- local; usage -- 80 -- System Control a1 01 -- main; collection -- 01 -- application 85 03 -- global; report ID -- 03 19 00 -- local; Usage Minimum -- 00 29 ff -- local; Usage Maximum -- ff 15 00 -- global; Logical Minimum -- 0 26 ff 00 -- global; Logical Maximum -- ff 81 00 -- main; input c0 -- main; End Collection I.e. it makes us think that there are all kinds of usages of system control. That the keyboard is a not only a keyboard, but also a joystick, mouse, gamepad, keypad, etc. The same as for the Wireless Desktop Receiver, this should be Physical Min/Max. So fix that appropriately. References: https://bugzilla.novell.com/show_bug.cgi?id=776834 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05target: Fix double-free of se_cmd in target_complete_tmr_failureNicholas Bellinger1-1/+0
commit e13d5fef88c40b87c8430f8274c3a9ca32ef90bc upstream. Fabric drivers currently expect to internally release se_cmd in the event of a TMR failure during target_submit_tmr(), which means the immediate call to transport_generic_free_cmd() after TFO->queue_tm_rsp() from within target_complete_tmr_failure() workqueue context is wrong. This is done as some fabrics expect TMR operations to be acknowledged before releasing the descriptor, so the assumption that core is releasing se_cmd associated TMR memory is incorrect. This fixes a OOPs where transport_generic_free_cmd() was being called more than once. This bug was originally observed with tcm_qla2xxx fabric ports. Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Roland Dreier <roland@purestorage.com> Cc: Andy Grover <agrover@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05b43: Fix oops on unload when firmware not foundLarry Finger1-0/+2
commit f89ff6441df06abc2d95f3ef67525923032d6283 upstream. When b43 fails to find firmware when loaded, a subsequent unload will oops due to calling ieee80211_unregister_hw() when the corresponding register call was never made. Commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 fixed the same problem for b43legacy. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Markus Kanet <dvmailing@gmx.eu> Cc: Markus Kanet <dvmailing@gmx.eu> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05floppy: do put_disk on current dr if blk_init_queue failsHerton Ronaldo Krzesinski1-0/+1
commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream. If blk_init_queue fails, we do not call put_disk on the current dr (dr is decremented first in the error handling loop). Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05md/raid1: Fix assembling of arrays containing Replacements.NeilBrown1-1/+1
commit 02b898f2f04e418094f0093a3ad0b415bcdbe8eb upstream. setup_conf in raid1.c uses conf->raid_disks before assigning a value. It is used when including 'Replacement' devices. The consequence is that assembling an array which contains a replacement will misbehave and either not include the replacement, or not include the device being replaced. Though this doesn't lead directly to data corruption, it could lead to reduced data safety. So use mddev->raid_disks, which is initialised, instead. Bug was introduced by commit c19d57980b38a5bb613a898937a1cf85f422fb9b md/raid1: recognise replacements when assembling arrays. in 3.3, so fix is suitable for 3.3.y thru 3.6.y. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-05gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpiosMathias Nyman1-3/+7
commit ad2fab36d7922401c4576fb7ea9b21a47a29a17f upstream. gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 07:45:50 +0000