[RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Ping-Ke Shih]

From: Johnson Tsai <wenjie.tsai@realtek.com>

Expose the device's Serial Number (SN) and UUID from EFUSE through a
read-only `hw_info` sysfs attribute on the USB interface device.

This hardware identification information is essential for user-space
applications to uniquely identify, track, and manage specific Wi-Fi
adapters. For example, in automated factory provisioning or device
management systems, user-space tools rely on the EFUSE SN and UUID
to bind specific configurations to a physical adapter. Currently,
standard wireless APIs do not expose this low-level hardware
information, making this sysfs node the only viable and necessary
solution for user space to extract this data.

Relying on debugfs or setuid binaries is unviable for production
environments, as explicitly requested by Valve (Steam). Steam frequently
runs inside unprivileged containers (e.g., Flatpak) where debugfs and
setuid binaries are inaccessible. Furthermore, many end-user systems
disable debugfs in their kernel configs, and strict access controls
(SELinux, AppArmor) block it regardless of permissions. Since Steam
installs as an unprivileged user, setuid deployments are impossible.
Consequently, exposing this data via a world-readable (0444) sysfs
node is the only functional approach to ensure reliable, unprivileged
access across diverse customer systems.

Example usage from user-space:
  $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
  SN: 36 42 00 01 23
  UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa

User-space scripts can easily iterate over bound devices to extract
this information:
  for dev in /sys/bus/usb/drivers/rtw89_8852cu/[0-9]*:*; do
      dev_id=$(basename "$dev")
      echo "--- Device: /sys/bus/usb/devices/$dev_id ---"
      cat "$dev/hw_info"
  done

Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
Hi maintainers,

We are submitting this RFC to discuss the most appropriate upstream path for
exposing hardware-specific IDs to unprivileged container environments.

1. Given the strict environment limitations (Flatpak, missing debugfs, LSMs),
   is a read-only sysfs attribute acceptable for this specific hardware data?
2. If exposing this globally via sysfs is not preferred, would it be acceptable
   to restrict the creation of this node to specific vendor VID/PIDs only?
3. If sysfs is strictly a no-go for this use case, what is the upstream-recommended
   method for an unprivileged, sandboxed application to retrieve eFuse data?
---
 drivers/net/wireless/realtek/rtw89/usb.c | 51 +++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index c6d55e669776..53dcb84af5c0 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -1059,6 +1059,41 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
 	usb_set_intfdata(intf, NULL);
 }
 
