mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-08-05 16:54:27 +00:00
2da4366f9e
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
174 lines
5.6 KiB
Text
174 lines
5.6 KiB
Text
# SPDX-License-Identifier: GPL-2.0-only
|
|
config IWLWIFI
|
|
tristate "Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi) "
|
|
depends on PCI && HAS_IOMEM && CFG80211
|
|
select FW_LOADER
|
|
help
|
|
Select to build the driver supporting the:
|
|
|
|
Intel Wireless WiFi Link Next-Gen AGN
|
|
|
|
This option enables support for use with the following hardware:
|
|
Intel Wireless WiFi Link 6250AGN Adapter
|
|
Intel 6000 Series Wi-Fi Adapters (6200AGN and 6300AGN)
|
|
Intel WiFi Link 1000BGN
|
|
Intel Wireless WiFi 5150AGN
|
|
Intel Wireless WiFi 5100AGN, 5300AGN, and 5350AGN
|
|
Intel 6005 Series Wi-Fi Adapters
|
|
Intel 6030 Series Wi-Fi Adapters
|
|
Intel Wireless WiFi Link 6150BGN 2 Adapter
|
|
Intel 100 Series Wi-Fi Adapters (100BGN and 130BGN)
|
|
Intel 2000 Series Wi-Fi Adapters
|
|
Intel 7260 Wi-Fi Adapter
|
|
Intel 3160 Wi-Fi Adapter
|
|
Intel 7265 Wi-Fi Adapter
|
|
Intel 8260 Wi-Fi Adapter
|
|
Intel 3165 Wi-Fi Adapter
|
|
|
|
|
|
This driver uses the kernel's mac80211 subsystem.
|
|
|
|
In order to use this driver, you will need a firmware
|
|
image for it. You can obtain the microcode from:
|
|
|
|
<https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi>.
|
|
|
|
The firmware is typically installed in /lib/firmware. You can
|
|
look in the hotplug script /etc/hotplug/firmware.agent to
|
|
determine which directory FIRMWARE_DIR is set to when the script
|
|
runs.
|
|
|
|
If you want to compile the driver as a module ( = code which can be
|
|
inserted in and removed from the running kernel whenever you want),
|
|
say M here and read <file:Documentation/kbuild/modules.rst>. The
|
|
module will be called iwlwifi.
|
|
|
|
if IWLWIFI
|
|
|
|
config IWLWIFI_LEDS
|
|
bool
|
|
depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI
|
|
depends on IWLMVM || IWLDVM
|
|
select LEDS_TRIGGERS
|
|
select MAC80211_LEDS
|
|
default y
|
|
|
|
config IWLDVM
|
|
tristate "Intel Wireless WiFi DVM Firmware support"
|
|
depends on MAC80211
|
|
help
|
|
This is the driver that supports the DVM firmware. The list
|
|
of the devices that use this firmware is available here:
|
|
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#firmware
|
|
|
|
config IWLMVM
|
|
tristate "Intel Wireless WiFi MVM Firmware support"
|
|
select WANT_DEV_COREDUMP
|
|
depends on MAC80211
|
|
help
|
|
This is the driver that supports the MVM firmware. The list
|
|
of the devices that use this firmware is available here:
|
|
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#firmware
|
|
|
|
# don't call it _MODULE -- will confuse Kconfig/fixdep/...
|
|
config IWLWIFI_OPMODE_MODULAR
|
|
bool
|
|
default y if IWLDVM=m
|
|
default y if IWLMVM=m
|
|
|
|
comment "WARNING: iwlwifi is useless without IWLDVM or IWLMVM"
|
|
depends on IWLDVM=n && IWLMVM=n
|
|
|
|
config IWLWIFI_BCAST_FILTERING
|
|
bool "Enable broadcast filtering"
|
|
depends on IWLMVM
|
|
help
|
|
Say Y here to enable default bcast filtering configuration.
|
|
|
|
Enabling broadcast filtering will drop any incoming wireless
|
|
broadcast frames, except some very specific predefined
|
|
patterns (e.g. incoming arp requests).
|
|
|
|
If unsure, don't enable this option, as some programs might
|
|
expect incoming broadcasts for their normal operations.
|
|
|
|
config IWLMEI
|
|
tristate "Intel Management Engine communication over WLAN"
|
|
depends on INTEL_MEI
|
|
depends on PM
|
|
depends on IWLMVM
|
|
help
|
|
Enables the iwlmei kernel module.
|
|
|
|
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.
|
|
|
|
This kernel module allows to communicate with the Intel Management
|
|
Engine over Wifi. This is supported starting from Tiger Lake
|
|
platforms and has been tested on 9260 devices only.
|
|
If AMT is configured not to use the wireless device, this module is
|
|
harmless (and useless).
|
|
Enabling this option on a platform that has a different device and
|
|
has Wireless enabled on AMT can prevent WiFi from working correctly.
|
|
|
|
For more information see
|
|
<https://software.intel.com/en-us/manageability/>
|
|
|
|
If unsure, say N.
|
|
|
|
menu "Debugging Options"
|
|
|
|
config IWLWIFI_DEBUG
|
|
bool "Enable full debugging output in the iwlwifi driver"
|
|
help
|
|
This option will enable debug tracing output for the iwlwifi drivers
|
|
|
|
This will result in the kernel module being ~100k larger. You can
|
|
control which debug output is sent to the kernel log by setting the
|
|
value in
|
|
|
|
/sys/module/iwlwifi/parameters/debug
|
|
|
|
This entry will only exist if this option is enabled.
|
|
|
|
To set a value, simply echo an 8-byte hex value to the same file:
|
|
|
|
% echo 0x43fff > /sys/module/iwlwifi/parameters/debug
|
|
|
|
You can find the list of debug mask values in:
|
|
drivers/net/wireless/iwlwifi/iwl-debug.h
|
|
|
|
If this is your first time using this driver, you should say Y here
|
|
as the debug information can assist others in helping you resolve
|
|
any problems you may encounter.
|
|
|
|
config IWLWIFI_DEBUGFS
|
|
bool "iwlwifi debugfs support"
|
|
depends on MAC80211_DEBUGFS
|
|
help
|
|
Enable creation of debugfs files for the iwlwifi drivers. This
|
|
is a low-impact option that allows getting insight into the
|
|
driver's state at runtime.
|
|
|
|
config IWLWIFI_DEVICE_TRACING
|
|
bool "iwlwifi device access tracing"
|
|
depends on EVENT_TRACING
|
|
default y
|
|
help
|
|
Say Y here to trace all commands, including TX frames and IO
|
|
accesses, sent to the device. If you say yes, iwlwifi will
|
|
register with the ftrace framework for event tracing and dump
|
|
all this information to the ringbuffer, you may need to
|
|
increase the ringbuffer size. See the ftrace documentation
|
|
for more information.
|
|
|
|
When tracing is not enabled, this option still has some
|
|
(though rather small) overhead.
|
|
|
|
If unsure, say Y so we can help you better when problems
|
|
occur.
|
|
endmenu
|
|
|
|
endif
|