linux-kernel - Re: [PATCH v4 15/19] dmaengine: ti: k3-udma-v2: New driver for K3 BCDMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <66bedd88-8ac6-45bb-866d-edaf436ee359@gmail.com>
Date: Tue, 3 Feb 2026 20:14:12 +0200
From: Péter Ujfalusi <peter.ujfalusi@...il.com>
To: Sai Sree Kartheek Adivi <s-adivi@...com>, vkoul@...nel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, nm@...com,
 ssantosh@...nel.org, dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 vigneshr@...com
Cc: r-sharma3@...com, gehariprasath@...com
Subject: Re: [PATCH v4 15/19] dmaengine: ti: k3-udma-v2: New driver for K3
 BCDMA_V2

Hi Kartheek,

On 03/02/2026 10:22, Sai Sree Kartheek Adivi wrote:
>>> @@ -632,7 +641,8 @@ int udma_configure_statictr(struct udma_chan *uc,
>>> struct udma_desc *d,
>>>               d->static_tr.bstcnt = d->residue / d->sglen / div;
>>>           else
>>>               d->static_tr.bstcnt = d->residue / div;
>>> -    } else if (uc->ud->match_data->type == DMA_TYPE_BCDMA &&
>>> +    } else if ((uc->ud->match_data->type == DMA_TYPE_BCDMA ||
>>> +           uc->ud->match_data->type == DMA_TYPE_BCDMA_V2) &&
>> Have you thought of adding a version member to struct udma_match_data
>> and use that instead of distinct different types for BCDMA/PKTDMA?
>>
>> Here for example you would not need any change as the code is common for
>> both v1 and v2.
>
> Hi Peter,
>
>
> I'm preparing a v5 and wanted to align with you on the handling of
> different dma
>
> variants (udma, bcdma, pktdma & v1, v2).
>
>
> Frank suggested moving toward feature flags (capabilities) in the
> match_data,
>
> rather than checking type. [1]
>
>
> I want to get your thoughts on Frank's suggestion before I proceed. Do
> you have
>
> any strong objections to using feature flags? I see merit in that
> approach for
>
> scaling to possible future DMA variants in K3 SoCs.
You have several differences here and there (small and big) between the
v1 and v2, if you want to feature flag these out you would need to have
a meaningful flag for each and every one of them.

I find this a daunting task to be honest, so I would go with the simpler
way to just use version to cover _all_ differences in one step.
How one should be handling things if
A) feature = FEATURE_1
B) feature = FEATURE_2
C) feature = FEATURE_1 | FEATURE_2
D) feature = FEATURE_1 | FEATURE_2 | FEATURE_3
E) feature = FEATURE_1 | FEATURE_3
...

I think this might get out of hand easily, but you know the hardware
better, which way fits better, which will scale better for the future.

Also, you set a FEATURE flag for V2, but it might be that in V3 revision
the same thing must be done in a third way, so you would need to
allocate a bit array to say that this feature have this three ways of
handling, etc.

Either way will help to make the code a bit cleaner, which is already in
good shape.

-- 
Péter