linux-toradex.git/drivers/staging, branch v3.0.2

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

Staging: usbip: vhci-hcd: Do not kill already dead RX/TX kthread

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

commit 8547d4cc2b616e4f1dafebe2c673fc986422b506 upstream.

When unbinding a device on the host which was still attached on the
client, I got a NULL pointer dereference on the client. This turned out
to be due to kthread_stop() being called on an already dead kthread.

Here is how I was able to reproduce the problem:

 server:# usbip bind -b 1-2
                                client:# usbip attach -h server -b 1-2
 server:# usbip unbind -b 1-2

This patch fixes the problem by checking the kthread before attempting
to kill it, as it is done on the opposite side in
stub_shutdown_connection().

Signed-off-by: Tobias Klauser 
Signed-off-by: Greg Kroah-Hartman