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

[Greg KH <gregkh@linuxfoundation.org>]

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