lwn.git/drivers/net, branch v3.13.5

iwlwifi: mvm: BT Coex - disable BT when TXing probe request in scan

2014-02-22T21:34:45+00:00

commit 8e2a866ef214af4e104ec8d593e3269d8fe66d19 upstream. Not doing so will let BT kill our probe requests leading to failures in scan. Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

iwlwifi: add more 7265 HW IDs

2014-02-22T21:34:45+00:00

commit f7690915ccce98553c5425b51e6b5a6c51e27f4e upstream. Add 6 new HW IDs for the 7265 series. Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: print the version of the firmware when it asserts

2014-02-22T21:34:44+00:00

commit b900a87b2eb90c0b9586496c82a323a1b8832d73 upstream. This can be useful to be able to spot the firmware version from the error reports without needing to fetch it from another place. Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: disable scheduled scan

2014-02-22T21:34:44+00:00

commit 0822afe8ebb9389997ef677447c7b08e08797de9 upstream. The iwlwifi scheduled scan implementation doesn't adhere to the userspace API correctly - the API assumes that any new incoming 'incompatible' request (like scan or remain-on-channel for this driver) will just cancel the scheduled scan. Instead our driver relies on userspace cancelling it, thus breaking existing wpa_s versions. Fixes: 35a000b7c1bb ("iwlwifi: mvm: support sched scan if supported by the fw") Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: don't allow A band if SKU forbids it

2014-02-22T21:34:44+00:00

commit c512865446e6dd5b6e91e81187e75b734ad7cfc7 upstream. The driver wasn't reading the NVM properly. While this didn't lead to any issue until now, it seems that there is an old version of the NVM in the wild. In this version, the A band channels appear to be valid but the SKU capabilities (another field of the NVM) says that A band isn't supported at all. With this specific version of the NVM, the driver would think that A band is supported while the HW / firmware don't. This leads to asserts. Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

ar5523: fix usb id for Gigaset.

2014-02-22T21:34:43+00:00

commit 4fcfc7443d072582b5047b8b391d711590e5645c upstream. Raw id and FW id should be switched. Tested-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: Do not support PowerSave by default

2014-02-22T21:34:43+00:00

commit 8298383c2cd5a6d0639f1bb1781fba181bd20154 upstream. Even though we make sure PowerSave is not enabled by default by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init, PS could be enabled by userspace based on various factors like battery usage etc. Since PS in ath9k is just broken and has been untested for years, remove support for it, but allow a user to explicitly enable it using a module parameter. Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_htc: Do not support PowerSave by default

2014-02-22T21:34:43+00:00

commit 6bca610d97b6139a1d7598b8009da9d339daa50f upstream. It is a copy/paste of patch provided by Sujith for ath9k. "Even though we make sure PowerSave is not enabled by default by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init, PS could be enabled by userspace based on various factors like battery usage etc. Since PS in ath9k is just broken and has been untested for years, remove support for it, but allow a user to explicitly enable it using a module parameter." Signed-off-by: Oleksij Rempel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_htc: make ->sta_rc_update atomic for most calls

2014-02-22T21:34:43+00:00

commit 2fa4cb905605c863bf570027233af7afd8149ae4 upstream. sta_rc_update() callback must be atomic, hence we can not take mutexes or do other operations, which can sleep in ath9k_htc_sta_rc_update(). I think we can just return from ath9k_htc_sta_rc_update(), if it is called without IEEE80211_RC_SUPP_RATES_CHANGED bit. That will help with scheduling while atomic bug for most cases (except mesh and IBSS modes). For mesh and IBSS I do not see other solution like creating additional workqueue, because sending firmware command require us to sleep, but this can be done in additional patch. Patch partially fixes bug: https://bugzilla.redhat.com/show_bug.cgi?id=990955 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

2014-02-13T21:55:28+00:00

commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream. The user has the option of disabling the platform driver: 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) which is used to unplug the emulated drivers (IDE, Realtek 8169, etc) and allow the PV drivers to take over. If the user wishes to disable that they can set: xen_platform_pci=0 (in the guest config file) or xen_emul_unplug=never (on the Linux command line) except it does not work properly. The PV drivers still try to load and since the Xen platform driver is not run - and it has not initialized the grant tables, most of the PV drivers stumble upon: input: Xen Virtual Keyboard as /devices/virtual/input/input5 input: Xen Virtual Pointer as /devices/virtual/input/input6M ------------[ cut here ]------------ kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206! invalid opcode: 0000 [#1] SMP Modules linked in: xen_kbdfront(+) xenfs xen_privcmd CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1 Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013 RIP: 0010:[] [] get_free_entries+0x2e0/0x300 Call Trace: [] ? evdev_connect+0x1e3/0x240 [] gnttab_grant_foreign_access+0x2e/0x70 [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront] [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront] [] xenbus_dev_probe+0x77/0x130 [] xenbus_frontend_dev_probe+0x47/0x50 [] driver_probe_device+0x89/0x230 [] __driver_attach+0x9b/0xa0 [] ? driver_probe_device+0x230/0x230 [] ? driver_probe_device+0x230/0x230 [] bus_for_each_dev+0x8c/0xb0 [] driver_attach+0x19/0x20 [] bus_add_driver+0x1a0/0x220 [] driver_register+0x5f/0xf0 [] xenbus_register_driver_common+0x15/0x20 [] xenbus_register_frontend+0x23/0x40 [] ? 0xffffffffa0014fff [] xenkbd_init+0x2b/0x1000 [xen_kbdfront] [] do_one_initcall+0x49/0x170 .. snip.. which is hardly nice. This patch fixes this by having each PV driver check for: - if running in PV, then it is fine to execute (as that is their native environment). - if running in HVM, check if user wanted 'xen_emul_unplug=never', in which case bail out and don't load any PV drivers. - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci) does not exist, then bail out and not load PV drivers. - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks', then bail out for all PV devices _except_ the block one. Ditto for the network one ('nics'). - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary' then load block PV driver, and also setup the legacy IDE paths. In (v3) make it actually load PV drivers. Reported-by: Sander Eikelenboom Reported-and-Tested-by: Fabio Fantoni Signed-off-by: Konrad Rzeszutek Wilk [v2: Add extra logic to handle the myrid ways 'xen_emul_unplug' can be used per Ian and Stefano suggestion] [v3: Make the unnecessary case work properly] [v4: s/disks/ide-disks/ spotted by Fabio] Reviewed-by: Stefano Stabellini Acked-by: Bjorn Helgaas [for PCI parts] Signed-off-by: Greg Kroah-Hartman