drivers/thunderbolt/nvm.c | 2 +- drivers/thunderbolt/xdomain.c | 32 +++++++++++++++++++++----------- include/linux/pci_ids.h | 1 + 3 files changed, 23 insertions(+), 12 deletions(-)
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
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
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
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
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 >
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.
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
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.
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
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!
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.
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
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.
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
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.
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
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
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
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
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.
© 2016 - 2025 Red Hat, Inc.