From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: Frank.Li@kernel.org, dmaengine@vger.kernel.org, vkoul@kernel.org
Subject: Re: [PATCH v5 14/14] dmaengine: dw-edma: Program endpoint function numbers
Date: Fri, 17 Jul 2026 05:29:49 +0000 [thread overview]
Message-ID: <20260717052949.949521F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260717050308.2144108-15-den@valinux.co.jp>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `PCI_FUNC(pdev->devfn)` incorrectly truncates the 8-bit PCI `devfn` to 3 bits, leading to corrupted Requester IDs in outgoing DMA TLPs for Alternative Routing-ID Interpretation (ARI) devices and non-zero device number RCiEPs.
--
--- Patch [14]: [PATCH v5 14/14] dmaengine: dw-edma: Program endpoint function numbers ---
commit 69615a1713850d90b9bf46ff89bf560c8d19478f
Author: Koichiro Den <den@valinux.co.jp>
dmaengine: dw-edma: Program endpoint function numbers
This commit programs the requester function number for eDMA/HDMA transfers
so that the host can attribute and translate them correctly. It records the
function number using PCI_FUNC() during probe and programs it per channel.
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 7f96e65ee2746..07ea237577d5e 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -473,6 +473,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>
> chip->mf = dma_data->mf;
> chip->flags = match->chip_flags;
> + chip->func_no = PCI_FUNC(pdev->devfn);
[Severity: High]
Does PCI_FUNC(pdev->devfn) incorrectly truncate the 8-bit PCI devfn to 3 bits
for Alternative Routing-ID Interpretation (ARI) devices and non-zero device
number RCiEPs?
Because the PCI_FUNC() macro masks the value with 0x07, it discards the upper
5 bits. This might cause DMA transfers from an endpoint function with an ARI
function number >= 8 to carry an aliased Requester ID.
> chip->nr_irqs = nr_irqs;
> chip->ops = match->plat_ops;
[ ... ]
> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> index 77260c076cd3a..fdb2c6fb08e41 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> @@ -334,6 +334,9 @@ static void dw_hdma_v0_core_ch_config(struct dw_edma_chan *chan)
> SET_CH_32(dw, chan->dir, chan->id, msi_abort.msb, chan->msi.address_hi);
> /* config MSI data */
> SET_CH_32(dw, chan->dir, chan->id, msi_msgdata, chan->msi.data);
> + /* Configure the requester function number used by outbound TLPs. */
> + SET_CH_32(dw, chan->dir, chan->id, func_num,
> + FIELD_PREP(HDMA_V0_FUNC_NUM_PF_MASK, chan->func_no));
[Severity: High]
Since HDMA_V0_FUNC_NUM_PF_MASK is defined as GENMASK(7, 0) and is intended to
hold the full Routing ID, will this field end up receiving the truncated
3-bit value set during probe? If so, could this lead to IOMMU faults by
blocking TLPs with mismatched Requester IDs?
> }
>
> static void
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717050308.2144108-1-den@valinux.co.jp?part=14
prev parent reply other threads:[~2026-07-17 5:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 5:02 [PATCH v5 00/14] dmaengine: dw-edma: Prepare for PCI EP DMA (part 1/3) Koichiro Den
2026-07-17 5:02 ` [PATCH v5 01/14] dmaengine: dw-edma: Factor out HDMA interrupt setup helper Koichiro Den
2026-07-17 5:02 ` [PATCH v5 02/14] dmaengine: dw-edma: Add per-channel interrupt routing control Koichiro Den
2026-07-17 5:21 ` sashiko-bot
2026-07-17 5:02 ` [PATCH v5 03/14] dmaengine: dw-edma: Add core quiesce operations Koichiro Den
2026-07-17 5:17 ` sashiko-bot
2026-07-17 5:02 ` [PATCH v5 04/14] dmaengine: dw-edma: Initialize IRQ data before requesting IRQs Koichiro Den
2026-07-17 5:16 ` sashiko-bot
2026-07-17 5:02 ` [PATCH v5 05/14] dmaengine: dw-edma: Add partial channel ownership mode Koichiro Den
2026-07-17 5:20 ` sashiko-bot
2026-07-17 5:03 ` [PATCH v5 06/14] dmaengine: dw-edma-pcie: Track non-LL mode in DMA data Koichiro Den
2026-07-17 5:03 ` [PATCH v5 07/14] dmaengine: dw-edma-pcie: Add capability match data Koichiro Den
2026-07-17 5:12 ` sashiko-bot
2026-07-17 5:03 ` [PATCH v5 08/14] dmaengine: dw-edma-pcie: Rename vsec_data to dma_data Koichiro Den
2026-07-17 5:03 ` [PATCH v5 09/14] dmaengine: dw-edma-pcie: Add platform ops to match data Koichiro Den
2026-07-17 5:03 ` [PATCH v5 10/14] dmaengine: dw-edma-pcie: Add register offset match flag Koichiro Den
2026-07-17 5:03 ` [PATCH v5 11/14] dmaengine: dw-edma-pcie: Factor out descriptor block address lookup Koichiro Den
2026-07-17 5:03 ` [PATCH v5 12/14] dmaengine: dw-edma-pcie: Handle optional data blocks Koichiro Den
2026-07-17 5:18 ` sashiko-bot
2026-07-17 5:03 ` [PATCH v5 13/14] dmaengine: dw-edma-pcie: Add chip flags to match data Koichiro Den
2026-07-17 5:03 ` [PATCH v5 14/14] dmaengine: dw-edma: Program endpoint function numbers Koichiro Den
2026-07-17 5:29 ` sashiko-bot [this message]
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=20260717052949.949521F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=den@valinux.co.jp \
--cc=dmaengine@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox