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

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

[Raju Rangoju]

This patch series aims to update vendor properties for XDomain
dynamically for vendors like AMD, Intel and ASMedia.

Raju Rangoju (3):
  thunderbolt: Dynamically populate vendor properties for XDomain
  PCI: Add PCI vendor ID for ASMedia USB4 devices
  thunderbolt: Add vendor ASMedia in update_property_block for XDomain

 drivers/thunderbolt/nvm.c     |  2 +-
 drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++-----------
 include/linux/pci_ids.h       |  1 +
 3 files changed, 23 insertions(+), 12 deletions(-)

-- 
2.34.1

[PATCH 1/3] thunderbolt: Dynamically populate vendor properties for XDomain

[Raju Rangoju]

Currently, the XDomain driver hardcodes the vendor information
properties, but there are multiple vendors that need to be
supported. Remove the hardcoded properties and fill it
dynamically in the update_property_block.

Co-developed-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
---
 drivers/thunderbolt/xdomain.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index b0630e6d9472..749faa7c487f 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -653,6 +653,8 @@ static void update_property_block(struct tb_xdomain *xd)
 	 */
 	if (!xd->local_property_block ||
 	    xd->local_property_block_gen < xdomain_property_block_gen) {
+		struct tb_switch *sw = tb_xdomain_parent(xd);
+		struct pci_dev *pdev = sw->tb->nhi->pdev;
 		struct tb_property_dir *dir;
 		int ret, block_len;
 		u32 *block;
@@ -664,7 +666,21 @@ static void update_property_block(struct tb_xdomain *xd)
 		}
 
 		/* Fill in non-static properties now */
+		tb_property_add_immediate(dir, "vendorid", pdev->vendor);
+		switch (pdev->vendor) {
+		case PCI_VENDOR_ID_INTEL:
+			tb_property_add_text(dir, "vendorid", "Intel Corp.");
+			break;
+		case PCI_VENDOR_ID_AMD:
+			tb_property_add_text(dir, "vendorid", "AMD");
+			break;
+		default:
+			tb_property_add_text(dir, "vendorid", "Unknown Vendor");
+			break;
+		}
+		tb_property_add_immediate(dir, "deviceid", sw->config.device_id);
 		tb_property_add_text(dir, "deviceid", utsname()->nodename);
+		tb_property_add_immediate(dir, "devicerv", sw->config.revision);
 		tb_property_add_immediate(dir, "maxhopid", xd->local_max_hopid);
 
 		ret = tb_property_format_dir(dir, NULL, 0);
@@ -2555,18 +2571,9 @@ int tb_xdomain_init(void)
 		return -ENOMEM;
 
 	/*
-	 * Initialize standard set of properties without any service
-	 * directories. Those will be added by service drivers
-	 * themselves when they are loaded.
-	 *
-	 * Rest of the properties are filled dynamically based on these
-	 * when the P2P connection is made.
+	 * All the properties are filled dynamically when the
+	 * P2P connection is made.
 	 */
-	tb_property_add_immediate(xdomain_property_dir, "vendorid",
-				  PCI_VENDOR_ID_INTEL);
-	tb_property_add_text(xdomain_property_dir, "vendorid", "Intel Corp.");
-	tb_property_add_immediate(xdomain_property_dir, "deviceid", 0x1);
-	tb_property_add_immediate(xdomain_property_dir, "devicerv", 0x80000100);
 
 	xdomain_property_block_gen = get_random_u32();
 	return 0;
-- 
2.34.1

[PATCH 2/3] PCI: Add PCI vendor ID for ASMedia USB4 devices

[Raju Rangoju]

Add a new PCI vendor ID (PCI_VENDOR_ID_ASMEDIA_USB4) for ASMedia
USB4 devices. This change enables proper identification and support
for ASMedia USB4 hardware in the kernel.

Co-developed-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
---
 include/linux/pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index e2d71b6fdd84..3397954ce96e 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2592,6 +2592,7 @@
 #define PCI_SUBDEVICE_ID_QEMU            0x1100
 
 #define PCI_VENDOR_ID_ASMEDIA		0x1b21
+#define PCI_VENDOR_ID_ASMEDIA_USB4	0x174C
 
 #define PCI_VENDOR_ID_REDHAT		0x1b36
 
-- 
2.34.1

[PATCH 3/3] thunderbolt: Add vendor ASMedia in update_property_block for XDomain

[Raju Rangoju]

Replace vendor ID 0x174c with PCI_VENDOR_ID_ASMEDIA_USB4 for
better maintainability. Add vendor name ASMedia for XDomain
properties.

Co-developed-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
---
 drivers/thunderbolt/nvm.c     | 2 +-
 drivers/thunderbolt/xdomain.c | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/nvm.c b/drivers/thunderbolt/nvm.c
index 8901db2de327..b6ccd8ea16a4 100644
--- a/drivers/thunderbolt/nvm.c
+++ b/drivers/thunderbolt/nvm.c
@@ -191,7 +191,7 @@ static const struct tb_nvm_vendor_ops asmedia_switch_nvm_ops = {
 
 /* Router vendor NVM support table */
 static const struct tb_nvm_vendor switch_nvm_vendors[] = {
-	{ 0x174c, &asmedia_switch_nvm_ops },
+	{ PCI_VENDOR_ID_ASMEDIA_USB4, &asmedia_switch_nvm_ops },
 	{ PCI_VENDOR_ID_INTEL, &intel_switch_nvm_ops },
 	{ 0x8087, &intel_switch_nvm_ops },
 };
diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index 749faa7c487f..f512aacb5f60 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -674,6 +674,9 @@ static void update_property_block(struct tb_xdomain *xd)
 		case PCI_VENDOR_ID_AMD:
 			tb_property_add_text(dir, "vendorid", "AMD");
 			break;
+		case PCI_VENDOR_ID_ASMEDIA_USB4:
+			tb_property_add_text(dir, "vendorid", "ASMedia");
+			break;
 		default:
 			tb_property_add_text(dir, "vendorid", "Unknown Vendor");
 			break;
-- 
2.34.1

Re: [PATCH 2/3] PCI: Add PCI vendor ID for ASMedia USB4 devices

[Bjorn Helgaas]

On Tue, Jul 22, 2025 at 11:20:25PM +0530, Raju Rangoju wrote:
> Add a new PCI vendor ID (PCI_VENDOR_ID_ASMEDIA_USB4) for ASMedia
> USB4 devices. This change enables proper identification and support
> for ASMedia USB4 hardware in the kernel.
> 
> Co-developed-by: Sanath S <Sanath.S@amd.com>
> Signed-off-by: Sanath S <Sanath.S@amd.com>
> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
> ---
>  include/linux/pci_ids.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index e2d71b6fdd84..3397954ce96e 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2592,6 +2592,7 @@
>  #define PCI_SUBDEVICE_ID_QEMU            0x1100
>  
>  #define PCI_VENDOR_ID_ASMEDIA		0x1b21
> +#define PCI_VENDOR_ID_ASMEDIA_USB4	0x174C
>  
>  #define PCI_VENDOR_ID_REDHAT		0x1b36

Sort by Vendor ID value (not the name), per the comment at the top.

Use lower-case hex to match style (not universally observed, but
close).

Per https://pcisig.com/membership/member-companies, 0x174c is not
reserved, although the same is true for 0x1b21 and many other Vendor
IDs.  Do you know the history of 0x174c and 0x1b21, or why these don't
show up as reserved?

With these,

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

Bjorn

Re: [PATCH 2/3] PCI: Add PCI vendor ID for ASMedia USB4 devices

[Rangoju, Raju]

On 7/23/2025 12:44 AM, Bjorn Helgaas wrote:
> On Tue, Jul 22, 2025 at 11:20:25PM +0530, Raju Rangoju wrote:
>> Add a new PCI vendor ID (PCI_VENDOR_ID_ASMEDIA_USB4) for ASMedia
>> USB4 devices. This change enables proper identification and support
>> for ASMedia USB4 hardware in the kernel.
>>
>> Co-developed-by: Sanath S <Sanath.S@amd.com>
>> Signed-off-by: Sanath S <Sanath.S@amd.com>
>> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
>> ---
>>   include/linux/pci_ids.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index e2d71b6fdd84..3397954ce96e 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -2592,6 +2592,7 @@
>>   #define PCI_SUBDEVICE_ID_QEMU            0x1100
>>   
>>   #define PCI_VENDOR_ID_ASMEDIA		0x1b21
>> +#define PCI_VENDOR_ID_ASMEDIA_USB4	0x174C
>>   
>>   #define PCI_VENDOR_ID_REDHAT		0x1b36
> 
> Sort by Vendor ID value (not the name), per the comment at the top.
> 
> Use lower-case hex to match style (not universally observed, but
> close).

Sure Bjorn, I'll address these changes in v2.

> 
> Per https://pcisig.com/membership/member-companies, 0x174c is not
> reserved, although the same is true for 0x1b21 and many other Vendor
> IDs.  Do you know the history of 0x174c and 0x1b21, or why these don't
> show up as reserved?

Chloe_Chen@asmedia.com.tw, could you please comment here?

> 
> With these,
> 
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> 
> Bjorn

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

[Mika Westerberg]

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.

> Raju Rangoju (3):
>   thunderbolt: Dynamically populate vendor properties for XDomain
>   PCI: Add PCI vendor ID for ASMedia USB4 devices
>   thunderbolt: Add vendor ASMedia in update_property_block for XDomain
> 
>  drivers/thunderbolt/nvm.c     |  2 +-
>  drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++-----------
>  include/linux/pci_ids.h       |  1 +
>  3 files changed, 23 insertions(+), 12 deletions(-)
> 
> -- 
> 2.34.1

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

[Rangoju, Raju]

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.

> 
>> Raju Rangoju (3):
>>    thunderbolt: Dynamically populate vendor properties for XDomain
>>    PCI: Add PCI vendor ID for ASMedia USB4 devices
>>    thunderbolt: Add vendor ASMedia in update_property_block for XDomain
>>
>>   drivers/thunderbolt/nvm.c     |  2 +-
>>   drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++-----------
>>   include/linux/pci_ids.h       |  1 +
>>   3 files changed, 23 insertions(+), 12 deletions(-)
>>
>> -- 
>> 2.34.1

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

[Mika Westerberg]

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.

> 
> > 
> > > Raju Rangoju (3):
> > >    thunderbolt: Dynamically populate vendor properties for XDomain
> > >    PCI: Add PCI vendor ID for ASMedia USB4 devices
> > >    thunderbolt: Add vendor ASMedia in update_property_block for XDomain
> > > 
> > >   drivers/thunderbolt/nvm.c     |  2 +-
> > >   drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++-----------
> > >   include/linux/pci_ids.h       |  1 +
> > >   3 files changed, 23 insertions(+), 12 deletions(-)
> > > 
> > > -- 
> > > 2.34.1

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

[Mario Limonciello]

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?

I was also thinking about the device ID, should we consider encoding the 
VERSION, PATCHLEVEL, and SUBLEVEL into the ID?  The reason I'm thinking 
about that is let's say there is some bug found in the CM on Linux and 
another implementation decides to work around it.  We get wind of it and 
fix the bug but in Linux but now what about the other end?  If we give 
them a hint on the version by putting it in the device ID they can 
potentially key off that to decide to tear out the workaround.

> 
>>
>>>
>>>> Raju Rangoju (3):
>>>>     thunderbolt: Dynamically populate vendor properties for XDomain
>>>>     PCI: Add PCI vendor ID for ASMedia USB4 devices
>>>>     thunderbolt: Add vendor ASMedia in update_property_block for XDomain
>>>>
>>>>    drivers/thunderbolt/nvm.c     |  2 +-
>>>>    drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++-----------
>>>>    include/linux/pci_ids.h       |  1 +
>>>>    3 files changed, 23 insertions(+), 12 deletions(-)
>>>>
>>>> -- 
>>>> 2.34.1
> 

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

[Mika Westerberg]

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.

> I was also thinking about the device ID, should we consider encoding the
> VERSION, PATCHLEVEL, and SUBLEVEL into the ID?  The reason I'm thinking
> about that is let's say there is some bug found in the CM on Linux and
> another implementation decides to work around it.  We get wind of it and fix
> the bug but in Linux but now what about the other end?  If we give them a
> hint on the version by putting it in the device ID they can potentially key
> off that to decide to tear out the workaround.

I'm not sure that's a good idea. Then we expose also all the known
vulnerabilities.

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

[Mario Limonciello]

On 8/6/2025 10:00 AM, 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.

I see that it's used by drivers/usb/gadget/legacy.c for a few USB 
devices too.

So it's "already in the wild".

> 
>> I was also thinking about the device ID, should we consider encoding the
>> VERSION, PATCHLEVEL, and SUBLEVEL into the ID?  The reason I'm thinking
>> about that is let's say there is some bug found in the CM on Linux and
>> another implementation decides to work around it.  We get wind of it and fix
>> the bug but in Linux but now what about the other end?  If we give them a
>> hint on the version by putting it in the device ID they can potentially key
>> off that to decide to tear out the workaround.
> 
> I'm not sure that's a good idea. Then we expose also all the known
> vulnerabilities.

Yeah I see your point.  This wasn't a strong feeling on my side, leaving 
this as is is fine.

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

[Greg KH]

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...)

Note, the LF is NOT listed as a USB-IF member anymore, as the USB-IF
kicked us out at the request of one of their founding members many years
ago.  But we still got to keep the product id, they can't take that away
from us :)

thanks,

greg k-h

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

[Mika Westerberg]

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.

> Note, the LF is NOT listed as a USB-IF member anymore, as the USB-IF
> kicked us out at the request of one of their founding members many years
> ago.  But we still got to keep the product id, they can't take that away
> from us :)

Hehe, understood.

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

[Greg KH]

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

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

[Mario Limonciello]

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!

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

[Mika Westerberg]

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.

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

[Greg KH]

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

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.

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

[Greg KH]

On Fri, Aug 08, 2025 at 11:13:13AM +0200, Mika Westerberg wrote:
> 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.

Ok, use 0004 for this.  But what should I use for the text string here
in the usb.ids file?

thanks,

greg k-h

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

[Mika Westerberg]

On Fri, Aug 08, 2025 at 04:13:28PM +0100, Greg KH wrote:
> > 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.
> 
> Ok, use 0004 for this.  But what should I use for the text string here
> in the usb.ids file?

Thanks! I'll cook up a patch changing these.

I don't think it should be in usb.ids because it is not visible anywhere
except over USB4 link (between hosts). You don't see this through USB 2.x
or 3.x.

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

