diff mbox series

[v3,3/4] nl80211: vendor-cmd: add Intel vendor commands for iwlmei usage

Message ID 20210623141033.27475-3-emmanuel.grumbach@intel.com
State Superseded
Headers show
Series None | expand

Commit Message

Emmanuel Grumbach June 23, 2021, 2:10 p.m. UTC 
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 <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
 include/uapi/linux/nl80211-vnd-intel.h | 80 ++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 include/uapi/linux/nl80211-vnd-intel.h

Comments

Johannes Berg June 24, 2021, 12:45 p.m. UTC | #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 <ayala.beker@intel.com>

> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

> ---

>  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 :)
Emmanuel Grumbach June 24, 2021, 12:51 p.m. UTC | #2 
On Thu, Jun 24, 2021 at 3:48 PM Johannes Berg <johannes@sipsolutions.net> 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 <ayala.beker@intel.com>

> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

> > ---

> >  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).
Kalle Valo June 24, 2021, 5:07 p.m. UTC | #3 
Emmanuel Grumbach <emmanuel.grumbach@intel.com> 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
Emmanuel Grumbach June 24, 2021, 7:56 p.m. UTC | #4 
On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>

> Emmanuel Grumbach <emmanuel.grumbach@intel.com> 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
Kalle Valo Aug. 5, 2021, 1:25 p.m. UTC | #5 
Emmanuel Grumbach <egrumbach@gmail.com> writes:

> On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <kvalo@codeaurora.org> wrote:

>>

>> Emmanuel Grumbach <emmanuel.grumbach@intel.com> 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
Emmanuel Grumbach Aug. 7, 2021, 6:32 p.m. UTC | #6 
> 

> > On Thu, Jun 24, 2021 at 8:09 PM Kalle Valo <kvalo@codeaurora.org> wrote:

> >>

> >> Emmanuel Grumbach <emmanuel.grumbach@intel.com> 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.
diff mbox series

Patch

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__ */