| 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
| ||
|
Message-ID: <h3uhcd426u32lmn4ajjcrclabuptiy3d4lmtdbwhtu5ca2dv2s@co5piltmkhx6>
Date: Sun, 1 Feb 2026 11:32:23 +0900
From: Koichiro Den <den@...inux.co.jp>
To: vkoul@...nel.org, mani@...nel.org, Frank.Li@....com,
jingoohan1@...il.com, lpieralisi@...nel.org, kwilczynski@...nel.org, robh@...nel.org,
bhelgaas@...gle.com
Cc: dmaengine@...r.kernel.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/7] dmaengine: dw-edma, PCI: dwc: Enable remote use
of integrated DesignWare eDMA
On Tue, Jan 27, 2026 at 12:34:13PM +0900, Koichiro Den wrote:
> Hi,
>
> Per Frank Li's suggestion [1], this revision combines the previously posted
> PCI/dwc helper series and the dmaengine/dw-edma series into a single
> 7-patch set. This series therefore supersedes the two earlier postings:
>
> - [PATCH 0/5] dmaengine: dw-edma: Add helpers for remote eDMA use scenarios
> https://lore.kernel.org/dmaengine/20260126073652.3293564-1-den@valinux.co.jp/
> - [PATCH 0/2] PCI: dwc: Expose integrated DesignWare eDMA windows
> https://lore.kernel.org/linux-pci/20260126071550.3233631-1-den@valinux.co.jp/
>
> [1] https://lore.kernel.org/linux-pci/aXeoxxG+9cFML1sx@lizhi-Precision-Tower-5810/
>
> Some DesignWare PCIe endpoint platforms integrate a DesignWare eDMA
> instance alongside the PCIe controller. In remote eDMA use cases, the host
> needs access to the eDMA register block and the per-channel linked-list
> (LL) regions via PCIe BARs, while the endpoint may still boot with a
> standard EP configuration (and may also use dw-edma locally).
>
> This series provides the following building blocks:
>
> * dmaengine: Add an optional dma_slave_caps.hw_id so DMA providers can expose
> a provider-defined hardware channel identifier to clients, and report it
> from dw-edma. This allows users to correlate a DMA channel with
> hardware-specific resources such as per-channel LL regions.
>
> * dmaengine/dw-edma: Add features useful for remote-controlled EP eDMA usage:
> - per-channel interrupt routing control (configured via dmaengine_slave_config(),
> passing a small dw-edma-specific structure through
> dma_slave_config.peripheral_config / dma_slave_config.peripheral_size),
> - optional completion polling when local IRQ handling is disabled, and
> - notify-only channels for cases where the local side needs interrupt
> notification without cookie-based accounting (i.e. its peer
> prepares and submits the descriptors), useful when host-to-endpoint
> interrupt delivery is difficult or unavailable without it.
>
> * PCI: dwc: Add query-only helper APIs to expose resources of an integrated
> DesignWare eDMA instance:
> - the physical base/size of the eDMA register window, and
> - the per-channel LL region base/size, keyed by transfer direction and
> the hardware channel identifier (hw_id).
>
> The first real user will likely be the DesignWare backend in the NTB transport work:
>
> [RFC PATCH v4 25/38] NTB: hw: Add remote eDMA backend registry and DesignWare backend
> https://lore.kernel.org/linux-pci/20260118135440.1958279-26-den@valinux.co.jp/
>
> (Note: the implementation in this series has been updated since that
> RFC v4, so the RFC series will also need some adjustments. I have an
> updated RFC series locally and can post an RFC v5 if that would help
> review/testing.)
>
> Apply/merge notes:
> - Patches 1-5 apply cleanly on dmaengine.git next.
> - Patches 6-7 apply cleanly on pci.git controller/dwc.
>
> Changes in v2:
> - Combine the two previously posted series into a single set (per Frank's
> suggestion). Order dmaengine/dw-edma patches first so hw_id support
> lands before the PCI LL-region helper, which assumes
> dma_slave_caps.hw_id availability.
>
> Thanks for reviewing,
>
>
> Koichiro Den (7):
> dmaengine: Add hw_id to dma_slave_caps
> dmaengine: dw-edma: Report channel hw_id in dma_slave_caps
> dmaengine: dw-edma: Add per-channel interrupt routing control
> dmaengine: dw-edma: Poll completion when local IRQ handling is
> disabled
> dmaengine: dw-edma: Add notify-only channels support
> PCI: dwc: Add helper to query integrated dw-edma register window
> PCI: dwc: Add helper to query integrated dw-edma linked-list region
Hi Mani, Vinod (and others),
I'd appreciate your thoughts on the overall design of patches 3–5/7 when
you have a moment.
- [PATCH v2 3/7] dmaengine: dw-edma: Add per-channel interrupt routing control
https://lore.kernel.org/dmaengine/20260127033420.3460579-4-den@valinux.co.jp/
- [PATCH v2 4/7] dmaengine: dw-edma: Poll completion when local IRQ handling is disabled
https://lore.kernel.org/dmaengine/20260127033420.3460579-5-den@valinux.co.jp/
- [PATCH v2 5/7] dmaengine: dw-edma: Add notify-only channels support
https://lore.kernel.org/dmaengine/20260127033420.3460579-6-den@valinux.co.jp/
My cover letter might have been too terse, so let me add a bit more context
and two questions at the end.
(Frank already provided helpful feedback on v1/RFC for Patch 3/7. Thanks, Frank.)
Motivation for these three patches
----------------------------------
For remote use of a DMA channel (i.e. the host drives a channel that
resides in the endpoint (EP)):
* The EP initializes its DMA channels during the normal SoC glue
driver probe.
* It obtains a dma_chan to delegate to the host via the standard
dma_request_channel().
* It exposes the underlying HW resources to the host ("delegation").
* The host also acquires a channel via the standard
dma_request_channel(). The underlying HW resource is the same as on the
EP side, but it's driven remotely from the host.
and I'm targeting two operating modes:
1). Standard use of the remote channel
* The host submits a transaction and handles its completion, just
like a local dmaengine client would. Under the hood, the HW channel
resides in the remote EP.
* In this scenario, we need to ensure:
(a). completion interrupts are delivered only to the host. Or,
(b). even if (a) is not possible (i.e. the EP also gets interrupted),
the EP must not acknowledge/clear the interrupt status in a way
that would race with host.
dmaengine_submit()
:
v
+----------+ +----------+
| dma_chan |--(delegate)--->: dma_chan :
+----------+ +----------+
EP (delegator) Host (delegatee)
^
:
completion interrupt
2). Notify-only channel
* The host submits a transaction, and the EP gets the interrupt
and runs any registered callbacks.
* In this scenario, we need to ensure:
(a). completion interrupts are delivered only to the EP. Or,
(b). even if (a) is not possible (i.e. the host also gets
interrupted), the host must not acknowledge/clear the interrupt
status in a way that would race with the EP.
(c). repeated dmaengine_submit() calls must not get stuck, even
though it cannot rely on interrupt-driven transaction status
management.
(d). callback can be registered for the dma_chan on the EP.
dmaengine_submit()
:
v
+----------+ +----------+
| dma_chan |--(delegate)--->: dma_chan :
+----------+ +----------+
EP (delegator) Host (delegatee)
^
:
completion interrupt
Patch mapping:
- (a)(b) are addressed by [PATCH v2 3/7].
- (c) is addressed by [PATCH v2 4/7].
- (d) is addressed by [PATCH v2 5/7].
Questions
---------
1. Are these two use cases (1) and (2) acceptable?
2. To support (1) and (2), is the current implementation direction acceptable?
Or should this be generalized into a dmaengine API rather than being a
dw-edma-core-specific extension?
Any feedback would be appreciated.
Kind regards,
Koichiro
>
> MAINTAINERS | 2 +-
> drivers/dma/dmaengine.c | 1 +
> drivers/dma/dw-edma/dw-edma-core.c | 167 +++++++++++++++++--
> drivers/dma/dw-edma/dw-edma-core.h | 21 +++
> drivers/dma/dw-edma/dw-edma-v0-core.c | 26 ++-
> drivers/pci/controller/dwc/pcie-designware.c | 74 ++++++++
> drivers/pci/controller/dwc/pcie-designware.h | 2 +
> include/linux/dma/edma.h | 57 +++++++
> include/linux/dmaengine.h | 2 +
> include/linux/pcie-dwc-edma.h | 72 ++++++++
> 10 files changed, 398 insertions(+), 26 deletions(-)
> create mode 100644 include/linux/pcie-dwc-edma.h
>
> --
> 2.51.0
>
Powered by blists - more mailing lists