linux-stable.git/drivers/staging, branch v3.0.9

Staging: hv: Add support for >2 TB LUN in storage driver.

2011-11-11T17:35:14+00:00

commit cf55f4a8b6243b42fb91c56d1421db0d36d60f96 upstream.

If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently
report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc.
Thanks to Robert Scheck  for reporting the issue.

Reported-by: Robert Scheck 
Signed-off-by: Mike Sterling 
Signed-off-by: K.Y. Srinivasan 
Signed-off-by: Haiyang Zhang 
Signed-off-by: Greg Kroah-Hartman

staging: quatech_usb2: Potential lost wakeup scenario in TIOCMIWAIT

2011-11-11T17:35:14+00:00

commit e8df1674d383d2ecc6efa8d7dba74c03aafdfdd7 upstream.

If the usermode app does an ioctl over this serial device  by
using TIOCMIWAIT, then the code will wait by setting the current
task state to TASK_INTERRUPTIBLE and then calling schedule().
This will be woken up by the qt2_process_modem_status on URB
completion when the port_extra->shadowMSR is set to the new
modem status.

However, this could result in a lost wakeup scenario due to a race
in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion
for new modem status in qt2_process_modem_status.
Due to this, the usermode app's task will continue to sleep despite a
change in the modem status.

Signed-off-by: Kautuk Consul 
Signed-off-by: Greg Kroah-Hartman

staging: serqt_usb2: remove ssu100 from supported devices

2011-11-11T17:35:13+00:00

commit 7cbf3c7cd59288fb5e9f31815c74773549668d43 upstream.

The serqt_usb2 driver will not work properly with the ssu100 device
even though it claims to support it.  The ssu100 is supported by the
ssu100 driver in mainline so there is no need to have it claimed by
serqt_usb2.

Signed-off-by: Bill Pemberton 
Signed-off-by: Greg Kroah-Hartman

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