From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <superm1@kernel.org>
Cc: "Rangoju, Raju" <raju.rangoju@amd.com>,
linux-usb@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, andreas.noever@gmail.com,
michael.jamet@intel.com, westeri@kernel.org,
YehezkelShB@gmail.com, bhelgaas@google.com, Sanath.S@amd.com
Subject: Re: [PATCH 0/3] thunderbolt: Update XDomain vendor properties dynamically
Date: Wed, 6 Aug 2025 17:00:24 +0200 [thread overview]
Message-ID: <20250806150024.GF476609@black.igk.intel.com> (raw)
In-Reply-To: <9a757d21-a6e0-4022-b844-57c91323af5e@kernel.org>
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.
next prev parent reply other threads:[~2025-08-06 15:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 17:50 [PATCH 0/3] thunderbolt: Update XDomain vendor properties dynamically Raju Rangoju
2025-07-22 17:50 ` [PATCH 1/3] thunderbolt: Dynamically populate vendor properties for XDomain Raju Rangoju
2025-07-22 17:50 ` [PATCH 2/3] PCI: Add PCI vendor ID for ASMedia USB4 devices Raju Rangoju
2025-07-22 19:14 ` Bjorn Helgaas
2025-07-23 10:16 ` Rangoju, Raju
2025-07-22 17:50 ` [PATCH 3/3] thunderbolt: Add vendor ASMedia in update_property_block for XDomain Raju Rangoju
2025-07-28 6:47 ` [PATCH 0/3] thunderbolt: Update XDomain vendor properties dynamically Mika Westerberg
2025-08-06 6:16 ` Rangoju, Raju
2025-08-06 8:51 ` Mika Westerberg
2025-08-06 14:06 ` Mario Limonciello
2025-08-06 15:00 ` Mika Westerberg [this message]
2025-08-06 15:05 ` Mario Limonciello
2025-08-06 16:58 ` Greg KH
2025-08-07 5:15 ` Mika Westerberg
2025-08-07 16:02 ` Greg KH
2025-08-07 16:07 ` Mario Limonciello
2025-08-08 4:45 ` Mika Westerberg
2025-08-08 9:02 ` Greg KH
2025-08-08 9:13 ` Mika Westerberg
2025-08-08 15:13 ` Greg KH
2025-08-11 4:53 ` Mika Westerberg
2025-08-11 5:25 ` Mika Westerberg
2025-08-13 15:26 ` Greg KH
2025-08-11 5:28 ` Greg KH
2025-08-11 7:02 ` Mika Westerberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250806150024.GF476609@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=Sanath.S@amd.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.com \
--cc=raju.rangoju@amd.com \
--cc=superm1@kernel.org \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.