1
0
Fork 0
mirror of synced 2025-03-06 20:59:54 +01:00
Commit graph

19 commits

Author SHA1 Message Date
Johannes Berg
78488a64ae iwlwifi: mei: fix potential NULL-ptr deref
If SKB allocation fails, continue rather than using the NULL
pointer.

Coverity CID: 1497650

Cc: stable@vger.kernel.org
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220517120045.90c1b1fd534e.Ibb42463e74d0ec7d36ec81df22e171ae1f6268b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-18 12:58:59 +02:00
Avraham Stern
55cf10488d iwlwifi: mei: clear the sap data header before sending
The SAP data header has some fields that are marked as reserved
but are actually in use by CSME. Clear those fields before sending
the data to avoid having random values in those fields.

Cc: stable@vger.kernel.org
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220517120045.8dd3423cf683.I02976028eaa6aab395cb2e701fa7127212762eb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-18 12:54:09 +02:00
Gustavo A. R. Silva
c5f675748c iwlwifi: mei: Replace zero-length array with flexible-array member
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/78
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220216195030.GA904170@embeddedor
2022-04-06 10:19:08 +03:00
Jakub Kicinski
0b3660695e brcmfmac
* add BCM43454/6 support
 
 rtw89
  * add support for 160 MHz channels and 6 GHz band
  * hardware scan support
 
 iwlwifi
  * support UHB TAS enablement via BIOS
  * remove a bunch of W=1 warnings
  * add support for channel switch offload
  * support 32 Rx AMPDU sessions in newer devices
  * add support for a couple of new devices
  * add support for band disablement via BIOS
 
 mt76
  * mt7915 thermal management improvements
  * SAR support for more mt76 drivers
  * mt7986 wmac support on mt7915
 
 ath11k
  * debugfs interface to configure firmware debug log level
  * debugfs interface to test Target Wake Time (TWT)
  * provide 802.11ax High Efficiency (HE) data via radiotap
 
 ath9k
  * use hw_random API instead of directly dumping into random.c
 
 wcn36xx
  * fix wcn3660 to work on 5 GHz band
 
 ath6kl
  * add device ID for WLU5150-D81
 
 cfg80211/mac80211
  * initial EHT (from 802.11be) support
    (EHT rates, 320 MHz, larger block-ack)
  * support disconnect on HW restart
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAmIrQoUACgkQB8qZga/f
 l8SV9RAAhZwiX4tkcjOYh3vDCOlmZRZV7dy0CYtcRlyHvO/4xH0DJUCbItW3hkeY
 HwLeaTE9J6INCui/iWbWVWsBKoiYQHEWxbfLYg6xDeQR4ijYQaz1c9inevu6qdOn
 3STKzBjsJ8uQF81ANjTFsL33B9olceIrHttqVI0Ezv6YlAQ1JYRNBBikh8NM+XPN
 /AUdsG9KyWRuraPbPf1sZapMJBGpvDMhKlo8LW08Xv9sC8to57Tw5AHVwMY71Ipu
 ClE0EyDGYRm8W+cbJvZ1bp7D/TGcIspAdpPR9JAznXWeFhyl6bswGtUsf3FGxXNk
 1i+1tonRlL3Xi9CvXDmGk2fstYe4MSmWXVFehoulMY9F2C1ibp6PrLa8SLjC+wzu
 1QDfM65ggc90uu0AJLTOp9qnkapvz3/FGL5z9sx2OEM1Iks2RwOpbB6gKo+C0A9W
 3wMxgPPt4mMV2WIgYv1okfcghUoH2l3b1n+Iq+osOa9pbdLrMhvzsrhIQZBaFnBa
 3S5yhGh8djEla2+FmmMs0RKvRX+m+FeVjkJ8ozPLZl880A0OLmZZ+6Wnoa3ZQHmi
 AkuOLhCGm3PVXCN8Mb0nwHmc+LJS/V/U5VBDzieOXMKM4OjMlbGQNt4+2bEJ+Qd3
 jlTkt1cLI/gFvdoFmsJUEOrpT49qZ94obmX8u07pEO/fI+bXHF4=
 =ccps
 -----END PGP SIGNATURE-----

