All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Devendra K Verma" <devverma@amd.com>
Cc: vkoul@kernel.org, linux-pci@vger.kernel.org, Frank.Li@kernel.org,
	dmaengine@vger.kernel.org
Subject: Re: [PATCH v3 1/2] dmaengine: dw-edma: Enable Chan Separation via VSEC
Date: Mon, 10 Aug 2026 10:36:06 +0000	[thread overview]
Message-ID: <20260810103607.5CAF61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260810101002.1726131-2-devverma@amd.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The parsed channel separation size (`ch_space_sz`) is never propagated to the core driver, rendering the commit functionally dead.
- [Medium] The newly added `ch_space_sz` field implicitly defaults to 0 instead of the documented 256 bytes for all non-B00F devices.
--

--- Patch [1]: [PATCH v3 1/2] dmaengine: dw-edma: Enable Chan Separation via VSEC ---
commit 49b6417fbdbe084d5839664db3abac6f79f818d2
Author: Devendra K Verma <devverma@amd.com>

dmaengine: dw-edma: Enable Chan Separation via VSEC

This commit adds support for parsing the channel separation size from the
DEVICE INFORMATION VSEC capability on the Xilinx B00F device. It aims to
allow the user to configure the separation between DMA channel registers.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 791c46e8ae4c4..5d7507a640565 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c

[ ... ]

> @@ -73,6 +75,7 @@ struct dw_edma_pcie_data {
>  	u16				wr_ch_cnt;
>  	u16				rd_ch_cnt;
>  	u64				devmem_phys_off;
> +	u32				ch_space_sz;
>  };

[Severity: Medium]
Does this new field implicitly default to 0 for non-B00F devices?

The commit message states "Default supported size is 256B", but static
structs like snps_edda_data and xilinx_mdb_data lack explicit
initialization for ch_space_sz, meaning they will be zero-initialized.

If this value is later used for channel offset calculations, could a 0-byte
separation cause all DMA channels to map to the exact same memory address?

[ ... ]

> @@ -279,6 +289,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	pdata->mf = map;
>  	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_BAR, val);
>  
> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> +		pdata->ch_space_sz = dw_edma_get_ch_space_sz
> +					(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP, val));
> +

[Severity: Medium]
Is this parsed value supposed to be propagated to the core driver?

It appears pdata->ch_space_sz is populated here, but looking at
dw_edma_pcie_probe(), it doesn't seem to be passed along to
struct dw_edma_chip before the VSEC data goes out of scope:

drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
	...
	chip->mf = vsec_data->mf;
	chip->nr_irqs = nr_irqs;
	chip->ops = &dw_edma_pcie_plat_ops;
	chip->cfg_non_ll = non_ll;
	/* missing chip->ch_space_sz = vsec_data->ch_space_sz ? */
	...
}

Without this propagation, does the channel separation configuration
actually take effect?

>  	pci_read_config_dword(pdev, vsec + 0xc, &val);
>  	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>  			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810101002.1726131-1-devverma@amd.com?part=1

  reply	other threads:[~2026-08-10 10:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 10:10 [PATCH v3 0/2] CPM6 Channel Separation Support Devendra K Verma
2026-08-10 10:10 ` [PATCH v3 1/2] dmaengine: dw-edma: Enable Chan Separation via VSEC Devendra K Verma
2026-08-10 10:36   ` sashiko-bot [this message]
2026-08-10 17:14   ` Frank Li
2026-08-10 10:10 ` [PATCH v3 2/2] dmaengine: dw-edma: Add changes to support Channel Separation Devendra K Verma
2026-08-10 10:40   ` sashiko-bot
2026-08-10 17:18   ` Frank Li

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=20260810103607.5CAF61F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=devverma@amd.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-pci@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.