linux-kernel - Re: [PATCH 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250910164912.GA1540975@bhelgaas>
Date: Wed, 10 Sep 2025 11:49:12 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: "Verma, Devendra" <Devendra.Verma@....com>
Cc: "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"mani@...nel.org" <mani@...nel.org>,
	"vkoul@...nel.org" <vkoul@...nel.org>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Simek, Michal" <michal.simek@....com>
Subject: Re: [PATCH 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support

On Wed, Sep 10, 2025 at 12:28:40PM +0000, Verma, Devendra wrote:
> > From: Bjorn Helgaas <helgaas@...nel.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