All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben.widawsky@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vinod Koul <vkoul@kernel.org>,
	dmaengine@vger.kernel.org
Subject: Re: [PATCH 04/15] PCI: Add pci_find_vsec_capability() to find a specific VSEC
Date: Mon, 1 Feb 2021 15:29:24 -0800	[thread overview]
Message-ID: <20210201232924.kklgi7u37iyrm2lq@intel.com> (raw)
In-Reply-To: <CAPcyv4ia_0Sn8paGi7y7JGNXQrbCoFhT7st2VOD=L_LKNEMOEg@mail.gmail.com>

On 21-02-01 15:24:45, Dan Williams wrote:
> [ add Ben ]
> 
> On Mon, Feb 1, 2021 at 2:39 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > [+cc Vinod, Dan, dmaengine]
> >
> > On Tue, Dec 15, 2020 at 06:30:13PM +0100, Gustavo Pimentel wrote:
> > > Add pci_find_vsec_capability() that crawls through the device config
> > > space searching in all Vendor-Specific Extended Capabilities for a
> > > particular capability ID.
> > >
> > > Vendor-Specific Extended Capability (VSEC) is a PCIe capability (acts
> > > like a wrapper) specified by PCI-SIG that allows the vendor to create
> > > their own and specific capability in the device config space.
> > >
> > > Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> >
> > If you fix the below, feel free to add my
> >
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >
> > Otherwise, I can take it myself.  But that will be an ordering issue
> > in the merge window if you merge the rest of the series via another
> > tree.
> 
> I wonder if this warrants and if you'd be willing to stand up a stable
> branch for just this commit for concerned parties to integrate,
> because CXL development should adopt it as well.
> 

Yeah, can we add DVSEC too please?

