[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66279e39a81cd4837b11e516a053ebb337e3756e.camel@linux.intel.com>
Date: Sun, 21 Nov 2021 07:48:43 -0800
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: lee.jones@...aro.org, hdegoede@...hat.com, bhelgaas@...gle.com,
andriy.shevchenko@...ux.intel.com, srinivas.pandruvada@...el.com,
mgross@...ux.intel.com, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/4] PCI: Add #defines for accessing PCIe DVSEC fields
On Sun, 2021-11-21 at 13:24 +0100, Greg KH wrote:
> On Sat, Nov 20, 2021 at 03:17:02PM -0800, David E. Box wrote:
> > Add #defines for accessing Vendor ID, Revision, Length, and ID offsets
> > in the Designated Vendor Specific Extended Capability (DVSEC). Defined
> > in PCIe r5.0, sec 7.9.6.
> >
> > Signed-off-by: David E. Box <david.e.box@...ux.intel.com>
> > Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
> > Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> > include/uapi/linux/pci_regs.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > index ff6ccbc6efe9..318f3f1f9e92 100644
> > --- a/include/uapi/linux/pci_regs.h
> > +++ b/include/uapi/linux/pci_regs.h
> > @@ -1086,7 +1086,11 @@
> >
> > /* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
> > #define PCI_DVSEC_HEADER1 0x4 /* Designated Vendor-Specific
> > Header1 */
> > +#define PCI_DVSEC_HEADER1_VID(x) ((x) & 0xffff)
> > +#define PCI_DVSEC_HEADER1_REV(x) (((x) >> 16) & 0xf)
> > +#define PCI_DVSEC_HEADER1_LEN(x) (((x) >> 20) & 0xfff)
> > #define PCI_DVSEC_HEADER2 0x8 /* Designated Vendor-Specific
> > Header2 */
> > +#define PCI_DVSEC_HEADER2_ID(x) ((x) & 0xffff)
>
> Why does userspace need to have these defines? What userspace tool is
> going to use these?
These headers should useful for userspace tools that access PCI devices. DVSEC
is also used by CXL so they should come in handy for tools accesses those
devices.
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists