This is now the only driver that selects the LEDS_CLASS framework,
which is normally user-selectable. While it doesn't strictly cause
a bug, rework the Kconfig logic to be more consistent with what
other drivers do, and only enable LED support in brcmsmac if the
dependencies are all there, rather than using 'select' to enable
what it needs.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-2-arnd@kernel.org
The dependencies for LED configuration are highly inconsistent and too
complicated at the moment. One of the results is a randconfig failure I
get very rarely when LEDS_CLASS is in a loadable module, but the wireless
core is built-in:
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- IWLEGACY [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y]
- IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y] && IWLWIFI [=m] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=IWLWIFI [=m]) && (IWLMVM [=m] || IWLDVM [=m])
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_register_led':
led.c:(.text+0x60): undefined reference to `led_classdev_register_ext'
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_unregister_leds':
led.c:(.text+0x200): undefined reference to `led_classdev_unregister'
For iwlwifi, the dependency is wrong, since this config prevents the
MAC80211_LEDS code from being part of a built-in MAC80211 driver.
For iwlegacy, this is worse because the driver tries to force-enable
the other subsystems, which is both a layering violation and a bug
because it will still fail with MAC80211=y and IWLEGACY=m, leading
to LEDS_CLASS being a module as well.
The actual link failure in the ath5k driver is a result of MAC80211_LEDS
being enabled but not usable. With the Kconfig logic fixed in the
Intel drivers, the ath5k driver works as expected again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-1-arnd@kernel.org
While running stress tests in roaming scenarios (switching ap's every 5
seconds, we discovered a issue which leads to tx hangings of exactly 5
seconds while or after scanning for new accesspoints. We found out that
this hanging is triggered by ath10k_mac_wait_tx_complete since the
empty_tx_wq was not wake when the num_tx_pending counter reaches zero.
To fix this, we simply move the wake_up call to htt_tx_dec_pending,
since this call was missed on several locations within the ath10k code.
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20210505085806.11474-1-s.gottschall@dd-wrt.com
In ath11k, tx of management packet is doing in a work queue. Sometimes
the workqueue does not finish tx immediately, then it lead after the next
step of vdev delete finished, it start to send the management packet to
firmware and lead firmware crash.
ieee80211_set_disassoc() have logic of ieee80211_flush_queues() after
it send_deauth_disassoc() to ath11k, its purpose is make sure the
deauth was actually sent, so it need to change ath11k to match the
purpose of mac80211.
To address these issue wait for tx mgmt as well as tx data packets.
dmesg log of connect/disconnect to AP:
[ 307.522226] wls1: authenticate with 62:66:e4:e9:6a:a9
[ 307.586565] wls1: send auth to 62:66:e4:e9:6a:a9 (try 1/3)
[ 307.586581] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 307.586922] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 307.590179] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 307.590181] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 307.598699] wls1: authenticated
[ 307.599483] wls1: associate with 62:66:e4:e9:6a:a9 (try 1/3)
[ 307.599506] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 307.599519] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 307.603059] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 307.603063] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 307.637105] wls1: associated
[ 317.365239] wls1: deauthenticating from 62:66:e4:e9:6a:a9 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 317.368104] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 317.372622] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 317.378320] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 317.378330] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 317.378359] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0
[ 317.421066] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0
[ 317.421427] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0)
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211202063705.14321-1-quic_wgong@quicinc.com
Kernel test robot reported:drivers/net/wireless/ath/wcn36xx/smd.c:943:33:
sparse: sparse: cast truncates bits from constant value (780 becomes 80)
The 'channels' field is not a simple u8 array but an array of
channel_params. Using sizeof for retrieving the max number of
channels is then wrong.
In practice, it was not an issue, because the sizeof returned
value is 780, which is truncated in min_t (u8) to 80, which is
the value we expect...
Fix that properly using ARRAY_SIZE instead of sizeof.
Fixes: d707f812bb ("wcn36xx: Channel list update before hardware scan")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638435732-14657-1-git-send-email-loic.poulain@linaro.org
Add handler for WMI_11D_NEW_COUNTRY_EVENTID, WMI_11D_SCAN_START_CMDID,
WMI_11D_SCAN_STOP_CMDID.
After vdev create for STATION, send WMI_11D_SCAN_START_CMDID to firmware
and wait firmware complete it, the scan from mac80211 also need to wait
the 11d scan finished, and send WMI_11D_SCAN_STOP_CMDID to firmware
before vdev delete for STATION.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211201071745.17746-4-quic_wgong@quicinc.com
Kalle Valo says:
====================
wireless-drivers-next patches for v5.17
First set of patches for v5.17. The biggest change is the iwlmei
driver for Intel's AMT devices. Also now WCN6855 support in ath11k
should be usable.
Major changes:
ath10k
* fetch (pre-)calibration data via nvmem subsystem
ath11k
* enable 802.11 power save mode in station mode for qca6390 and wcn6855
* trace log support
* proper board file detection for WCN6855 based on PCI ids
* BSS color change support
rtw88
* add debugfs file to force lowest basic rate
* add quirk to disable PCI ASPM on HP 250 G7 Notebook PC
mwifiex
* add quirk to disable deep sleep with certain hardware revision in
Surface Book 2 devices
iwlwifi
* add iwlmei driver for co-operating with Intel's Active Management
Technology (AMT) devices
* tag 'wireless-drivers-next-2021-12-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (87 commits)
iwlwifi: mei: fix linking when tracing is not enabled
rtlwifi: rtl8192de: Style clean-ups
mwl8k: Use named struct for memcpy() region
intersil: Use struct_group() for memcpy() region
libertas_tf: Use struct_group() for memcpy() region
libertas: Use struct_group() for memcpy() region
wlcore: no need to initialise statics to false
rsi: Fix out-of-bounds read in rsi_read_pkt()
rsi: Fix use-after-free in rsi_rx_done_handler()
brcmfmac: Configure keep-alive packet on suspend
wilc1000: remove '-Wunused-but-set-variable' warning in chip_wakeup()
iwlwifi: mvm: read the rfkill state and feed it to iwlmei
iwlwifi: mvm: add vendor commands needed for iwlmei
iwlwifi: integrate with iwlmei
iwlwifi: mei: add debugfs hooks
iwlwifi: mei: add the driver to allow cooperation with CSME
mei: bus: add client dma interface
mwifiex: Ignore BTCOEX events from the 88W8897 firmware
mwifiex: Ensure the version string from the firmware is 0-terminated
mwifiex: Add quirk to disable deep sleep with certain hardware revision
...
====================
Link: https://lore.kernel.org/r/20211207144211.A9949C341C1@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If the iwlmei code is a loadable module, the main iwlwifi driver
cannot be built-in:
x86_64-linux-ld: drivers/net/wireless/intel/iwlwifi/pcie/trans.o: in function `iwl_pcie_prepare_card_hw':
trans.c:(.text+0x4158): undefined reference to `iwl_mei_is_connected'
Unfortunately, Kconfig enforces the opposite, forcing the MEI driver to
not be built-in if iwlwifi is a module.
To work around this, decouple iwlmei from iwlwifi and add the
dependency in the other direction.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211207151447.3338818-1-arnd@kernel.org
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We have a MAC component (which is inside the SoC) and it has several
different HW steps. 3 bits used to be enough but now we need 4-bits
to represent all the different steps.
Properly support 4-bits in the MAC step value by refactoring all the
current handling of the MAC step/dash.
Already from family 8000 and up the dash (bits 0-1) no longer exists
and the step (until 8000 bits 2-3) consists of the dash bits as well.
To do this remove the CSR_HW_REV_STEP and the CSR_HW_REV_DASH
macros, replace them with CSR_HW_REV_STEP_DASH and add hw_rev_step
into the trans struct.
In addition remove the CSR_HW_IF_CONFIG_REG_MSK_MAC_STEP and
CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH macros and create a new macro
combining the 2 (this way we don't need shifting or anything else.)
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Mike Golant <michael.golant@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211207160459.2e81a14d1f80.Ia5287e37fb3439d805336837361f6491f958e465@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If userspace installs a lot of multicast groups very quickly, then
we may run out of command queue space as we send the updates in an
asynchronous fashion (due to locking concerns), and the CPU can
create them faster than the firmware can process them. This is true
even when mac80211 has a work struct that gets scheduled.
Fix this by synchronizing with the firmware after sending all those
commands - outside of the iteration we can send a synchronous echo
command that just has the effect of the CPU waiting for the prior
asynchronous commands to finish. This also will cause fewer of the
commands to be sent to the firmware overall, because the work will
only run once when rescheduled multiple times while it's running.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649
Suggested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reported-by: Maximilian Ernestus <maximilian@ernestus.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If we happen to decide an NSSN queue sync (IWL_MVM_RXQ_NSSN_SYNC)
for some remaining packets that are still on the queue, but just
after we've decided to do a delBA (which causes its own queues
sync with IWL_MVM_RXQ_NOTIF_DEL_BA) we can end up with a sequence
of events like this:
CPU 1 CPU 2
remove BA session with baid N
send IWL_MVM_RXQ_NOTIF_DEL_BA
send IWL_MVM_RXQ_NSSN_SYNC
get IWL_MVM_RXQ_NOTIF_DEL_BA
get IWL_MVM_RXQ_NOTIF_DEL_BA
get IWL_MVM_RXQ_NSSN_SYNC
complete IWL_MVM_RXQ_NOTIF_DEL_BA
remove N from baid_map[]
get IWL_MVM_RXQ_NSSN_SYNC
WARN_ON(!baid_map[N])
Thus, there's a race that leads in hitting the WARN_ON, but more
importantly, it's a race that potentially even results in a new
aggregation session getting assigned to baid N.
To fix this, remove the WARN_ON() in the NSSN_SYNC case, we can't
completely protect against hitting this case, so we shouldn't be
warning. However, guard ourselves against BAID reuse by doing yet
another round of queue synchronization after the entry is removed
from the baid_map, so that it cannot be reused with any in-flight
IWL_MVM_RXQ_NSSN_SYNC messages.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204083237.44abbbc50f40.I5492600dfe513356555abe2d7df0e2835846e3d8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