+static ssize_t hw_info_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	struct usb_interface *intf = to_usb_interface(dev);
+	struct ieee80211_hw *hw;
+	struct rtw89_dev *rtwdev;
+	struct rtw89_efuse *efuse;
+	ssize_t ret;
+
+	device_lock(dev);
+
+	hw = usb_get_intfdata(intf);
+	if (!hw) {
+		device_unlock(dev);
+		return -ENODEV;
+	}
+
+	rtwdev = hw->priv;
+	efuse = &rtwdev->efuse;
+
+	ret = sysfs_emit(buf, "SN: %*ph\nUUID: %*ph\n",
+			 (int)sizeof(efuse->sn), efuse->sn,
+			 (int)sizeof(efuse->uuid), efuse->uuid);
+
+	device_unlock(dev);
+	return ret;
+}
+static DEVICE_ATTR_RO(hw_info);
+
+static struct attribute *rtw89_usb_attrs[] = {
+	&dev_attr_hw_info.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(rtw89_usb);
+
 int rtw89_usb_probe(struct usb_interface *intf,
 		    const struct usb_device_id *id)
 {
@@ -1118,10 +1153,16 @@ int rtw89_usb_probe(struct usb_interface *intf,
 		goto err_core_deinit;
 	}
 
+	ret = sysfs_create_groups(&intf->dev.kobj, rtw89_usb_groups);
+	if (ret) {
+		rtw89_err(rtwdev, "failed to create sysfs groups: %d\n", ret);
+		goto err_core_deinit;
+	}
+
 	ret = rtw89_core_register(rtwdev);
 	if (ret) {
 		rtw89_err(rtwdev, "failed to register core\n");
-		goto err_core_deinit;
+		goto err_remove_sysfs;
 	}
 
 	rtw89_usb_start_rx(rtwdev);
@@ -1130,6 +1171,8 @@ int rtw89_usb_probe(struct usb_interface *intf,
 
 	return 0;
 
+err_remove_sysfs:
+	sysfs_remove_groups(&intf->dev.kobj, rtw89_usb_groups);
 err_core_deinit:
 	rtw89_core_deinit(rtwdev);
 err_deinit_rx:
@@ -1154,12 +1197,18 @@ void rtw89_usb_disconnect(struct usb_interface *intf)
 	if (!hw)
 		return;
 
+	/* Clear intfdata immediately so any concurrent sysfs show waiting on
+	 * device_lock will see NULL and bail out safely.
+	 */
+	usb_set_intfdata(intf, NULL);
+
 	rtwdev = hw->priv;
 	rtwusb = rtw89_usb_priv(rtwdev);
 
 	rtw89_usb_cancel_rx_bufs(rtwusb);
 	rtw89_usb_cancel_tx_bufs(rtwusb);
 
+	sysfs_remove_groups(&intf->dev.kobj, rtw89_usb_groups);
 	rtw89_core_unregister(rtwdev);
 	rtw89_core_deinit(rtwdev);
 	rtw89_usb_deinit_rx(rtwdev);

base-commit: 7076af642955693935e60bc94546d105fb0395ca
-- 
2.25.1

[RFC rtw-next 2/2] wifi: rtw89: usb: add sysfs write example

[Ping-Ke Shih]

From: Johnson Tsai <wenjie.tsai@realtek.com>

Add a simple echo_sum sysfs attribute on the USB interface device as
an RFC example for discussing whether a writable sysfs interface is
acceptable for this driver.

The attribute accepts two integers from userspace, stores their sum in
driver private data, and exposes the result.

Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
 drivers/net/wireless/realtek/rtw89/usb.c | 38 ++++++++++++++++++++++++
 drivers/net/wireless/realtek/rtw89/usb.h |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index 53dcb84af5c0..566618e9f3b8 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -1059,6 +1059,43 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
 	usb_set_intfdata(intf, NULL);
 }
 
+static ssize_t echo_sum_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct usb_interface *intf = to_usb_interface(dev);
+	struct ieee80211_hw *hw = usb_get_intfdata(intf);
+	struct rtw89_usb *rtwusb;
+
+	if (!hw)
+		return -ENODEV;
+
+	rtwusb = rtw89_usb_priv(hw->priv);
+
+	return sysfs_emit(buf, "%u\n", rtwusb->echo_sum);
+}
+
+static ssize_t echo_sum_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct usb_interface *intf = to_usb_interface(dev);
+	struct ieee80211_hw *hw = usb_get_intfdata(intf);
+	struct rtw89_usb *rtwusb;
+	int a, b;
+
+	if (!hw)
+		return -ENODEV;
+
+	if (sscanf(buf, "%d %d", &a, &b) != 2)
+		return -EINVAL;
+
+	rtwusb = rtw89_usb_priv(hw->priv);
+	rtwusb->echo_sum = a + b;
+
+	return count;
+}
+static DEVICE_ATTR_ADMIN_RW(echo_sum);
+
 static ssize_t hw_info_show(struct device *dev,
 			    struct device_attribute *attr, char *buf)
 {
@@ -1089,6 +1126,7 @@ static ssize_t hw_info_show(struct device *dev,
 static DEVICE_ATTR_RO(hw_info);
 
 static struct attribute *rtw89_usb_attrs[] = {
+	&dev_attr_echo_sum.attr,
 	&dev_attr_hw_info.attr,
 	NULL,
 };
diff --git a/drivers/net/wireless/realtek/rtw89/usb.h b/drivers/net/wireless/realtek/rtw89/usb.h
index bdf312559743..9eba6264a9a2 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.h
+++ b/drivers/net/wireless/realtek/rtw89/usb.h
@@ -87,6 +87,8 @@ struct rtw89_usb {
 
 	struct sk_buff_head tx_queue[RTW89_TXCH_NUM];
 	atomic_t tx_inflight[RTW89_TXCH_NUM];
+
+	u32 echo_sum;
 };
 
 static inline struct rtw89_usb *rtw89_usb_priv(struct rtw89_dev *rtwdev)
-- 
2.25.1

RE: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Ping-Ke Shih]

Hi Johannes,

Need your comments on usage of sysfs.

Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Johnson Tsai <wenjie.tsai@realtek.com>
> 
> Expose the device's Serial Number (SN) and UUID from EFUSE through a
> read-only `hw_info` sysfs attribute on the USB interface device.
> 
> This hardware identification information is essential for user-space
> applications to uniquely identify, track, and manage specific Wi-Fi
> adapters. For example, in automated factory provisioning or device
> management systems, user-space tools rely on the EFUSE SN and UUID
> to bind specific configurations to a physical adapter. Currently,
> standard wireless APIs do not expose this low-level hardware
> information, making this sysfs node the only viable and necessary
> solution for user space to extract this data.
> 
> Relying on debugfs or setuid binaries is unviable for production
> environments, as explicitly requested by Valve (Steam). Steam frequently
> runs inside unprivileged containers (e.g., Flatpak) where debugfs and
> setuid binaries are inaccessible. Furthermore, many end-user systems
> disable debugfs in their kernel configs, and strict access controls
> (SELinux, AppArmor) block it regardless of permissions. Since Steam
> installs as an unprivileged user, setuid deployments are impossible.
> Consequently, exposing this data via a world-readable (0444) sysfs
> node is the only functional approach to ensure reliable, unprivileged
> access across diverse customer systems.
> 
> Example usage from user-space:
>   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
>   SN: 36 42 00 01 23
>   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> 
> User-space scripts can easily iterate over bound devices to extract
> this information:
>   for dev in /sys/bus/usb/drivers/rtw89_8852cu/[0-9]*:*; do
>       dev_id=$(basename "$dev")
>       echo "--- Device: /sys/bus/usb/devices/$dev_id ---"
>       cat "$dev/hw_info"
>   done
> 
> Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> Hi maintainers,
> 
> We are submitting this RFC to discuss the most appropriate upstream path for
> exposing hardware-specific IDs to unprivileged container environments.
> 
> 1. Given the strict environment limitations (Flatpak, missing debugfs, LSMs),
>    is a read-only sysfs attribute acceptable for this specific hardware data?
> 2. If exposing this globally via sysfs is not preferred, would it be acceptable
>    to restrict the creation of this node to specific vendor VID/PIDs only?
> 3. If sysfs is strictly a no-go for this use case, what is the upstream-recommended
>    method for an unprivileged, sandboxed application to retrieve eFuse data?

I also looked up lore.kernel.org and only found a thread commented by Kalle [1].
However, it is not clear to us if sysfs is suitable to read efuse SN/UUID.

[1] https://lore.kernel.org/linux-wireless/87ziib3da5.fsf@kamboji.qca.qualcomm.com/

> ---
>  drivers/net/wireless/realtek/rtw89/usb.c | 51 +++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
> index c6d55e669776..53dcb84af5c0 100644
> --- a/drivers/net/wireless/realtek/rtw89/usb.c
> +++ b/drivers/net/wireless/realtek/rtw89/usb.c
> @@ -1059,6 +1059,41 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
>  	usb_set_intfdata(intf, NULL);
>  }
> 
> +static ssize_t hw_info_show(struct device *dev,
> +			    struct device_attribute *attr, char *buf)
> +{
> +	struct usb_interface *intf = to_usb_interface(dev);
> +	struct ieee80211_hw *hw;
> +	struct rtw89_dev *rtwdev;
> +	struct rtw89_efuse *efuse;
> +	ssize_t ret;
> +
> +	device_lock(dev);

I think it isn't necessary to do lock/unlock in show ops. We will revise
it by v2.

[...]

Thanks
Ping-Ke

Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Johannes Berg]

