Re: [PATCH 0/3] thunderbolt: Update XDomain vendor properties dynamically

[Mika Westerberg]

On Fri, Aug 08, 2025 at 10:02:08AM +0100, Greg KH wrote:
> On Fri, Aug 08, 2025 at 06:45:38AM +0200, Mika Westerberg wrote:
> > On Thu, Aug 07, 2025 at 11:07:39AM -0500, Mario Limonciello wrote:
> > > On 8/7/25 11:02 AM, Greg KH wrote:
> > > > On Thu, Aug 07, 2025 at 07:15:33AM +0200, Mika Westerberg wrote:
> > > > > On Wed, Aug 06, 2025 at 05:58:26PM +0100, Greg KH wrote:
> > > > > > On Wed, Aug 06, 2025 at 05:00:24PM +0200, Mika Westerberg wrote:
> > > > > > > On Wed, Aug 06, 2025 at 09:06:30AM -0500, Mario Limonciello wrote:
> > > > > > > > On 8/6/2025 3:51 AM, Mika Westerberg wrote:
> > > > > > > > > On Wed, Aug 06, 2025 at 11:46:04AM +0530, Rangoju, Raju wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 7/28/2025 12:17 PM, Mika Westerberg wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, Jul 22, 2025 at 11:20:23PM +0530, Raju Rangoju wrote:
> > > > > > > > > > > > This patch series aims to update vendor properties for XDomain
> > > > > > > > > > > > dynamically for vendors like AMD, Intel and ASMedia.
> > > > > > > > > > > 
> > > > > > > > > > > The XDomain properties pretty much describe "software" not the underlying
> > > > > > > > > > > hardware so I don't understand why this is needed? We could have some USB
> > > > > > > > > > > IF registered Linux specific ID there but I don't see why this matters at
> > > > > > > > > > > all.
> > > > > > > > > > 
> > > > > > > > > > Currently, it is showing up as "Intel" on AMD host controllers during
> > > > > > > > > > inter-domain connection. I suppose an alternative is to just call it "Linux"
> > > > > > > > > > or "Linux Connection Manager" to ensure we accurately represent the
> > > > > > > > > > connections across different systems.
> > > > > > > > > > 
> > > > > > > > > > I appreciate your guidance on this and suggestions you might have.
> > > > > > > > > 
> > > > > > > > > Yeah, something like that (I prefer "Linux"). The "ID" still is 0x8086
> > > > > > > > > though but I don't think that matters. AFAIK we have other "donated" IDs in
> > > > > > > > > use in Linux. Let me check on our side if that's okay.
> > > > > > > > 
> > > > > > > > Having looked through this discussion I personally like "Linux" for this
> > > > > > > > string too.
> > > > > > > > 
> > > > > > > > As for the vendor ID doesn't the LF have an ID assigned already of 0x1d6b?
> > > > > > > > Would it make sense to use that?
> > > > > > > 
> > > > > > > AFAIK that's PCI ID, right? It should be USB IF assigned ID and LF is not
> > > > > > > here at least:
> > > > > > > 
> > > > > > >    https://www.usb.org/members
> > > > > > > 
> > > > > > > If it really matters we can sure register one.
> > > > > > 
> > > > > > Linux has an official USB vendor id, we use it for when Linux is used as
> > > > > > a USB gadget device and in a few other places.  If you want to reserve a
> > > > > > product id from it, just let me know and I can dole it out (the list is
> > > > > > around here somewhere...)
> > > > > 
> > > > > Yes please :) I think this is the right thing to do.
> > > > 
> > > > Great, please let me know why you need it and what it will be for and
> > > > why.  I totally can not figure that out from this thread...
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Actually it's a very similar reason for the gadget drivers.  When connected
> > > to other machines and using the USB4 networking feature (like a host to host
> > > communication) the Linux kernel will identify itself and the other side will
> > > show that to a user.
> > > 
> > > So right now it's got some hardcoded values.  This thread was prompting to
> > > change the strings, but it's brought about the realization that we should
> > > also be using a Linux specific vendor (the one uses in gadget devices) and
> > > then a Linux specific "device id" which you will allocate.
> > > 
> > > Hope that helps!
> > 
> > Thanks Mario, yes exactly that :)
> > 
> > "Linux USB4 Inter-domain discovery properties" in a nutshell.
> 
> Ok, sounds good.  Here's the currently assigned ids that we have so far:
> 
> # Linux Foundation USB id list.
> 1d6b  Linux Foundation
>         0001  1.1 root hub
>         0002  2.0 root hub
>         0003  3.0 root hub
>         0010  USB Debug Target
>         0011  USB GDB Target
>         0100  PTP Gadget
>         0101  Audio Gadget
>         0102  EEM Gadget
>         0103  NCM (Ethernet) Gadget
>         0104  Multifunction Composite Gadget
>         0105  FunctionFS Gadget
>         0106  Composite Gadget: ACM + Mass Storage
>         0107  Embedded Hub Gadgetg
>         0200  Qemu Audio Device
>         0246  BlueZ Host Stack
>         0247  BlueZ for Android
> 
> Any specific number feel drawn toward using?  Would 0004 make sense as this is
> "USB 4" or should we save that if we ever get a USB 4.0 root hub?

0004 USB4

sounds good to me. In USB4 there is no "root hub". It's called host router
(but we do have device routers that are called USB4 hubs for added
confusion ;-).

But I'm fine with other numbers too, does not matter if you want to save it
for some future USB variant.