Re: [PATCH v8 02/19] dmaengine: ti: k3-udma: move macros to header file

[email protected]
Newsgroups org.kernel.vger.dmaengine,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Failure to handle all MSI controller DT binding variants by directly calling `of_msi_get_domain`.
--

--- Patch [2]: [PATCH v8 02/19] dmaengine: ti: k3-udma: move macros to header file ---
commit 602a5738457ed780a012151dd52a59d2064763e4
Author: Sai Sree Kartheek Adivi <[email protected]>

dmaengine: ti: k3-udma: move macros to header file
    
Move macros defined in k3-udma.c to k3-udma.h for better separation and
reuse.

> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 48f4db777d924..a066862e2c699 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c

[ ... ]

> @@ -5398,12 +5342,6 @@ static enum dmaengine_alignment udma_get_copy_align(struct udma_dev *ud)
>  	}
>  }
>  
> -#define TI_UDMAC_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> -				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> -				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
> -				 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
> -				 BIT(DMA_SLAVE_BUSWIDTH_8_BYTES))
> -
>  static int udma_probe(struct platform_device *pdev)
>  {
>  	struct device_node *navss_node = pdev->dev.parent->of_node;

[ ... ]

	dev->msi.domain = of_msi_get_domain(dev, dev->of_node,
					    DOMAIN_BUS_TI_SCI_INTA_MSI);

[Severity: High]
This is a pre-existing issue, but does this explicitly fail to support
msi-map bindings?

By calling of_msi_get_domain() during device probe, the driver resolves
the MSI domain solely by iterating msi-parent phandles.

Will this cause MSI allocation failures and return -EPROBE_DEFER on platforms
that rely on msi-map bindings?

	if (!dev->msi.domain) {
		return -EPROBE_DEFER;
	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.