Hi,

> > Example usage from user-space:
> >   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> >   SN: 36 42 00 01 23
> >   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa

Sysfs has a "one value per file" rule (soft rule according to the docs,
but harder in practice, I believe), so seems if anything that should be
two files. Maybe a UUID should also be formatted as such with %pU or
similar.

> I also looked up lore.kernel.org and only found a thread commented by Kalle [1].
> However, it is not clear to us if sysfs is suitable to read efuse SN/UUID.
> 
> [1] https://lore.kernel.org/linux-wireless/87ziib3da5.fsf@kamboji.qca.qualcomm.com/

It seems to me this was more in the context of _writable_ files to do
some operations.

I don't think I have a problem with this, but sysfs also has
documentation requirements, and we should probably ask
driver-core@lists.linux.dev.

I'm not really quite sure I see the _point_ of identifying the serial
number of a wifi device in a container, but I guess you do.

johannes

Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Greg KH]

On Tue, May 19, 2026 at 02:11:32PM +0200, Johannes Berg wrote:
> Hi,
> 
> > > Example usage from user-space:
> > >   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > >   SN: 36 42 00 01 23
> > >   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> 
> Sysfs has a "one value per file" rule (soft rule according to the docs,
> but harder in practice, I believe), so seems if anything that should be
> two files. Maybe a UUID should also be formatted as such with %pU or
> similar.

That should be 2 separate sysfs files please.

And yes, use %pU.

And be careful about exposing serial numbers to userspace, some systems
don't like normal users to read them so be sure to get the permissions
correct.  We had to add some USB code for ALLOW_SERIAL_NUMBER to make it
so that systems can handle this if they want to.

And shouldn't this just be the USB serial number to start with?  Why is
there a different string here?  We already have a sysfs file for this
value.

thanks,

greg k-h

RE: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Johnson Tsai]

On Tuesday, May 19, 2026 20:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, May 19, 2026 at 02:11:32PM +0200, Johannes Berg wrote:
> > Hi,
> >
> > > > Example usage from user-space:
> > > >   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > > >   SN: 36 42 00 01 23
> > > >   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> >
> > Sysfs has a "one value per file" rule (soft rule according to the
> > docs, but harder in practice, I believe), so seems if anything that
> > should be two files. Maybe a UUID should also be formatted as such
> > with %pU or similar.
> 
> That should be 2 separate sysfs files please.
> 
> And yes, use %pU.

The v2 patch will use separate `sn` and `uuid` attributes, with `uuid`
formatted via `%pU`. We also removed the spaces in `sn` to provide a clean
string.

Example usage from user-space:
  $ cat /sys/bus/usb/devices/2-3.1.2:1.0/sn
  3642000123
  $ cat /sys/bus/usb/devices/2-3.1.2:1.0/uuid
  aaec2b7c-0a55-4727-8de0-b30febccbbaa

> 
> And be careful about exposing serial numbers to userspace, some systems
> don't like normal users to read them so be sure to get the permissions correct.
> We had to add some USB code for ALLOW_SERIAL_NUMBER to make it so that
> systems can handle this if they want to.
> 
> And shouldn't this just be the USB serial number to start with?  Why is there a
> different string here?  We already have a sysfs file for this value.

Regarding the serial number and permission design, these are requirements 
from Valve, so we have CC'd them here to provide the background.

Hi Elliot and Charles, could you please help explain the requirements and use case here?

Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Greg KH]

On Wed, May 20, 2026 at 09:41:46AM +0000, Johnson Tsai wrote:
> 
> 
> On Tuesday, May 19, 2026 20:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, May 19, 2026 at 02:11:32PM +0200, Johannes Berg wrote:
> > > Hi,
> > >
> > > > > Example usage from user-space:
> > > > >   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > > > >   SN: 36 42 00 01 23
> > > > >   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> > >
> > > Sysfs has a "one value per file" rule (soft rule according to the
> > > docs, but harder in practice, I believe), so seems if anything that
> > > should be two files. Maybe a UUID should also be formatted as such
> > > with %pU or similar.
> > 
> > That should be 2 separate sysfs files please.
> > 
> > And yes, use %pU.
> 
> The v2 patch will use separate `sn` and `uuid` attributes, with `uuid`
> formatted via `%pU`. We also removed the spaces in `sn` to provide a clean
> string.
> 
> Example usage from user-space:
>   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/sn
>   3642000123
>   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/uuid
>   aaec2b7c-0a55-4727-8de0-b30febccbbaa

