Re: [PATCH v6 20/23] dmaengine: ste_dma40: Fix event group bounds

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: ste_dma40: channel aliasing for event group 4 on V4B
--

commit 48ff5fdacb29b6847b9d51f8ce427281645c1c9b
Author: Linus Walleij <linusw@kernel.org>
dmaengine: ste_dma40: Fix event group bounds

This commit fixes event group bounds validation by properly restricting
device type values to the hardware event-group range and removing incorrect
physical channel limits. It also stops physical channel searches before they
can index past the allocated channel array.

Closes: https://lore.kernel.org/dmaengine/20260819225008.5F9651F000E9@smtp.kernel.org/

> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 8b13f1360edbe..d3d79e394d028 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
[ ... ]
> @@ -2068,8 +2078,12 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
>  				}
>  			}
>  		} else
> -			for (j = 0; j < d40c->base->num_phy_chans; j += 8) {
> +			for (j = 0; j < d40c->base->num_phy_chans;
> +			     j += D40_GROUP_SIZE) {
>  				int phy_num = j  + event_group * 2;
> +				if (phy_num + 1 >= num_phy_chans)
> +					break;
> +

[Severity: High]
Does this cause channel aliasing for event group 4 on V4B hardware?

Since D40_GROUP_SIZE is hardcoded to 8, if event_group is 4 (allowed for V4B)
and j is 0, phy_num evaluates to 8. But if event_group is 0 and j is 8,
phy_num also evaluates to 8.

Could this collision map two different groups to the same physical channel?

Additionally, since D40_PHYS_TO_GROUP is hardcoded as ((phys & 7) / 2),
channel 8 evaluates to group 0. Might this incorrectly configure the GCC clock
and hardware registers for group 0 instead of 4, breaking DMA operations for
event group 4 and channels >= 8?

[ ... ]
> @@ -2089,8 +2103,10 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
>  		return -EINVAL;
>  
>  	/* Find logical channel */
> -	for (j = 0; j < d40c->base->num_phy_chans; j += 8) {
> +	for (j = 0; j < d40c->base->num_phy_chans; j += D40_GROUP_SIZE) {
>  		int phy_num = j + event_group * 2;
> +		if (phy_num + 1 >= num_phy_chans)
> +			break;

[Severity: High]
Will this mathematical collision also occur here for logical channel allocation
when event_group is 4?

[ ... ]
> @@ -3470,6 +3486,7 @@ static int __init d40_hw_detect_init(struct platform_device *pdev,
>  	base->log_chans = &base->phy_chans[num_phy_chans];
>  
>  	if (base->plat_data->num_of_phy_chans == 14) {
> +		base->gen_dmac.num_event_groups = D40_EVENT_GROUPS_V4B;

[Severity: High]
Does setting the max event groups to 5 allow event_group = 4, which
ultimately exposes the aliasing bug against the hardcoded block size of 8
in d40_allocate_channel()?

>  		base->gen_dmac.backup = d40_backup_regs_v4b;
>  		base->gen_dmac.backup_size = BACKUP_REGS_SZ_V4B;
>  		base->gen_dmac.interrupt_en = D40_DREG_CPCMIS;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-dma40-fixes-v6-0-fdb6755020a2@kernel.org?part=20