Merge tag 'wireless-next-2022-03-11' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

Johannes Berg says:

====================
brcmfmac
 * add BCM43454/6 support

rtw89
 * add support for 160 MHz channels and 6 GHz band
 * hardware scan support

iwlwifi
 * support UHB TAS enablement via BIOS
 * remove a bunch of W=1 warnings
 * add support for channel switch offload
 * support 32 Rx AMPDU sessions in newer devices
 * add support for a couple of new devices
 * add support for band disablement via BIOS

mt76
 * mt7915 thermal management improvements
 * SAR support for more mt76 drivers
 * mt7986 wmac support on mt7915

ath11k
 * debugfs interface to configure firmware debug log level
 * debugfs interface to test Target Wake Time (TWT)
 * provide 802.11ax High Efficiency (HE) data via radiotap

ath9k
 * use hw_random API instead of directly dumping into random.c

wcn36xx
 * fix wcn3660 to work on 5 GHz band

ath6kl
 * add device ID for WLU5150-D81

cfg80211/mac80211
 * initial EHT (from 802.11be) support
   (EHT rates, 320 MHz, larger block-ack)
 * support disconnect on HW restart

* tag 'wireless-next-2022-03-11' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (247 commits)
  mac80211: Add support to trigger sta disconnect on hardware restart
  mac80211: fix potential double free on mesh join
  mac80211: correct legacy rates check in ieee80211_calc_rx_airtime
  nl80211: fix typo of NL80211_IF_TYPE_OCB in documentation
  mac80211: Use GFP_KERNEL instead of GFP_ATOMIC when possible
  mac80211: replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
  rtw89: 8852c: process logic efuse map
  rtw89: 8852c: process efuse of phycap
  rtw89: support DAV efuse reading operation
  rtw89: 8852c: add chip::dle_mem
  rtw89: add page_regs to handle v1 chips
  rtw89: add chip_info::{h2c,c2h}_reg to support more chips
  rtw89: add hci_func_en_addr to support variant generation
  rtw89: add power_{on/off}_func
  rtw89: read chip version depends on chip ID
  rtw89: pci: use a struct to describe all registers address related to DMA channel
  rtw89: pci: add V1 of PCI channel address
  rtw89: pci: add struct rtw89_pci_info
  rtw89: 8852c: add 8852c empty files
  MAINTAINERS: add devicetree bindings entry for mt76
  ...

====================

Link: https://lore.kernel.org/r/20220311124029.213470-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-11 13:00:17 -08:00
Johannes Berg
cdf3949f24 iwlwifi: mei: use C99 initializer for device IDs
There's another field and so W=2 warns about this code, but
in general it's nicer to use C99 initializers anyway to make
the code easier to read.

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.20220204122220.b5efbbd83c9c.I908128aa8249565ff1c5496ca5c5597efea7cb39@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18 10:40:53 +02:00
Johannes Berg
a31ec5fac1 iwlwifi: mei: avoid -Wpointer-arith and -Wcast-qual warnings
These cause extra warnings (at least with W=3), avoid them.

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.20220130115024.59d00c6e5f09.I331bf18af0b80b5cc41b379ff0cc1b26a89dd915@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18 10:40:52 +02:00
Emmanuel Grumbach
30de48b436 iwlwifi: mei: report RFKILL upon register when needed
When we register and we are in link protection passive, meaning
that the host can't touch the device, report RFKILL immediately
upon register() and don't wait for the CSME firmware to let us
know again about the link protection state.

What happens if we wait is that the host will not see RFKILL soon
enough and we'll have a window of time during which it can bring
up the device which will request ownership.

Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.a136f9f46336.Ief7506dc3b1813a1943a5a639aa45d8e5f284f31@changeid
2022-02-03 10:24:51 +02:00
Emmanuel Grumbach
44bf7c4667 iwlwifi: mei: retry mapping the shared area
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.

