Re: [PATCH v5 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] 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