Re: [PATCH v6 14/14] dmaengine: dw-edma: Program endpoint function numbers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Truncation of PCIe Requester ID using `PCI_FUNC()` breaks IOMMU isolation and DMA for ARI devices and SR-IOV Virtual Functions.
--

--- Patch [14]: [PATCH v6 14/14] dmaengine: dw-edma: Program endpoint function numbers ---
commit 12cd49191ea0c234c70a872c83095a085495199a
Author: Koichiro Den <den@valinux.co.jp>

dmaengine: dw-edma: Program endpoint function numbers

This patch configures the requester function number for eDMA/HDMA transfers
by recording it in the chip data and programming it per channel. It extracts
the function number using PCI_FUNC() during PCIe probe. Endpoint-local
instances keep it at 0, while host-side instances use the probing device's
function number.

[ ... ]
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 64f2a80072bce..9f237ba916dea 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() truncate the function number for Alternative Routing-ID
Interpretation (ARI) devices and SR-IOV Virtual Functions?

PCI_FUNC() masks the input to 3 bits, dropping the upper bits of the
function number. Since ARI or SR-IOV topologies can have function numbers
up to 255 (8 bits), could this cause the host IOMMU to attribute DMA traffic
from functions >= 8 to functions 0-7, breaking isolation?

>  	chip->nr_irqs = nr_irqs;
>  	chip->ops = match->plat_ops;
>  	chip->cfg_non_ll = dma_data->cfg_non_ll;
[ ... ]
> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> index 8d20bb028b528..36ee72efcd317 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> @@ -345,6 +345,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]
HDMA_V0_FUNC_NUM_PF_MASK is an 8-bit mask, which implies the hardware expects
the full 8-bit devfn. Because chan->func_no was assigned using PCI_FUNC()
earlier, does this result in programming a truncated 3-bit value into this
8-bit hardware field, causing the hardware to emit TLPs with an incorrect
Requester ID?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721062815.4117887-1-den@valinux.co.jp?part=14