From: Mario Limonciello <superm1@kernel.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
"Rangoju, Raju" <raju.rangoju@amd.com>
Cc: 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 09:06:30 -0500 [thread overview]
Message-ID: <9a757d21-a6e0-4022-b844-57c91323af5e@kernel.org> (raw)
In-Reply-To: <20250806085118.GE476609@black.igk.intel.com>
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
>
next prev parent reply other threads:[~2025-08-06 14:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 17:50 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 [this message]
2025-08-06 15:00 ` Mika Westerberg
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=9a757d21-a6e0-4022-b844-57c91323af5e@kernel.org \
--to=superm1@kernel.org \
--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=mika.westerberg@linux.intel.com \
--cc=raju.rangoju@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®