public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Roger Quadros <rogerq@kernel.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Peter Chen <peter.chen@kernel.org>,
	Pawel Laszczak <pawell@cadence.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v1 1/1] sub: cdns3: Use predefined PCI vendor ID constant
Date: Mon, 23 Sep 2024 16:44:06 +0300	[thread overview]
Message-ID: <ZvFwppgtysrFR6Dx@smile.fi.intel.com> (raw)
In-Reply-To: <ed7e7044-1b5a-44a4-be24-7c94278244b0@kernel.org>

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



      reply	other threads:[~2024-09-23 13:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 13:17 [PATCH v1 1/1] sub: cdns3: Use predefined PCI vendor ID constant Andy Shevchenko
2024-09-23 12:42 ` Roger Quadros
2024-09-23 12:53   ` Andy Shevchenko
2024-09-23 13:24     ` Roger Quadros
2024-09-23 13:44       ` Andy Shevchenko [this message]

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=ZvFwppgtysrFR6Dx@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pawell@cadence.com \
    --cc=peter.chen@kernel.org \
    --cc=rogerq@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