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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9a757d21-a6e0-4022-b844-57c91323af5e@kernel.org>
Date: Wed, 6 Aug 2025 09:06:30 -0500
From: Mario Limonciello <superm1@...nel.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>,
 "Rangoju, Raju" <raju.rangoju@....com>
Cc: linux-usb@...r.kernel.org, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, andreas.noever@...il.com,
 michael.jamet@...el.com, westeri@...nel.org, YehezkelShB@...il.com,
 bhelgaas@...gle.com, Sanath.S@....com
Subject: Re: [PATCH 0/3] thunderbolt: Update XDomain vendor properties
 dynamically

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
>