BMC/Intel-BMC/linux.git/drivers/net/wireless/marvell, branch dev-4.17

mwifiex: correct histogram data with appropriate index

2018-08-03T05:47:46+00:00

[ Upstream commit 30bfce0b63fa68c14ae1613eb9d259fa18644074 ] Correct snr/nr/rssi data index to avoid possible buffer underflow. Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mwifiex: handle race during mwifiex_usb_disconnect

2018-08-03T05:47:42+00:00

[ Upstream commit b817047ae70c0bd67b677b65d0d69d72cd6e9728 ] Race condition is observed during rmmod of mwifiex_usb: 1. The rmmod thread will call mwifiex_usb_disconnect(), download SHUTDOWN command and do wait_event_interruptible_timeout(), waiting for response. 2. The main thread will handle the response and will do a wake_up_interruptible(), unblocking rmmod thread. 3. On getting unblocked, rmmod thread will make rx_cmd.urb = NULL in mwifiex_usb_free(). 4. The main thread will try to resubmit rx_cmd.urb in mwifiex_usb_submit_rx_urb(), which is NULL. To fix, wait for main thread to complete before calling mwifiex_usb_free(). Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()

2018-03-27T08:03:24+00:00

Fix the following sparse warning in mwifiex_cmd_append_11n_tlv: drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:358:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:358:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:360:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:360:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:366:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:366:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:368:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:368:65: right side has type int Fixes: 77423fa73927 ("mwifiex: fix incorrect ht capability problem") Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo

mwifiex: get_channel from firmware

2018-03-13T16:53:47+00:00

At present driver gets chan_type by referring to IEEE80211_HT_PARAM_CHA_SEC_OFFSET, in ASSOC response. Sometimes AP shows IEEE80211_HT_PARAM_CHA_SEC_OFFSET as above/below in assoc response, even if the association is done on HT20 channel only. So, it will be accurate to get econdary channel offset from firmware. Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo

mwifiex: fix incorrect ht capability problem

2018-03-13T16:53:46+00:00

IEEE80211_CHAN_NO_HT40PLUS and IEEE80211_CHAN_NO_HT40PLUS channel flags tell if HT40 operation is allowed on a channel or not. This patch ensures ht_capability information is modified accordingly so that we don't end up creating a HT40 connection when it's not allowed for current regulatory domain. Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo

Revert "mwifiex: fix incorrect ht capability problem"

2018-03-13T16:53:45+00:00

This reverts commit bcc920e8f08336cbbdcdba7c4449c27137e6b4b9. Drivers gets hardware info and updates ht_cap field of wiphy->bands during initialization. Once updated during init, ht_cap must not be modified as it reflects the capability supported by hardwawre. Above patch tries to modify the ht_cap field and this results in wrongly advertising capabilities during association. Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo

mwifiex: correct antenna number with high bits reserved

2018-03-13T16:52:58+00:00

High bits of antenna number are reserved in hardware spec, using low 4 bits represent supported antenna. Signed-off-by: Cathy Luo Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo

net/wireless: fix spaces and grammar copy/paste in vendor Kconfig help text

2018-03-13T16:52:25+00:00

Lots of the wireless driver vendor Kconfig symol help text says "questions about cards." (2 spaces between "about" and "cards") Besides dropping one of those spaces, it also needs some other word inserted there. Instead of putting each vendor's name there, I chose to say "these" cards in all of the Kconfig help text. Cc: Kalle Valo Signed-off-by: Randy Dunlap Signed-off-by: Kalle Valo

mwifiex: set different mac address for interfaces with same bss type

2018-02-27T16:20:22+00:00

Multiple interfaces with same bss type could affect each other if they are sharing the same mac address. In this patch, different mac address is assigned to new interface which have same bss type with exist interfaces. Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo

mwifiex: resolve reset vs. remove()/shutdown() deadlocks

2018-01-16T16:00:17+00:00

Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see: (a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work) Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock. It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock. It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: Cc: Xinming Hu Signed-off-by: Brian Norris Signed-off-by: Kalle Valo