Wait, no, you are putting attributes in the USB interface device, which
is NOT the device your driver is creating.  Don't do that, it makes for
massive confusion.

> > And be careful about exposing serial numbers to userspace, some systems
> > don't like normal users to read them so be sure to get the permissions correct.
> > We had to add some USB code for ALLOW_SERIAL_NUMBER to make it so that
> > systems can handle this if they want to.
> > 
> > And shouldn't this just be the USB serial number to start with?  Why is there a
> > different string here?  We already have a sysfs file for this value.
> 
> Regarding the serial number and permission design, these are requirements 
> from Valve, so we have CC'd them here to provide the background.
> 
> Hi Elliot and Charles, could you please help explain the requirements and use case here?

The USB serial number is already exported in sysfs, why export it again
under a different filename?  That's ripe for total confusion :(

Also, where does this random UUID come from?  That's not part of the USB
spec, is it?  Why is it not just a USB string attribute like the spec
says to use for stuff like this?

thanks,

greg k-h

Re: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Elliot Saba]

Hello Greg, Johannes, thank you for your time and feedback on this patchset.

The purpose of this information is to provide access to two pieces of information, a serial number (also printed on the outside of the device, used for product tracking, RMAs, etc...) and a GUID (random entropy that is intentionally difficult to guess).
We use the GUID to establish a direct connection between the USB network adapter and another device.

To directly answer your USB questions, unfortunately the ASIC used in this product does not support customization of the USB serial number; all devices have the same USB serial number.  Indeed, I believe there is no mutable state on the device at all except for the e-fuses that are written at the factory to write these two values.  Given those constraints, we're trying to find the best way to raise this up to userspace, and we're grateful for your feedback.

This USB device is expected to operate on both Windows and Linux hosts, on the Windows side we have a custom driver that allows our host application (Steam) to directly query these fuses and setup the network connection appropriately.  We're attempting to upstream this capability as much as possible so that users running a vanilla kernel can take advantage of these features as much as possible.

With regards to permissions, we'd really like to make this serial number readable by non-root users so that the pairing functionality can work out-of-the-box without needing special udev/tmpfiles.d rules to adjust permissions to allow Steam to read this information, but we are simultaneously sympathetic to the desire to limit trackable/identifying information by default.  Of course we can adjust permissions however needed for our own Linux distribution, but in our effort to support the rest of the Linux ecosystem as best we can, we'd like to do our best to find a solution that would work everywhere.  We're open to comparing against any existing precedent for devices that necessarily require identifying information to perform their basic function, if you know of any.

Thank you,
-Elliot Saba

Re: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Greg KH]

On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> Hello Greg, Johannes, thank you for your time and feedback on this patchset.
> 
> The purpose of this information is to provide access to two pieces of information, a serial number (also printed on the outside of the device, used for product tracking, RMAs, etc...) and a GUID (random entropy that is intentionally difficult to guess).
> We use the GUID to establish a direct connection between the USB network adapter and another device.
> 
> To directly answer your USB questions, unfortunately the ASIC used in this product does not support customization of the USB serial number; all devices have the same USB serial number.  Indeed, I believe there is no mutable state on the device at all except for the e-fuses that are written at the factory to write these two values.  Given those constraints, we're trying to find the best way to raise this up to userspace, and we're grateful for your feedback.

Then where exactly does that "serial number" come from in the device so
that it can be read by the kernel, if not in the USB device itself?

> This USB device is expected to operate on both Windows and Linux hosts, on the Windows side we have a custom driver that allows our host application (Steam) to directly query these fuses and setup the network connection appropriately.  We're attempting to upstream this capability as much as possible so that users running a vanilla kernel can take advantage of these features as much as possible.

Great, why can't this driver also query the fuses?