[Mika Westerberg]

On Mon, Aug 11, 2025 at 06:53:07AM +0200, Mika Westerberg wrote:
> On Fri, Aug 08, 2025 at 04:13:28PM +0100, Greg KH wrote:
> > > 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.
> > 
> > Ok, use 0004 for this.  But what should I use for the text string here
> > in the usb.ids file?
> 
> Thanks! I'll cook up a patch changing these.
> 
> I don't think it should be in usb.ids because it is not visible anywhere
> except over USB4 link (between hosts). You don't see this through USB 2.x
> or 3.x.

Of course for documentation purposes it could be:

    0004 Linux USB4 Connection Manager

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

[Greg KH]

On Mon, Aug 11, 2025 at 06:53:07AM +0200, Mika Westerberg wrote:
> On Fri, Aug 08, 2025 at 04:13:28PM +0100, Greg KH wrote:
> > > 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.
> > 
> > Ok, use 0004 for this.  But what should I use for the text string here
> > in the usb.ids file?
> 
> Thanks! I'll cook up a patch changing these.
> 
> I don't think it should be in usb.ids because it is not visible anywhere
> except over USB4 link (between hosts). You don't see this through USB 2.x
> or 3.x.

It goes in usb.ids as that is what I use to keep track of all of the
assigned product ids for this vendor :)

So, should I use "USB 4.0 host link" or something else?

thanks,

greg k-h

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

[Mika Westerberg]

On Mon, Aug 11, 2025 at 07:28:21AM +0200, Greg KH wrote:
> On Mon, Aug 11, 2025 at 06:53:07AM +0200, Mika Westerberg wrote:
> > On Fri, Aug 08, 2025 at 04:13:28PM +0100, Greg KH wrote:
> > > > 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.
> > > 
> > > Ok, use 0004 for this.  But what should I use for the text string here
> > > in the usb.ids file?
> > 
> > Thanks! I'll cook up a patch changing these.
> > 
> > I don't think it should be in usb.ids because it is not visible anywhere
> > except over USB4 link (between hosts). You don't see this through USB 2.x
> > or 3.x.
> 
> It goes in usb.ids as that is what I use to keep track of all of the
> assigned product ids for this vendor :)

Right, got it.

> So, should I use "USB 4.0 host link" or something else?

USB4 Connection Manager

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

[Greg KH]

On Mon, Aug 11, 2025 at 07:25:55AM +0200, Mika Westerberg wrote:
> On Mon, Aug 11, 2025 at 06:53:07AM +0200, Mika Westerberg wrote:
> > On Fri, Aug 08, 2025 at 04:13:28PM +0100, Greg KH wrote:
> > > > 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.
> > > 
> > > Ok, use 0004 for this.  But what should I use for the text string here
> > > in the usb.ids file?
> > 
> > Thanks! I'll cook up a patch changing these.
> > 
> > I don't think it should be in usb.ids because it is not visible anywhere
> > except over USB4 link (between hosts). You don't see this through USB 2.x
> > or 3.x.
> 
> Of course for documentation purposes it could be:
> 
>     0004 Linux USB4 Connection Manager
> 

Now updated, thanks!

greg k-h