linux-kernel - RE: [PATCH v1 2/2] dmaengine: dw-edma: Add non-LL mode

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:
 <SA1PR12MB812055A34EC34AAA83306C989515A@SA1PR12MB8120.namprd12.prod.outlook.com>
Date: Mon, 15 Sep 2025 10:54:36 +0000
From: "Verma, Devendra" <Devendra.Verma@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
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 v1 2/2] dmaengine: dw-edma: Add non-LL mode

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Bjorn

Please check my response inline.
Regards,
Devendra

> -----Original Message-----
> From: Bjorn Helgaas <helgaas@...nel.org>
> Sent: Friday, September 12, 2025 21:04
> To: Verma, Devendra <Devendra.Verma@....com>
> Cc: bhelgaas@...gle.com; mani@...nel.org; vkoul@...nel.org;
> dmaengine@...r.kernel.org; linux-pci@...r.kernel.org; linux-
> kernel@...r.kernel.org; Simek, Michal <michal.simek@....com>
> Subject: Re: [PATCH v1 2/2] dmaengine: dw-edma: Add non-LL mode
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Sep 12, 2025 at 09:35:56AM +0000, Verma, Devendra wrote:
> > > -----Original Message-----
> > > From: Bjorn Helgaas <helgaas@...nel.org>
>
> [redundant headers removed]
>
> > > On Thu, Sep 11, 2025 at 05:14:51PM +0530, Devendra K Verma wrote:
> > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > The current code does not have the mechanisms to enable the DMA
> > > > transactions using the non-LL mode. The following two cases are
> > > > added with this patch:
> > > > - When a valid physical base address is not configured via the
> > > >   Xilinx VSEC capability then the IP can still be used in non-LL
> > > >   mode. The default mode for all the DMA transactions and for all
> > > >   the DMA channels then is non-LL mode.
> > > > - When a valid physical base address is configured but the client
> > > >   wants to use the non-LL mode for DMA transactions then also the
> > > >   flexibility is provided via the peripheral_config struct member of
> > > >   dma_slave_config. In this case the channels can be individually
> > > >   configured in non-LL mode. This use case is desirable for single
> > > >   DMA transfer of a chunk, this saves the effort of preparing the
> > > >   Link List.
> > >
> > > > +static pci_bus_addr_t dw_edma_get_phys_addr(struct pci_dev *pdev,
> > > > +                                         struct dw_edma_pcie_data *pdata,
> > > > +                                         enum pci_barno bar) {
> > > > +     if (pdev->vendor == PCI_VENDOR_ID_XILINX)
> > > > +             return pdata->devmem_phys_off;
> > > > +     return pci_bus_address(pdev, bar);
> > >
> > > Does this imply that non-Xilinx devices don't have the iATU that
> > > translates a PCI bus address to an internal device address?
> >
> > Non-Xilinx devices can have iATU enabled or bypassed as well. In
> > bypass mode no translation is done and the TLPs are simply forwarded
> > untranslated.
>
> What happens on a non-Xilinx device with iATU enabled?  Does
> pci_bus_address() return the correct address in that case?
>
> I can't figure out what's different about Xilinx that requires this special handling.

I am not sure how non-Xilinx device operates, but as mentioned earlier, there is an
option where translation may not be required.AMD (Xilinx) design enables the iATU
that is the reason the device side DDR offset is retrieved and programmed.