All of lore.kernel.org
 help / color / mirror / Atom feed
From: nuno.sa@analog.com
To: sashiko-reviews@lists.linux.dev
Cc: Frank.Li@kernel.org, dmaengine@vger.kernel.org, vkoul@kernel.org
Subject: Re: [PATCH v3 2/9] dmaengine: dma-axi-dmac: Use bus width capability helpers
Date: Mon, 31 Aug 2026 13:27:35 +0100	[thread overview]
Message-ID: <apVzBTBI2CP9eiBi@nsa> (raw)
In-Reply-To: <20260831120112.07E861F000E9@smtp.kernel.org>

On Mon, Aug 31, 2026 at 12:01:11PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The legacy `src_addr_widths` and `dst_addr_widths` fields in `struct dma_device` are left uninitialized (0), breaking bisection for unconverted dmaengine consumers and directly contradicting the commit message.
> --
> 
> commit e0d3ea2099710250e81c32b95cc62ac180daeb2f
> Author: Nuno Sá <nuno.sa@analog.com>
> 
> dmaengine: dma-axi-dmac: Use bus width capability helpers
> 
> Advertise the source and destination bus widths through the new
> dma_set_{src,dst}_bus_width() helpers instead of open-coding the legacy
> BIT() mask.
> 
> > diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> > index d47ff27e1408f..dc56178cafe08 100644
> > --- a/drivers/dma/dma-axi-dmac.c
> > +++ b/drivers/dma/dma-axi-dmac.c
> [ ... ]
> > @@ -1262,8 +1263,13 @@ static int axi_dmac_probe(struct platform_device *pdev)
> >  	dma_dev->device_terminate_all = axi_dmac_terminate_all;
> >  	dma_dev->device_synchronize = axi_dmac_synchronize;
> >  	dma_dev->dev = &pdev->dev;
> > -	dma_dev->src_addr_widths = BIT(dmac->chan.src_width);
> > -	dma_dev->dst_addr_widths = BIT(dmac->chan.dest_width);
> > +	ret = dma_bus_width_set(dma_dev->src_bus_widths, dmac->chan.src_width);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = dma_bus_width_set(dma_dev->dst_bus_widths, dmac->chan.dest_width);
> > +	if (ret)
> > +		return ret;
> 
> [Severity: Medium]
> Will this break bisection for unconverted dmaengine consumers by leaving the
> legacy src_addr_widths and dst_addr_widths uninitialized?
> 
> The commit message states the intent is "keeping the legacy u32 fields
> populated during the transition."
> 
> However, this patch removes the assignments to dma_dev->src_addr_widths and
> dma_dev->dst_addr_widths and replaces them with dma_bus_width_set(), which only
> populates the new bitmap masks.
> 
> The DMA engine core's fallback logic in dma_get_slave_caps() (which folds the
> new bitmaps into the legacy caps fields) is placed inside an if
> (device->device_caps) block. Because axi-dmac does not implement a
> device_caps() callback, this fallback is never executed.
> 

Oh yeah! sashiko seems to have a point!!

> Consequently, will unconverted legacy consumers (like IIO) querying channel
> capabilities during bisection receive caps->src_addr_widths == 0, causing DMA
> transfer configurations to fail?
> 
> While this regression is fixed later in the patch series (when legacy fields
> are dropped and consumers are fully converted), it seems to cause a bisection
> breakage in the intermediate patches.
> 
> Could the legacy assignments be retained alongside the new helper calls to
> match the commit message's stated intent?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260831-dmaengine-support-wider-dma-masks-v3-0-507d97496f2d@analog.com?part=2

  reply	other threads:[~2026-08-31 12:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 11:46 [PATCH v3 0/9] dmaengine: Support bus widths of 32 bytes and above Nuno Sá
2026-08-31 11:46 ` [PATCH v3 1/9] " Nuno Sá
2026-08-31 13:45   ` Andy Shevchenko
2026-08-31 15:56     ` Nuno Sá
2026-09-01  7:18       ` Andy Shevchenko
2026-09-11 15:14       ` Nuno Sá
2026-09-11 16:06         ` Andy Shevchenko
2026-09-11 16:59           ` Nuno Sá
2026-08-31 11:46 ` [PATCH v3 2/9] dmaengine: dma-axi-dmac: Use bus width capability helpers Nuno Sá
2026-08-31 12:01   ` sashiko-bot
2026-08-31 12:27     ` nuno.sa [this message]
2026-08-31 11:46 ` [PATCH v3 3/9] dmaengine: dw-axi-dmac: " Nuno Sá
2026-08-31 11:58   ` sashiko-bot
2026-08-31 12:41     ` nuno.sa
2026-08-31 11:46 ` [PATCH v3 4/9] dmaengine: qcom: gpi: " Nuno Sá
2026-08-31 11:59   ` sashiko-bot
2026-08-31 11:46 ` [PATCH v3 5/9] dmaengine: stm32-dma3: " Nuno Sá
2026-08-31 14:01   ` Amelie Delaunay
2026-09-01  8:25     ` Nuno Sá
2026-08-31 11:46 ` [PATCH v3 6/9] iio: buffer-dmaengine: Use dma_slave_caps bus width accessors Nuno Sá
2026-08-31 11:46 ` [PATCH v3 7/9] ALSA: pcm_dmaengine: Use dma_slave_caps bus width helpers Nuno Sá
2026-08-31 11:46 ` [PATCH v3 8/9] spi: dw: " Nuno Sá
2026-08-31 12:08   ` sashiko-bot
2026-08-31 12:12   ` Mark Brown
2026-08-31 13:47   ` Andy Shevchenko
2026-08-31 11:46 ` [PATCH v3 9/9] dmaengine: Drop legacy bus width fields from dma_slave_caps Nuno Sá
2026-08-31 13:49   ` Andy Shevchenko
2026-08-31 13:50 ` [PATCH v3 0/9] dmaengine: Support bus widths of 32 bytes and above Andy Shevchenko
2026-08-31 15:51   ` Nuno Sá

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=apVzBTBI2CP9eiBi@nsa \
    --to=nuno.sa@analog.com \
    --cc=Frank.Li@kernel.org \
    --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 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.