> With regards to permissions, we'd really like to make this serial number readable by non-root users so that the pairing functionality can work out-of-the-box without needing special udev/tmpfiles.d rules to adjust permissions to allow Steam to read this information, but we are simultaneously sympathetic to the desire to limit trackable/identifying information by default.  Of course we can adjust permissions however needed for our own Linux distribution, but in our effort to support the rest of the Linux ecosystem as best we can, we'd like to do our best to find a solution that would work everywhere.  We're open to comparing against any existing precedent for devices that necessarily require identifying information to perform their basic function, if you know of any.

My objection is the placement of random sysfs files in the USB device
directory, for something that is not a USB device-specific thing, but
rather a driver-specific thing.  If this is a driver/device bound
specific thing, then put it in the device that the driver creates and
owns.  NOT in the device that the USB core creates and owns.

thanks,

greg k-h

RE: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Johnson Tsai]

On Thursday, May 21, 2026 18:58, Greg KH wrote:
> On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> > Hello Greg, Johannes, thank you for your time and feedback on this
> patchset.
> >
> > The purpose of this information is to provide access to two pieces of
> information, a serial number (also printed on the outside of the device, used
> for product tracking, RMAs, etc...) and a GUID (random entropy that is
> intentionally difficult to guess).
> > We use the GUID to establish a direct connection between the USB network
> adapter and another device.
> >
> > To directly answer your USB questions, unfortunately the ASIC used in this
> product does not support customization of the USB serial number; all devices
> have the same USB serial number.  Indeed, I believe there is no mutable state
> on the device at all except for the e-fuses that are written at the factory to
> write these two values.  Given those constraints, we're trying to find the best
> way to raise this up to userspace, and we're grateful for your feedback.
> 
> Then where exactly does that "serial number" come from in the device so that
> it can be read by the kernel, if not in the USB device itself?

The "serial number" we're talking about right now is not exposed through the standard 
USB descriptors. It is obtained via a vendor-specific H2C (Host-to-Chip) 
command, which reads EFUSE data into the rtw89 driver. 
Both SN and UUID are stored as specific fields within that data block.

> 
> > This USB device is expected to operate on both Windows and Linux hosts,
> on the Windows side we have a custom driver that allows our host application
> (Steam) to directly query these fuses and setup the network connection
> appropriately.  We're attempting to upstream this capability as much as
> possible so that users running a vanilla kernel can take advantage of these
> features as much as possible.
> 
> Great, why can't this driver also query the fuses?

Yes, the driver can query the fuses directly, similar to the Windows driver 
implementation.
In this RFC v1, the H2C implementation is intentionally omitted to keep the discussion 
focused on the sysfs interface design and gather early feedback from the 
community.

> 
> > With regards to permissions, we'd really like to make this serial number
> readable by non-root users so that the pairing functionality can work out-of-
> the-box without needing special udev/tmpfiles.d rules to adjust permissions
> to allow Steam to read this information, but we are simultaneously
> sympathetic to the desire to limit trackable/identifying information by default.
> Of course we can adjust permissions however needed for our own Linux
> distribution, but in our effort to support the rest of the Linux ecosystem as
> best we can, we'd like to do our best to find a solution that would work
> everywhere.  We're open to comparing against any existing precedent for
> devices that necessarily require identifying information to perform their basic
> function, if you know of any.
> 
> My objection is the placement of random sysfs files in the USB device
> directory, for something that is not a USB device-specific thing, but rather a
> driver-specific thing.  If this is a driver/device bound specific thing, then put it
> in the device that the driver creates and owns.  NOT in the device that the USB
> core creates and owns.
> 

We completely agree with your concern. Since accessing these values requires 
driver-specific commands rather than standard USB requests, they should not live 
under the USB device directory.

In the upcoming v2 patchset, we will move these attributes under the wiphy device 
managed by the rtw89 driver. The paths will be something like: 

  $ cat /sys/class/ieee80211/phy0/sn
  3642000123
  $ cat /sys/class/ieee80211/phy0/uuid
  aaec2b7c-0a55-4727-8de0-b30febccbbaa

