Re: [PATCH v4 1/5] PCI: Add vendor ID for the PCI SIG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 10 Jun 2021 08:17:23 -0700
Dan Williams <dan.j.williams@xxxxxxxxx> wrote:

> On Mon, May 24, 2021 at 6:41 AM Jonathan Cameron
> <Jonathan.Cameron@xxxxxxxxxx> wrote:
> >
> > This ID is used in DOE headers to identify protocols that are defined
> > within the PCI Express Base Specification.
> >
> > Specified in Table 7-x2 of the Data Object Exchange ECN (approved 12 March
> > 2020) available from https://members.pcisig.com/wg/PCI-SIG/document/14143
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > ---
> >  include/linux/pci_ids.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 4c3fa5293d76..dcc8b4b14198 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -149,6 +149,7 @@
> >  #define PCI_CLASS_OTHERS               0xff
> >
> >  /* Vendors and devices.  Sort key: vendor first, device next. */
> > +#define PCI_VENDOR_ID_PCI_SIG          0x0001  
> 
> Should this not be:
> 
> PCI_DOE_VENDOR_ID_PCI_SIG?
> 
> ...because I don't think this value will ever show up at the typical
> config-offset 0 vendor-id, will it?

Good question.

Whilst I agree it is unlikely to turn up as a conventional vendor-id
(though I've not found any text ruling it out) it already turns up
in locations other than DOE.

Many of them aren't software visible, but potentially places
like SPDM are in which you would have a registry ID of 0x3 (PCI-SIG)
followed by the PCI vendor ID (this one).  Those are used in SPDM
vendor defined requests / responses.

That SPDM feature is then used in IDE establishment.
The IDE ECN (via pcisig.com) has the following:
"The VendorID field of the VENDOR_DEFINED_REQUEST/
 VENDOR_DEFINED_RESPONSE must contain the value 0001h, which is assigned to
 the PCI-SIG."

Which to my reading, isn't quite the same as saying it's a vendor ID,
but nearly so.

Now, I argued the *_DVSEC_* naming in the CXL one based on the spec saying
that was all it could be used for but I may well have been wrong longer
term.

I'm fine with renaming it to the PCI_DOE_* version then dropping the DOE
when it gets used for something else though if that works for people.

At least this time naming isn't made awkward by legalese.

Jonathan



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux