linux-kernel - Re: [PATCH v1 1/1] sub: cdns3: Use predefined PCI vendor ID constant

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] [day] [month] [year] [list]

Message-ID: <ZvFwppgtysrFR6Dx@smile.fi.intel.com>
Date: Mon, 23 Sep 2024 16:44:06 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Roger Quadros <rogerq@...nel.org>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Chen <peter.chen@...nel.org>,
	Pawel Laszczak <pawell@...ence.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v1 1/1] sub: cdns3: Use predefined PCI vendor ID constant

On Mon, Sep 23, 2024 at 04:24:15PM +0300, Roger Quadros wrote:
> On 23/09/2024 15:53, Andy Shevchenko wrote:
> > On Mon, Sep 23, 2024 at 03:42:20PM +0300, Roger Quadros wrote:
> >> On 13/09/2024 16:17, Andy Shevchenko wrote:

...

> >>> -#define CDNS_DEVICE_ID		0x0200
> >>> -#define CDNS_DRD_ID		0x0100
> >>> -#define CDNS_DRD_IF		(PCI_CLASS_SERIAL_USB << 8 | 0x80)
> >>> +#define PCI_DEVICE_ID_CDNS_USB3		0x0100
> >>
> >> This is an entirely different card who's device ID should be 0x200?
> >> Also I don't think this card supports USB3 so it is a wrong name choice.
> > 
> > Are you stating that 0x0100 in both cases points to the *different* devices?!
> > This is unbelievable, however possible abuse of PCI IDs.
> 
> I am not entirely sure.
> What I do know is that one card should be USBSS (0x100) and other should be
> USBSSP (0x200). P for super-speed-Plus.

That's my understanding as well.

> Also please see commit 96b96b2a567f ("usb: cdnsp: changes PCI Device ID to
> fix conflict with CNDS3 driver")

I believe this is an interesting way to solve the issue "enumeration with two
or more drivers for the same HW". So, 0x100 in here is used just to see which
driver is in use (has been chosen at build time?).

That said, the 0x100 in both cases seems to me the _same_ device in question.
Hence it should be called the same, whatever you prefer. So, since the patches
are already in USB Next, feel free to update the constant definition names as
it looks like you are much more familiar with the hardware than me.

-- 
With Best Regards,
Andy Shevchenko