Additionally, these sysfs attributes will be strictly limited to Valve's specific VID/PID 
pair and will not be exposed on generic RTL8852CU devices.


Thanks,

Johnson

Re: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Greg KH]

On Thu, May 21, 2026 at 01:06:09PM +0000, Johnson Tsai wrote:
> 
> On Thursday, May 21, 2026 18:58, Greg KH wrote:
> > On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> > > Hello Greg, Johannes, thank you for your time and feedback on this
> > patchset.
> > >
> > > The purpose of this information is to provide access to two pieces of
> > information, a serial number (also printed on the outside of the device, used
> > for product tracking, RMAs, etc...) and a GUID (random entropy that is
> > intentionally difficult to guess).
> > > We use the GUID to establish a direct connection between the USB network
> > adapter and another device.
> > >
> > > To directly answer your USB questions, unfortunately the ASIC used in this
> > product does not support customization of the USB serial number; all devices
> > have the same USB serial number.  Indeed, I believe there is no mutable state
> > on the device at all except for the e-fuses that are written at the factory to
> > write these two values.  Given those constraints, we're trying to find the best
> > way to raise this up to userspace, and we're grateful for your feedback.
> > 
> > Then where exactly does that "serial number" come from in the device so that
> > it can be read by the kernel, if not in the USB device itself?
> 
> The "serial number" we're talking about right now is not exposed through the standard 
> USB descriptors. It is obtained via a vendor-specific H2C (Host-to-Chip) 
> command, which reads EFUSE data into the rtw89 driver. 
> Both SN and UUID are stored as specific fields within that data block.

Ick, ok, gotta love custom USB commands :(

> > > This USB device is expected to operate on both Windows and Linux hosts,
> > on the Windows side we have a custom driver that allows our host application
> > (Steam) to directly query these fuses and setup the network connection
> > appropriately.  We're attempting to upstream this capability as much as
> > possible so that users running a vanilla kernel can take advantage of these
> > features as much as possible.
> > 
> > Great, why can't this driver also query the fuses?
> 
> Yes, the driver can query the fuses directly, similar to the Windows driver 
> implementation.
> In this RFC v1, the H2C implementation is intentionally omitted to keep the discussion 
> focused on the sysfs interface design and gather early feedback from the 
> community.

Great, put these on the network device that you create as they are not a
generic USB attribute, and properly document them in Documentation/ABI/

> 
> > 
> > > With regards to permissions, we'd really like to make this serial number
> > readable by non-root users so that the pairing functionality can work out-of-
> > the-box without needing special udev/tmpfiles.d rules to adjust permissions
> > to allow Steam to read this information, but we are simultaneously
> > sympathetic to the desire to limit trackable/identifying information by default.
> > Of course we can adjust permissions however needed for our own Linux
> > distribution, but in our effort to support the rest of the Linux ecosystem as
> > best we can, we'd like to do our best to find a solution that would work
> > everywhere.  We're open to comparing against any existing precedent for
> > devices that necessarily require identifying information to perform their basic
> > function, if you know of any.
> > 
> > My objection is the placement of random sysfs files in the USB device
> > directory, for something that is not a USB device-specific thing, but rather a
> > driver-specific thing.  If this is a driver/device bound specific thing, then put it
> > in the device that the driver creates and owns.  NOT in the device that the USB
> > core creates and owns.
> > 
> 
> We completely agree with your concern. Since accessing these values requires 
> driver-specific commands rather than standard USB requests, they should not live 
> under the USB device directory.

Great

> In the upcoming v2 patchset, we will move these attributes under the wiphy device 
> managed by the rtw89 driver. The paths will be something like: 
> 
>   $ cat /sys/class/ieee80211/phy0/sn
>   3642000123

Spell it out, you have almost unlimited number of characters for a file name :)

>   $ cat /sys/class/ieee80211/phy0/uuid
>   aaec2b7c-0a55-4727-8de0-b30febccbbaa
> 
> Additionally, these sysfs attributes will be strictly limited to Valve's specific VID/PID 
> pair and will not be exposed on generic RTL8852CU devices.

Great, please document it as such.

thanks,

greg k-h