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>
In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by:
iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But
it forgot to set txq->tfds to NULL.
Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by:
goto error->iwl_txq_gen2_free_memory()->dma_free_coherent().
My patch sets txq->tfds to NULL after the first free to avoid the
double free.
Fixes: 0cd1ad2d7f ("iwlwifi: move all bus-independent TX functions to common code")
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Link: https://lore.kernel.org/r/20210403054755.4781-1-lyl2019@mail.ustc.edu.cn
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add the vendor commands that must be used by the network manager
to allow proper operation of iwlmei.
* Send information on the AP CSME is connected to
* Notify the userspace when roaming is forbidden
* Allow the userspace to require ownership
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v6: remove the VENDOR_CMDS Kconfig option and make the whole infra
depend on IWLMEI directly
v7: remove // comments
remove an unneeded function
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-5-emmanuel.grumbach@intel.com
iwlmei needs to know about the follwing events:
* Association
* De-association
* Country Code change
* SW Rfkill change
* SAR table changes
iwlmei can take the device away from us, so report the new
rfkill type when this happens.
Advertise the required data from the CSME firmware to the
usersapce: mostly, the AP that the CSME firmware is currently
associated to in case there is an active link protection
session.
Generate the HOST_ASSOC / HOST_DISSASSOC messages.
Don't support WPA1 (non-RSNA) for now.
Don't support shared wep either.
We can then determine the AUTH parameter by checking the AKM.
Feed the cipher from the key installation.
SW Rfkill will be implemented later when cfg80211 will
allow us to read the SW Rfkill state.
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v7: Ayala added her signed-off
remove pointless function declaration
fix a bug due to merge conflict in the HOST_ASSOC message
v8: leave a print if we have a SAP connection on a device we do
not support (yet)
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-4-emmanuel.grumbach@intel.com
Add three debugfs hooks:
* status: Check if we have a connection with the CSME
firwmare. This hook is a read only.
* req_ownership: Send a SAP command to request ownership. This
flow should be triggered by iwlwifi (from user space through
vendor commands really), but being able to trigger an ownership
request from debugfs allows us to request ownership without
connecting afterwards. This is an "error" flow that the CSME
firmware is designed to handle this way:
+ Grant ownership since the host asked for it
+ Wait 3 seconds to let the host connect
+ If the host didn't connect, take the device back (forcefully).
+ Don't grant any new ownership request in the following 30
seconds.
This debugfs hook allows us to test this flow.
* send_start_message: Restart the communication with the CSME
firmware from the very beginning. At the very beginning (upon
iwlwifi start), iwlmei send a special message: SAP_ME_MSG_START.
This hook allows to send it again and this will retrigger the
whole flow. It is important to test this restart in the middle
of normal operation since it can happen (in case the CSME
firmware decided to reset for example).
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-3-emmanuel.grumbach@intel.com
CSME in two words
-----------------
CSME stands for Converged Security and Management Engine. It is
a CPU on the chipset and runs a dedicated firmware.
AMT (Active Management Technology) is one of the applications
that run on that CPU. AMT allows to control the platform remotely.
Here is a partial list of the use cases:
* View the screen of the plaform, with keyboard and mouse (KVM)
* Attach a remote IDE device
* Have a serial console to the device
* Query the state of the platform
* Reset / shut down / boot the platform
Networking in CSME
------------------
For those uses cases, CSME's firmware has an embedded network
stack and is able to use the network devices of the system: LAN
and WLAN. This is thanks to the CSME's firmware WLAN driver.
One can add a profile (SSID / key / certificate) to the CSME's OS
and CSME will connect to that profile. Then, one can use the WLAN
link to access the applications that run on CSME (AMT is one of
them). Note that CSME is active during power state and power state
transitions. For example, it is possible to have a KVM session
open to the system while the system is rebooting and actually
configure the BIOS remotely over WLAN thanks to AMT.
How all this is related to Linux
--------------------------------
In Linux, there is a driver that allows the OS to talk to the
CSME firmware, this driver is drivers/misc/mei. This driver
advertises a bus that allows other kernel drivers or even user
space) to talk to components inside the CSME firmware.
In practice, the system advertises a PCI device that allows
to send / receive data to / from the CSME firmware. The mei
bus drivers in drivers/misc/mei is an abstration on top of
this PCI device.
The driver being added here is called iwlmei and talks to the
WLAN driver inside the CSME firmware through the mei bus driver.
Note that the mei bus driver only gives bus services, it doesn't
define the content of the communication.
Why do we need this driver?
--------------------------
CSME uses the same WLAN device that the OS is expecting to see
hence we need an arbitration mechanism. This is what iwlmei is
in charge of. iwlmei maintains the communication with the CSME
firmware's WLAN driver. The language / protocol that is used
between the CSME's firmware WLAN driver and iwlmei is OS agnostic
and is called SAP which stands for Software Abritration Protocol.
With SAP, iwlmei will be able to tell the CSME firmware's WLAN
driver:
1) Please give me the device.
2) Please note that the SW/HW rfkill state change.
3) Please note that I am now associated to X.
4) Please note that I received this packet.
etc...
There are messages that go the opposite direction as well:
1) Please note that AMT is en/disable.
2) Please note that I believe the OS is broken and hence I'll take
the device *now*, whether you like it or not, to make sure that
connectivity is preserved.
3) Please note that I am willing to give the device if the OS
needs it.
4) Please give me any packet that is sent on UDP / TCP on IP address
XX.XX.XX.XX and an port ZZ.
5) Please send this packet.
etc...
Please check drivers/net/wireless/intel/iwlwifi/mei/sap.h for the
full protocol specification.
Arbitration is not the only purpose of iwlmei and SAP. SAP also
allows to maintain the AMT's functionality even when the OS owns
the device. To connect to AMT, one needs to initiate an HTTP
connection to port 16992. iwlmei will listen to the Rx path and
forward (through SAP) to the CSME firmware the data it got. Then,
the embedded HTTP server in the chipset will reply to the request
and send a SAP notification to ask iwlmei to send the reply.
This way, AMT running on the CSME can still work.
In practice this means that all the use cases quoted above (KVM,
remote IDE device, etc...) will work even when the OS uses the
WLAN device.
How to disable all this?
---------------------------
iwlmei won't be able to do anything if the CSME's networking stack
is not enabled. By default, CSME's networking stack is disabled (this
is a BIOS setting).
In case the CSME's networking stack is disabled, iwlwifi will just
get access to the device because there is no contention with any other
actor and, hence, no arbitration is needed.
In this patch, I only add the iwlmei driver. Integration with
iwlwifi will be implemented in the next one.
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v2: fix a few warnings raised by the different bots
v3: rewrite the commit message
v4: put the debugfs content in a different patch
v5: fix a NULL pointer dereference upon DHCP TX if SAP is connected
since we now have the required cfg80211 bits in wl-drv-next, add
the RFKILL handling patch to this series.
v6: change the SAP API to inherit the values from iwl-mei.h removing
the need to ensure the values are equal with a BUILD_BUG_ON.
This was suggested by Arend
v7: * fix a locking issue in case of CSME firmware reset:
When the CSME firmware resets, we need to unregister the
netdev, first take the mutex, and only then, rely on it
being taken.
* Add a comment to explain why it is ok to have static variables
(iwlmei can't have more than a single instance).
* Add a define for 26 + 8 + 8
* Add a define SEND_SAP_MAX_WAIT_ITERATION
* make struct const
* Reword a bit the Kconfig help message
* Ayala added her Signed-off
* fixed an RCU annotation
v8: do not require ownership upfront, use NIC_OWNER instead. This fixes
a deadlock when CSME does not have the right WiFi FW.
Add more documentation about the owernship transition
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-2-emmanuel.grumbach@intel.com
