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 15:53:19 +0300	[thread overview]
Message-ID: <ZvFkv-xrs1ul7-oI@smile.fi.intel.com> (raw)
In-Reply-To: <d6ec3b8b-9405-49fa-ba39-a0bf6311a489@kernel.org>

On Mon, Sep 23, 2024 at 03:42:20PM +0300, Roger Quadros wrote:
> On 13/09/2024 16:17, Andy Shevchenko wrote:
> > The PCI vendor ID for Cadence is defined in pci_ids.h. Use it.
> > While at it, move to PCI_DEVICE() macro and usual pattern for
> > PCI class and device IDs.

...

> > +#define PCI_DEVICE_ID_CDNS_USB3	0x0100
> 
> Why do we need to change this? You did not explain in commit log.

It's explained: "...usual pattern for PCI class and device IDs."

> I would call this PCI_DEVICE_ID_CDNS_USBSS3. Also see later why to differentiate with USBSSP.

It's good to know that there are semantic differences,
but it is already applied, feel free to update.

...

> > -	{ PCI_DEVICE(CDNS_VENDOR_ID, CDNS_DEVICE_ID), },
> > +	{ PCI_VDEVICE(CDNS, PCI_DEVICE_ID_CDNS_USB3) },
> 
> For better readability I still prefer
> 	PCI_DEVICE(PCI_VENDOR_ID_CDNS, PCI_DEVICE_ID_CDNS_USBSS3)

I disagree. The PCI_VDEVICE() has less letters and much easier to get
the vendor from the (less power to parse and decode is required).

...

> > -#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 would call this PCI_DEVICE_ID_CDNS_USBSSP	0x200	to match with PCI driver name.
> 
> > +#define PCI_DEVICE_ID_CDNS_UDC		0x0200
> 
> UDC is used for Peripheral controller only. Is that really the case here?
> originally it was called DRD. 
> So how about?
> 	PCI_DEVICE_ID_CDNS_DRD		0x0100

I strongly disagree. The same PCI IDs should be named the same independently on
how many drivers use them.

The only possibility to have what you propose is the complete screwed up PCI
IDs allocations done by vendor (I do not believe this is the case with Cadence).

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-09-23 12:53 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 [this message]
2024-09-23 13:24     ` Roger Quadros
2024-09-23 13:44       ` Andy Shevchenko

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=ZvFkv-xrs1ul7-oI@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