All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Verma, Devendra" <Devendra.Verma@amd.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
	"mani@kernel.org" <mani@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Simek, Michal" <michal.simek@amd.com>
Subject: Re: [PATCH 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support
Date: Wed, 10 Sep 2025 11:49:12 -0500	[thread overview]
Message-ID: <20250910164912.GA1540975@bhelgaas> (raw)
In-Reply-To: <SA1PR12MB8120B9D69376F56AD2540E15950EA@SA1PR12MB8120.namprd12.prod.outlook.com>

On Wed, Sep 10, 2025 at 12:28:40PM +0000, Verma, Devendra wrote:
> > From: Bjorn Helgaas <helgaas@kernel.org>

[redundant quoted headers removed]

> > On Fri, Sep 05, 2025 at 03:46:58PM +0530, Devendra K Verma wrote:
> > > AMD MDB PCIe endpoint support. For AMD specific support added the
> > > following
> > >   - AMD supported PCIe Device IDs and Vendor ID (Xilinx).
> > >   - AMD MDB specific driver data
> > >   - AMD MDB specific VSEC capability to retrieve the device DDR
> > >     base address.

> > > static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
> > >       u32 val, map;
> > >       u16 vsec;
> > >       u64 off;
> > > +     u16 vendor;
> > >
> > > -     vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_SYNOPSYS,
> > > -                                     DW_PCIE_VSEC_DMA_ID);
> > > +     vendor = pdev->vendor;
> > > +     if (vendor != PCI_VENDOR_ID_SYNOPSYS &&
> > > +         vendor != PCI_VENDOR_ID_XILINX)
> > > +             return;
> > > +
> > > +     vsec = pci_find_vsec_capability(pdev, vendor,
> > > + DW_PCIE_VSEC_DMA_ID);
> >
> > The vendor of a device assigns VSEC IDs and determines what each
> > ID means, so the semantics of a VSEC Capability are determined by
> > the tuple of (device Vendor ID, VSEC ID), where the Vendor ID is
> > the value at 0x00 in config space.
> 
> As AMD is a vendor for this device, it is determined as VSEC
> capability to support some of the functionality not supported by the
> other vendor Synopsys.

Based on your code, the vendor of this device (the value at 0x00 in
config space) is either PCI_VENDOR_ID_SYNOPSYS or
PCI_VENDOR_ID_XILINX.  Whoever controls those Vendor IDs also
controls the VSEC ID allocations for those Vendor IDs.

> > The DVSEC Capability is a more generic solution to this problem.
> > The VSEC ID namespace is determined by the Vendor ID of the
> > *device*.
> >
> > By contrast, the DVSEC ID namespace is determined by a Vendor ID
> > in the DVSEC Capability itself, not by the Vendor ID of the
> > device.
> >
> > So AMD could define a DVSEC ID, e.g., 6, and define the semantics
> > of that DVSEC.  Then devices from *any* vendor could include a
> > DVSEC Capability with (PCI_VENDOR_ID_AMD, 6), and generic code
> > could look for that DVSEC independent of what is at 0x00 in config
> > space.
> 
> As AMD itself becomes the vendor for this device, VSEC capability is
> chosen to support the functionality missing in the code.

For VSEC, it doesn't matter who *sells* the device or who supplies IP
contained in the device.  What matters is the Vendor ID at 0x00 in
config space.

Bjorn

  reply	other threads:[~2025-09-10 16:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05 10:16 [PATCH 0/2] Add AMD MDB Endpoint and non-LL mode Support Devendra K Verma
2025-09-05 10:16 ` [PATCH 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support Devendra K Verma
2025-09-05 16:54   ` Bjorn Helgaas
2025-09-10 12:28     ` Verma, Devendra
2025-09-10 16:49       ` Bjorn Helgaas [this message]
2025-09-05 10:16 ` [PATCH 2/2] dmaengine: dw-edma: Add non-LL mode Devendra K Verma
2025-09-05 19:06   ` Bjorn Helgaas
2025-09-10 12:30     ` Verma, Devendra
2025-09-10 17:56       ` Bjorn Helgaas
2025-09-11 11:42         ` Verma, Devendra
2025-09-11 20:43           ` Bjorn Helgaas
2025-09-12  9:31             ` Verma, Devendra

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=20250910164912.GA1540975@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Devendra.Verma@amd.com \
    --cc=bhelgaas@google.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=michal.simek@amd.com \
    --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.