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

[Greg KH <gregkh@linuxfoundation.org>]

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?

thanks,

greg k-h