iwlmei allows to integrate with the CSME firmware. There are
flows that are prioprietary for this purpose:
* Get the information the AP, the CSME firmware is connected
to. This is useful when we need to speed up the connection
process in case the CSME firmware has an TCP connection
that must be kept alive across the ownership transition.
* Forbid roaming, which will happen when the CSME firmware
wants to tell the user space not disrupt the connection.
* Request ownership, upon driver boot when the CSME firmware
owns the device.
Co-Developed-by: Ayala Beker <[email protected]>
Signed-off-by: Emmanuel Grumbach <[email protected]>
---
include/uapi/linux/nl80211-vnd-intel.h | 80 ++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
create mode 100644 include/uapi/linux/nl80211-vnd-intel.h
diff --git a/include/uapi/linux/nl80211-vnd-intel.h b/include/uapi/linux/nl80211-vnd-intel.h
new file mode 100644
index 000000000000..d41c34b84f25
--- /dev/null
+++ b/include/uapi/linux/nl80211-vnd-intel.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2012-2014, 2018-2021 Intel Corporation
+ * Copyright (C) 2013-2015 Intel Mobile Communications GmbH
+ * Copyright (C) 2016-2017 Intel Deutschland GmbH
+ */
+#ifndef __VENDOR_CMD_INTEL_H__
+#define __VENDOR_CMD_INTEL_H__
+
+#define INTEL_OUI 0x001735
+
+/**
+ * enum iwl_mvm_vendor_cmd - supported vendor commands
+ * @IWL_MVM_VENDOR_CMD_GET_CSME_CONN_INFO: reports CSME connection info.
+ * @IWL_MVM_VENDOR_CMD_HOST_GET_OWNERSHIP: asks for ownership on the device.
+ * @IWL_MVM_VENDOR_CMD_ROAMING_FORBIDDEN_EVENT: notifies if roaming is allowed.
+ * It contains a &IWL_MVM_VENDOR_ATTR_ROAMING_FORBIDDEN and a
+ * &IWL_MVM_VENDOR_ATTR_VIF_ADDR attributes.
+ */
+
+enum iwl_mvm_vendor_cmd {
+ IWL_MVM_VENDOR_CMD_GET_CSME_CONN_INFO = 0x2d,
+ IWL_MVM_VENDOR_CMD_HOST_GET_OWNERSHIP = 0x30,
+ IWL_MVM_VENDOR_CMD_ROAMING_FORBIDDEN_EVENT = 0x32,
+};
+
+enum iwl_vendor_auth_akm_mode {
+ IWL_VENDOR_AUTH_OPEN,
+ IWL_VENDOR_AUTH_SHARED,
+ IWL_VENDOR_AUTH_WPA = 0x3,
+ IWL_VENDOR_AUTH_WPA_PSK,
+ IWL_VENDOR_AUTH_RSNA = 0x6,
+ IWL_VENDOR_AUTH_RSNA_PSK,
+ IWL_VENDOR_AUTH_SAE = 0x9,
+ IWL_VENDOR_AUTH_MAX,
+};
+
+/**
+ * enum iwl_mvm_vendor_attr - attributes used in vendor commands
+ * @__IWL_MVM_VENDOR_ATTR_INVALID: attribute 0 is invalid
+ * @IWL_MVM_VENDOR_ATTR_VIF_ADDR: interface MAC address
+ * @IWL_MVM_VENDOR_ATTR_ADDR: MAC address
+ * @IWL_MVM_VENDOR_ATTR_SSID: SSID (binary attribute, 0..32 octets)
+ * @IWL_MVM_VENDOR_ATTR_STA_CIPHER: the cipher to use for the station with the
+ * mac address specified in &IWL_MVM_VENDOR_ATTR_ADDR.
+ * @IWL_MVM_VENDOR_ATTR_ROAMING_FORBIDDEN: u8 attribute. Indicates whether
+ * roaming is forbidden or not. Value 1 means roaming is forbidden,
+ * 0 mean roaming is allowed.
+ * @IWL_MVM_VENDOR_ATTR_AUTH_MODE: u32 attribute. Authentication mode type
+ * as specified in &enum iwl_vendor_auth_akm_mode.
+ * @IWL_MVM_VENDOR_ATTR_CHANNEL_NUM: u8 attribute. Contains channel number.
+ * @IWL_MVM_VENDOR_ATTR_BAND: u8 attribute.
+ * 0 for 2.4 GHz band, 1 for 5.2GHz band and 2 for 6GHz band.
+ * @IWL_MVM_VENDOR_ATTR_COLLOC_CHANNEL: u32 attribute. Channel number of
+ * collocated AP. Relevant for 6GHz AP info.
+ * @IWL_MVM_VENDOR_ATTR_COLLOC_ADDR: MAC address of a collocated AP.
+ * Relevant for 6GHz AP info.
+ *
+ * @NUM_IWL_MVM_VENDOR_ATTR: number of vendor attributes
+ * @MAX_IWL_MVM_VENDOR_ATTR: highest vendor attribute number
+
+ */
+enum iwl_mvm_vendor_attr {
+ __IWL_MVM_VENDOR_ATTR_INVALID = 0x00,
+ IWL_MVM_VENDOR_ATTR_VIF_ADDR = 0x02,
+ IWL_MVM_VENDOR_ATTR_ADDR = 0x0a,
+ IWL_MVM_VENDOR_ATTR_SSID = 0x3d,
+ IWL_MVM_VENDOR_ATTR_STA_CIPHER = 0x51,
+ IWL_MVM_VENDOR_ATTR_ROAMING_FORBIDDEN = 0x64,
+ IWL_MVM_VENDOR_ATTR_AUTH_MODE = 0x65,
+ IWL_MVM_VENDOR_ATTR_CHANNEL_NUM = 0x66,
+ IWL_MVM_VENDOR_ATTR_BAND = 0x69,
+ IWL_MVM_VENDOR_ATTR_COLLOC_CHANNEL = 0x70,
+ IWL_MVM_VENDOR_ATTR_COLLOC_ADDR = 0x71,
+
+ NUM_IWL_MVM_VENDOR_ATTR,
+ MAX_IWL_MVM_VENDOR_ATTR = NUM_IWL_MVM_VENDOR_ATTR - 1,
+};
+
+#endif /* __VENDOR_CMD_INTEL_H__ */
--
2.25.1
On Wed, 2021-06-23 at 17:10 +0300, Emmanuel Grumbach wrote:
> iwlmei allows to integrate with the CSME firmware. There are
> flows that are prioprietary for this purpose:
>
> * Get the information the AP, the CSME firmware is connected
> to. This is useful when we need to speed up the connection
> process in case the CSME firmware has an TCP connection
> that must be kept alive across the ownership transition.
> * Forbid roaming, which will happen when the CSME firmware
> wants to tell the user space not disrupt the connection.
> * Request ownership, upon driver boot when the CSME firmware
> owns the device.
>
> Co-Developed-by: Ayala Beker <[email protected]>
> Signed-off-by: Emmanuel Grumbach <[email protected]>
> ---
> include/uapi/linux/nl80211-vnd-intel.h | 80 ++++++++++++++++++++++++++
This was supposed to be submitted separately [1] so people see it more
easily, so *bump* - everyone take a look please.
johannes
[1] https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
Patches introducing such commands shall be submitted separately, not
“buried” in big driver patchsets. Give them a “nl80211: vendor-cmd: ”
prefix to make them easily identifiable.
Though I guess we can debate if this is a "big" patchset :)
On Thu, Jun 24, 2021 at 3:48 PM Johannes Berg <[email protected]> wrote:
>
> On Wed, 2021-06-23 at 17:10 +0300, Emmanuel Grumbach wrote:
> > iwlmei allows to integrate with the CSME firmware. There are
> > flows that are prioprietary for this purpose:
> >
> > * Get the information the AP, the CSME firmware is connected
> > to. This is useful when we need to speed up the connection
> > process in case the CSME firmware has an TCP connection
> > that must be kept alive across the ownership transition.
> > * Forbid roaming, which will happen when the CSME firmware
> > wants to tell the user space not disrupt the connection.
> > * Request ownership, upon driver boot when the CSME firmware
> > owns the device.
> >
> > Co-Developed-by: Ayala Beker <[email protected]>
> > Signed-off-by: Emmanuel Grumbach <[email protected]>
> > ---
> > include/uapi/linux/nl80211-vnd-intel.h | 80 ++++++++++++++++++++++++++
>
> This was supposed to be submitted separately [1] so people see it more
> easily, so *bump* - everyone take a look please.
>
> johannes
>
> [1] https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
>
> Patches introducing such commands shall be submitted separately, not
> “buried” in big driver patchsets. Give them a “nl80211: vendor-cmd: ”
> prefix to make them easily identifiable.
>
> Though I guess we can debate if this is a "big" patchset :)
>
Thanks Johannes.
I have a few typos in the commit message so that I can re-send this
patch if needed.
In that case, I'd send it as a standalone patch.
(Although it'd make the kernel build bots unhappy).
Emmanuel Grumbach <[email protected]> writes:
> iwlmei allows to integrate with the CSME firmware. There are
> flows that are prioprietary for this purpose:
>
> * Get the information the AP, the CSME firmware is connected
> to. This is useful when we need to speed up the connection
> process in case the CSME firmware has an TCP connection
> that must be kept alive across the ownership transition.
> * Forbid roaming, which will happen when the CSME firmware
> wants to tell the user space not disrupt the connection.
> * Request ownership, upon driver boot when the CSME firmware
> owns the device.
Vendor command requirements are documented here:
https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
The commit log is not really answering to those. For example, how a user
would use this? Or is there a user space tool?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <[email protected]> wrote:
>
> Emmanuel Grumbach <[email protected]> writes:
>
> > iwlmei allows to integrate with the CSME firmware. There are
> > flows that are prioprietary for this purpose:
> >
> > * Get the information the AP, the CSME firmware is connected
> > to. This is useful when we need to speed up the connection
> > process in case the CSME firmware has an TCP connection
> > that must be kept alive across the ownership transition.
> > * Forbid roaming, which will happen when the CSME firmware
> > wants to tell the user space not disrupt the connection.
> > * Request ownership, upon driver boot when the CSME firmware
> > owns the device.
>
> Vendor command requirements are documented here:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
>
> The commit log is not really answering to those. For example, how a user
> would use this? Or is there a user space tool?
We intend to send those command from the NetworkManager.
I'll write a commit message that explains this better.
The gist of it is that the user space will see that the NIC is not
owned by the host thanks to the new RFKILL reason that I added. Then,
it can ask CSME what AP it is connected to, check if it has the a
profile configure for that AP and connect to that same profile.
I'll respin.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Emmanuel Grumbach <[email protected]> writes:
> On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <[email protected]> wrote:
>>
>> Emmanuel Grumbach <[email protected]> writes:
>>
>> > iwlmei allows to integrate with the CSME firmware. There are
>> > flows that are prioprietary for this purpose:
>> >
>> > * Get the information the AP, the CSME firmware is connected
>> > to. This is useful when we need to speed up the connection
>> > process in case the CSME firmware has an TCP connection
>> > that must be kept alive across the ownership transition.
>> > * Forbid roaming, which will happen when the CSME firmware
>> > wants to tell the user space not disrupt the connection.
>> > * Request ownership, upon driver boot when the CSME firmware
>> > owns the device.
>>
>> Vendor command requirements are documented here:
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
>>
>> The commit log is not really answering to those. For example, how a user
>> would use this? Or is there a user space tool?
>
> We intend to send those command from the NetworkManager.
I'm not really fond of the idea that NetworkManager uses nl80211 vendor
commands, sounds quite hacky to me. I would prefer that NetworkManager
uses generic nl80211 interface so that it works with every driver. But I
need to look at v4 to understand more how this all works.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
> > On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <[email protected]> wrote:
> >>
> >> Emmanuel Grumbach <[email protected]> writes:
> >>
> >> > iwlmei allows to integrate with the CSME firmware. There are flows
> >> > that are prioprietary for this purpose:
> >> >
> >> > * Get the information the AP, the CSME firmware is connected
> >> > to. This is useful when we need to speed up the connection
> >> > process in case the CSME firmware has an TCP connection
> >> > that must be kept alive across the ownership transition.
> >> > * Forbid roaming, which will happen when the CSME firmware
> >> > wants to tell the user space not disrupt the connection.
> >> > * Request ownership, upon driver boot when the CSME firmware
> >> > owns the device.
> >>
> >> Vendor command requirements are documented here:
> >>
> >> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#
> >> vendor-specific_api
> >>
> >> The commit log is not really answering to those. For example, how a
> >> user would use this? Or is there a user space tool?
> >
> > We intend to send those command from the NetworkManager.
>
> I'm not really fond of the idea that NetworkManager uses nl80211 vendor
> commands, sounds quite hacky to me. I would prefer that NetworkManager
> uses generic nl80211 interface so that it works with every driver. But I need
> to look at v4 to understand more how this all works.
>
You'd need to look at v5 which I already sent.
Nothing of this can be generic, because it is really Intel proprietary. CSME can only use Intel devices by design.
It uses a proprietary bus implemented only in Intel devices (and not even all of them, only the ones in systems
with the vPRO sticker).
I already touched base with the NetworkManager's maintainers about this. They asked the vendor commands
to be upstream in the kernel, so this is what I am doing.
"Grumbach, Emmanuel" <[email protected]> writes:
>>
>> > On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <[email protected]> wrote:
>> >>
>> >> Emmanuel Grumbach <[email protected]> writes:
>> >>
>> >> > iwlmei allows to integrate with the CSME firmware. There are flows
>> >> > that are prioprietary for this purpose:
>> >> >
>> >> > * Get the information the AP, the CSME firmware is connected
>> >> > to. This is useful when we need to speed up the connection
>> >> > process in case the CSME firmware has an TCP connection
>> >> > that must be kept alive across the ownership transition.
>> >> > * Forbid roaming, which will happen when the CSME firmware
>> >> > wants to tell the user space not disrupt the connection.
>> >> > * Request ownership, upon driver boot when the CSME firmware
>> >> > owns the device.
>> >>
>> >> Vendor command requirements are documented here:
>> >>
>> >> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#
>> >> vendor-specific_api
>> >>
>> >> The commit log is not really answering to those. For example, how a
>> >> user would use this? Or is there a user space tool?
>> >
>> > We intend to send those command from the NetworkManager.
>>
>> I'm not really fond of the idea that NetworkManager uses nl80211 vendor
>> commands, sounds quite hacky to me. I would prefer that NetworkManager
>> uses generic nl80211 interface so that it works with every driver. But I need
>> to look at v4 to understand more how this all works.
>>
>
> You'd need to look at v5 which I already sent.
> Nothing of this can be generic, because it is really Intel
> proprietary.
Every company always says that their implemention is proprietary :) So
that's not really a technical reason....
> CSME can only use Intel devices by design. It uses a proprietary bus
> implemented only in Intel devices (and not even all of them, only the
> ones in systems with the vPRO sticker).
Ok, fair enough. I guess this is exotic enough that no other driver ever
wants to implement, and I haven't seen any complaints either about this
vendor interface. But please do include the justification for the vendor
interface in the commit log as well.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches