linux-kernel - Re: [PATCH v4 3/3] selftests: pci_endpoint: Migrate to Kselftest framework

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] [day] [month] [year] [list]

Message-ID: <Z3ahUuSjRv66L_g9@ryzen>
Date: Thu, 2 Jan 2025 15:23:14 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Vinod Koul <vkoul@...nel.org>
Cc: kw@...ux.com, gregkh@...uxfoundation.org, arnd@...db.de,
	lpieralisi@...nel.org, shuah@...nel.org, kishon@...nel.org,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	bhelgaas@...gle.com, linux-arm-msm@...r.kernel.org, robh@...nel.org,
	linux-kselftest@...r.kernel.org,
	Aman Gupta <aman1.gupta@...sung.com>,
	Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>
Subject: Re: [PATCH v4 3/3] selftests: pci_endpoint: Migrate to Kselftest
 framework

Hello Mani, Vinod,

On Thu, Jan 02, 2025 at 12:34:04PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Dec 31, 2024 at 08:33:57PM +0100, Niklas Cassel wrote:
> > 
> > I have some patches that adds DMA_MEMCPY to dw-edma, but I'm not sure if the DWC eDMA hardware supports having both src and dst as PCI addresses, or if only one of them can be a PCI address (with the other one being a local address).
> > 
> > If only one of them can be a PCI address, then I'm not sure if your suggested patch is correct.
> > 
> 
> I don't see why that would be an issue. DMA_MEMCPY is independent of PCI/local
> addresses. If a dmaengine driver support doing MEMCPY, then the dma cap should
> be sufficient. As you said, if a controller supports both SLAVE and MEMCPY, the
> test currently errors out, which is wrong.

While I am okay with your suggested change to pci-epf-test.c:
> >-               if (epf_test->dma_private) {
> >+               if (!dma_has_cap(DMA_MEMCPY, epf_test->dma_chan_tx->device->cap_mask)) {

Since this will ensure that a DMA driver implementing DMA_MEMCPY,
which cannot be shared (has DMA_PRIVATE set), will not error out.

What I'm trying to explain is that in:
https://lore.kernel.org/linux-pci/Z2BW4CjdE1p50AhC@vaman/
https://lore.kernel.org/linux-pci/20241217090129.6dodrgi4tn7l3cod@thinkpad/

Vinod (any you) suggested that we should add support for prep_memcpy()
(which implies also setting cap DMA_MEMCPY) in the dw-edma DMA driver.

However, from section "6.3 Using the DMA" in the DWC databook,
the DWC eDMA hardware only supports:
- Transfer (copy) of a block of data from local memory to remote memory.
- Transfer (copy) of a block of data from remote memory to local memory.

Currently, we have:
https://github.com/torvalds/linux/blob/v6.13-rc5/include/linux/dmaengine.h#L843-L844
https://github.com/torvalds/linux/blob/v6.13-rc5/drivers/dma/dw-edma/dw-edma-core.c#L215-L231

Where we can expose per-channel capabilities, so we set MEM_TO_DEV/DEV_TO_MEM
per channel, however, these are returned in a struct dma_slave_caps *caps,
so this is AFAICT only for DMA_SLAVE, not for DMA_MEMCPY.

Looking at:
https://github.com/torvalds/linux/blob/v6.13-rc5/include/linux/dmaengine.h#L975-L979
it seems that DMA_MEMCPY is always assumed to be MEM_TO_MEM.

To me, it seems that we would either need a new dma_transaction_type (e.g. DMA_COPY)
where we can set dir:
MEM_TO_DEV, DEV_TO_MEM, or DEV_TO_DEV. (dw-edma would not support DEV_TO_DEV.)

Or, if we should stick with DMA_MEMCPY, we would need another way of telling
client drivers that only src or dst can be a remote address.

Until this is solved, I think I will stop my work on adding DMA_MEMCPY to the
dw-edma driver.

Kind regards,
Niklas