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.