> >
> > > ---
> > >  drivers/pci/pci.c             | 29 +++++++++++++++++++++++++++++
> > >  include/linux/pci.h           |  1 +
> > >  include/uapi/linux/pci_regs.h |  5 +++++
> > >  3 files changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 6d4d5a2..235d0b2 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -623,6 +623,35 @@ u64 pci_get_dsn(struct pci_dev *dev)
> > >  }
> > >  EXPORT_SYMBOL_GPL(pci_get_dsn);
> > >
> > > +/**
> > > + * pci_find_vsec_capability - Find a vendor-specific extended capability
> > > + * @dev: PCI device to query
> > > + * @cap: vendor-specific capability id code
> >
> > s/id/ID/
> >
> > > + *
> > > + * Returns the address of the vendor-specific structure that matches the
> > > + * requested capability id code within the device's PCI configuration space
> >
> > s/id/ID/
> >
> > > + * or 0 if it does not find a match.
> > > + */
> > > +int pci_find_vsec_capability(struct pci_dev *dev, int vsec_cap_id)
> > > +{
> > > +     u32 header;
> > > +     int vsec;
> >
> >   int vsec;
> >   u32 header;
> >
> > since that's the order they're used.
> >
> > > +
> > > +     vsec = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_VNDR);
> > > +     while (vsec) {
> > > +             if (pci_read_config_dword(dev, vsec + 0x4,
> >
> > s/0x4/PCI_VSEC_HDR/
> >
> > > +                                       &header) == PCIBIOS_SUCCESSFUL &&
> > > +                 PCI_VSEC_CAP_ID(header) == vsec_cap_id)
> > > +                     break;
> >
> >   return vsec;
> >
> > > +
> > > +             vsec = pci_find_next_ext_capability(dev, vsec,
> > > +                                                 PCI_EXT_CAP_ID_VNDR);
> > > +     }
> > > +
> > > +     return vsec;
> >
> >   return 0;
> >
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_find_vsec_capability);
> > > +
> > >  static int __pci_find_next_ht_cap(struct pci_dev *dev, int pos, int ht_cap)
> > >  {
> > >       int rc, ttl = PCI_FIND_CAP_TTL;
> > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > index 22207a7..effecb0 100644
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -1067,6 +1067,7 @@ int pci_find_capability(struct pci_dev *dev, int cap);
> > >  int pci_find_next_capability(struct pci_dev *dev, u8 pos, int cap);
> > >  int pci_find_ext_capability(struct pci_dev *dev, int cap);
> > >  int pci_find_next_ext_capability(struct pci_dev *dev, int pos, int cap);
> > > +int pci_find_vsec_capability(struct pci_dev *dev, int vsec_cap_id);
> > >  int pci_find_ht_capability(struct pci_dev *dev, int ht_cap);
> > >  int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap);
> > >  struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
> > > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > > index a95d55f..f5d17be 100644
> > > --- a/include/uapi/linux/pci_regs.h
> > > +++ b/include/uapi/linux/pci_regs.h
> > > @@ -730,6 +730,11 @@
> > >  #define PCI_EXT_CAP_DSN_SIZEOF       12
> > >  #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
> > >
> > > +/* Vendor-Specific Extended Capabilities */
> > > +#define PCI_VSEC_CAP_ID(header)              (header & 0x0000ffff)
> > > +#define PCI_VSEC_CAP_REV(header)     ((header >> 16) & 0xf)
> > > +#define PCI_VSEC_CAP_LEN(header)     ((header >> 20) & 0xffc)
> >
> > Please put these next to the existing PCI_VSEC_HDR.
> >
> > Why does PCI_VSEC_CAP_LEN mask with 0xffc instead of 0xfff?  I don't
> > see anything in the spec about VSEC Length having to be a multiple of
> > 4 (PCIe r5.0, sec 7.9.5.2).
> >
> > But you don't use this anyway, so I'd just drop it (and
> > PCI_VSEC_CAP_REV) altogether.
> >
> > >  /* Advanced Error Reporting */
> > >  #define PCI_ERR_UNCOR_STATUS 4       /* Uncorrectable Error Status */
> > >  #define  PCI_ERR_UNC_UND     0x00000001      /* Undefined */
> > > --
> > > 2.7.4
> > >

  reply	other threads:[~2021-02-01 23:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 17:30 [PATCH 00/15] dmaengine: dw-edma: HDMA support Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 01/15] dmaengine: dw-edma: Add writeq() and readq() for 64 bits architectures Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 02/15] dmaengine: dw-edma: Fix comments offset characters' alignment Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 03/15] dmaengine: dw-edma: Add support for the HDMA feature Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 04/15] PCI: Add pci_find_vsec_capability() to find a specific VSEC Gustavo Pimentel
2021-02-01 22:39   ` Bjorn Helgaas
2021-02-01 23:24     ` Dan Williams
2021-02-01 23:29       ` Ben Widawsky [this message]
2021-02-02 12:25     ` Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 05/15] dmaengine: dw-edma: Add PCIe VSEC data retrieval support Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 06/15] dmaengine: dw-edma: Add device_prep_interleave_dma() support Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 07/15] dmaengine: dw-edma: Improve number of channels check Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 08/15] dmaengine: dw-edma: Reorder variables to keep consistency Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 09/15] dmaengine: dw-edma: Improve the linked list and data blocks definition Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 10/15] dmaengine: dw-edma: Change linked list and data blocks offset and sizes Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 11/15] dmaengine: dw-edma: Move struct dentry variable from static definition into dw_edma struct Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 12/15] dmaengine: dw-edma: Fix crash on loading/unloading driver Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 13/15] dmaengine: dw-edma: Change DMA abreviation from lower into upper case Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 14/15] dmaengine: dw-edma: Revert fix scatter-gather address calculation Gustavo Pimentel
2020-12-15 17:30 ` [PATCH 15/15] dmaengine: dw-edma: Add pcim_iomap_table return checker Gustavo Pimentel
2021-02-01  7:16 ` [PATCH 00/15] dmaengine: dw-edma: HDMA support Vinod Koul

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=20210201232924.kklgi7u37iyrm2lq@intel.com \
    --to=ben.widawsky@intel.com \
    --cc=Gustavo.Pimentel@synopsys.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=vkoul@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.