The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.

For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.

The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.

Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.

Add a retry mechanism to make sure that we will succeed
to map the memory.

Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Fixes: bcbddc4f9d ("iwlwifi: mei: wait before mapping the shared area")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.cc51e6a6d635.I4b74a082eb8d89f9e4f556a27c4339c15444dc6c@changeid
2022-02-03 10:24:50 +02:00
Emmanuel Grumbach
e1849784de iwlwifi: mei: fix the pskb_may_pull check in ipv4
The check makes sure that we can look at the ip header.
We first need to check that the basic ip header (20 bytes)
can be pulled before we look at the field that will teach
us how long is the ip header. This is why there are two
checks.

The second check was wrong and smatch pointed that
sizeof(ip_hdrlen(skb) - sizeof(*iphdr)) can't be right.

Looking at the code again made me think that we really
need ip_hdrlen(skb) since we want to make sure all the
IP header is in the buffer header. This will allow us
to set the transport offset and from there to look
at the transport header (TCP / UDP).

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.6d9fcf82691e.I449b1e21c5b5478f2ac218522570479918f49f9d@changeid
2022-02-03 10:24:49 +02:00
Kalle Valo
bc11517bc8 wlwifi patches for v5.17 v2
* Support for Time-Aware-SAR (TAS) as read from the BIOS;
 * Fix scan timeout issue when 6GHz is enabled;
 * Work continues for new HW family Bz;
 * Support for Optimized Connectivity Experience (OCE) scan;
 * A bunch of FW debugging improvements and fixes;
 * Fix one 32-bit compilation issue;
 * Some RX changes for new HW family
 * Some fixes for 6 GHz scan;
 * Fix SAR table fixes with newer platforms;
 * Fix early restart crash;
 * Small fix in the debugging code;
 * Add new Killer device IDs;
 * Datapath updates for Bz family continues;
 * A couple of important fixes in iwlmei;
 * Some other small fixes, clean-ups and improvements.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAmHBrxwACgkQoUecoho8
 xfrx7RAAsQDep82tXHDq4il8iGJ0pw/5Whxs4COxRpEpvzMk6fQsiox5+k2CrDT4
 K63lusg8ARPJbtWJOMVf6/0UjVrpy3kulzvG208p4J1Rtxs+s0TwbsxFIH4FzUFp
 vOlr8ck1GdDicgHNM4jr/vzJu/eUnu+mgOZO0SOK6r3sm8lCAnq7SQjr8cePnCoL
 VnRz/27DjpmE4/3cyiMS8c9GwYNDYdzSyb/fQLQ/YkbPzMnSHD1a5OosBZq7B9KL
 Db9YOT0tgFSKwPcXxC6rWY5z0R0E8KKXNVfk+Vwj+WmNPhXFPkAVTPHO0wuy6ZZg
 NguBk80LOzlXlo5Nr3sYKNtNDBw9IDIP5oZUnBqG5qxsW/rKJNMOPOBgurOpHbY3
 +IR+HW9PBjG+j2xlcuVDcXCR/wZxfKk6X7c2PRReBWB8aCRZZb7lfe8KelwtGFkc
 fsqPg8ng1Ba7qJ7rm39URRJoi0dQ1+iRmQUJTD3JOsQNmKGvLpMlqmh70VTpRRj/
 1Z+zjry3rYUT+hzZA3Qb62Fe62BXX+oLLjFUpnDSVLJhul3vCmlnjT5Yc/gud8M0
 jQEkZdCrFzK+1z58E9FmBrdjqzWs5SnatBZnTsyeGnWQbnQguS+Mzfgx3kWOZj30
 KfKn0S/97ysG1mdBAZ2yjiD7Tp1rpFrXZMO44KEBEczH6a5rdD4=
 =BKW6
 -----END PGP SIGNATURE-----

Merge tag 'iwlwifi-next-for-kalle-2021-12-21-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next

wlwifi patches for v5.17 v2

* Support for Time-Aware-SAR (TAS) as read from the BIOS;
* Fix scan timeout issue when 6GHz is enabled;
* Work continues for new HW family Bz;
* Support for Optimized Connectivity Experience (OCE) scan;
* A bunch of FW debugging improvements and fixes;
* Fix one 32-bit compilation issue;
* Some RX changes for new HW family
* Some fixes for 6 GHz scan;
* Fix SAR table fixes with newer platforms;
* Fix early restart crash;
* Small fix in the debugging code;
* Add new Killer device IDs;
* Datapath updates for Bz family continues;
* A couple of important fixes in iwlmei;
* Some other small fixes, clean-ups and improvements.
2021-12-21 20:07:09 +02:00
Emmanuel Grumbach
bcbddc4f9d iwlwifi: mei: wait before mapping the shared area
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.

The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.

For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.

The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.

Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.

Add a delay to avoid this. This is still racy, but our
measurements showed that we have a good margin and we
should now be safe.

Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21 12:39:04 +02:00
Emmanuel Grumbach
013f9e6355 iwlwifi: mei: clear the ownership when the driver goes down
When the driver is unregistered, CSME will take ownership on the
device. Reflect this in the iwlmei object so that we will remember
to re-ask for ownership when the driver will register again.

Not doing so will cause CSME not to give the host ownership and
we will see the following error message when trying to bring up
the interface:

iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw Couldn't prepare the card but SAP is connected
iwlwifi 0000:a9:00.0: Error while preparing HW: -16

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.c7bb5b7644df.I48498d9fd6e3959562205af67aa5f1a822eb762d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21 12:39:04 +02:00
Johannes Berg
991bbbeccc iwlwifi: mei: fix W=1 warnings
There are a few warnings due to kernel-doc not understanding
the constructs the way they're done here, fix them.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211219110000.1ef2bb24771c.I6a59ad2d64f719d3e27398951c8f1b678b0b1092@changeid
2021-12-20 20:41:29 +02:00
Emmanuel Grumbach
46c7b05a4f iwlwifi: mvm: fix a possible NULL pointer deference
Smatch spot a possible NULL pointer dereference. Fix it.

__iwl_mvm_mac_set_key can be called with sta = NULL
Also add a NULL pointer check after memory allocation.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://lore.kernel.org/r/20211130105951.85539-1-emmanuel.grumbach@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07 12:58:05 +02:00
Colin Ian King
1a4d575869 iwlwifi: mei: Fix spelling mistake "req_ownserhip" -> "req_ownership"
There is a spelling mistake in a debugfs filename. Fix it.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211129124921.11817-1-colin.i.king@gmail.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07 12:58:05 +02:00
Emmanuel Grumbach
6522916014 iwlwifi: mei: don't rely on the size from the shared area
If CSME is compromised, it could report a bigger queue size
in the share area and make the host perform an out of bound
access.
Instead of reading the size of the queue from the shared area,
store it in the regular context which is not accessible by CSME.

While at it, fix a small typo in an error print.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://lore.kernel.org/r/20211128121509.3952-1-emmanuel.grumbach@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07 12:58:04 +02:00
Emmanuel Grumbach
fe6db7eda9 iwlwifi: mei: fix linking when tracing is not enabled
I forgot to add stubs in case tracing is disabled which caused linking errors:

ERROR: modpost: "__SCT__tp_func_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__SCT__tp_func_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__tracepoint_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__tracepoint_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__SCK__tp_func_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__SCK__tp_func_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__tracepoint_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__SCT__tp_func_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!
ERROR: modpost: "__SCK__tp_func_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined!

Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201113411.130409-1-emmanuel.grumbach@intel.com
2021-12-05 13:55:15 +02:00
Emmanuel Grumbach
4ea7da5fad iwlwifi: mei: add debugfs hooks
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
2021-11-26 18:31:47 +02:00
Emmanuel Grumbach
2da4366f9e iwlwifi: mei: add the driver to allow cooperation with CSME
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
2021-11-26 18:31:47 +02:00