kernel/linux.git/drivers/staging, branch v3.0.6

staging: rtl8192u: declare MODULE_FIRMWARE

2011-08-17T17:55:50+00:00

commit 589c3ca00b7886bf743998398884cd4f4d354e17 upstream. declaring MODULE_FIRMWARE has apparently forgotten while removing the embedded firmware arrays in 0a8692b534e18fcec6eac07551bb37a22659f5c7 (rtl8192u_usb: Remove built-in firmware images). Signed-off-by: Stefan Lippers-Hollmann Signed-off-by: Greg Kroah-Hartman

net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared

2011-08-16T01:31:38+00:00

[ Upstream commit 550fd08c2cebad61c548def135f67aba284c6162 ] After the last patch, We are left in a state in which only drivers calling ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real hardware call ether_setup for their net_devices and don't hold any state in their skbs. There are a handful of drivers that violate this assumption of course, and need to be fixed up. This patch identifies those drivers, and marks them as not being able to support the safe transmission of skbs by clearning the IFF_TX_SKB_SHARING flag in priv_flags Signed-off-by: Neil Horman CC: Karsten Keil CC: "David S. Miller" CC: Jay Vosburgh CC: Andy Gospodarek CC: Patrick McHardy CC: Krzysztof Halasa CC: "John W. Linville" CC: Greg Kroah-Hartman CC: Marcel Holtmann CC: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

staging: brcm80211: fix for reported log spam problem

2011-08-05T04:58:34+00:00

commit 37c962d195005d009e130e65a9e55960996c3cab upstream. Every few minutes, this message would appear in syslog: ieee80211 ph0: wl_ops_bss_info_changed: BSS idle: true (implement) The message has been deleted, the driver requires no special action on this particular event (). See: https://bugzilla.kernel.org/show_bug.cgi?id=38162 Reported-by: David Hill Signed-off-by: Roland Vossen Reviewed-by: Arend van Spriel Reviewed-by: Franky Lin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Lippers-Hollmann

ath6kl: fix crash when interface is closed but scan is ongoing

2011-08-05T04:58:33+00:00

commit 98ab5c7755b5cc9e1a8f2a57ccb22eac5e13ec50 upstream. When ath6kl module was resumed while a scan was ongoing, for example during suspend, the driver would crash in ar6k_cfg80211_scanComplete_event(): [26581.586440] Call Trace: [26581.586440] [] ? ar6k_cfg80211_scanComplete_event+0xaa/0xaa [ath6kl] [26581.586440] [] wmi_iterate_nodes+0xb/0xd [ath6kl] [26581.586440] [] ar6k_cfg80211_scanComplete_event+0x48/0xaa [ath6kl] [26581.586440] [] ar6000_close+0x77/0x7e [ath6kl] [26581.586440] [] __dev_close_many+0x87/0xab [26581.586440] [] dev_close_many+0x54/0xab [26581.586440] [] rollback_registered_many+0xa5/0x19e [26581.586440] [] rollback_registered+0x23/0x2f [26581.586440] [] unregister_netdevice_queue+0x4c/0x69 [26581.586440] [] unregister_netdev+0x18/0x1f [26581.586440] [] ar6000_destroy+0xf8/0x115 [ath6kl] [26581.586440] [] ar6k_cleanup_module+0x20/0x29 [ath6kl] [26581.586440] [] sys_delete_module+0x181/0x1d9 [26581.586440] [] ? lock_release_holdtime+0x2b/0xcd [26581.586440] [] ? sys_munmap+0x3b/0x42 [26581.586440] [] ? restore_all+0xf/0xf [26581.586440] [] sysenter_do_call+0x12/0x32 [26581.586440] Code: 89 53 6c 75 07 89 d8 e8 c0 ff ff ff 89 f0 e8 2c f2 a9 c7 5b 5e 5d c3 55 89 e5 57 56 53 89 c3 83 ec 08 89 55 f0 8d 78 04 89 4d ec <8b> b0 b8 00 00 00 46 89 b0 b8 00 00 00 89 f8 e8 ae ed a9 c7 8b Fix the function not to iterate nodes when the scan is aborted. The nodes are already freed when the module is being unloaded. Patch "ath6kl: Fix a kernel panic furing suspend/resume" tried to fix this already but it wasn't enough as a pointer was still used even after the null check. This patch removes the null check entirely as the wmi structure is not accessed anymore during module unload. Also fix a bug where the status was checked as a bitfield with '&' operator. But it's not a bitfield, just a regular (enum like) value. Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath6kl: cache firmware

2011-08-05T04:58:33+00:00

commit b42a7b1bc7c0f535dfe35b2c934f239c60bb8d30 upstream. Drivers should not request firmware during resume. Fix ath6kl to cache the firmware instead. Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

Staging: hv: netvsc: Increase the timeout value in the netvsc driver

2011-08-05T04:58:32+00:00

commit 5c5781b3f88567211ecaaada13431af15c8c6003 upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Signed-off-by: Greg Kroah-Hartman

Staging: hv: vmbus: Increase the timeout value in the vmbus driver

2011-08-05T04:58:31+00:00

commit 2dfde9644fe8c4a77f9c73f95b25d6300ca23b5d upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Signed-off-by: Greg Kroah-Hartman

Staging: hv: storvsc: Increase the timeout value in the storvsc driver

2011-08-05T04:58:31+00:00

commit 46d2eb6d82ef44be58ae192c35e8cd52485f02eb upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. the 3.0 kernel as well. Signed-off-by: K. Y. Srinivasan Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Signed-off-by: Greg Kroah-Hartman

staging: comedi: fix infoleak to userspace

2011-08-05T04:58:31+00:00

commit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream. driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman

staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192 conflict with rtl8192se

2011-08-05T04:58:31+00:00

commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 upstream. There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman