linux-kernel - Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for BAM locking

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MejA90TRue6F2JjQXHYo0AmFxc-gKkwNX0EKzP5scB14Q@mail.gmail.com>
Date: Wed, 14 Jan 2026 16:37:33 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Vinod Koul <vkoul@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, Thara Gopinath <thara.gopinath@...il.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Udit Tiwari <quic_utiwari@...cinc.com>, Daniel Perez-Zoghbi <dperezzo@...cinc.com>, 
	Md Sadre Alam <mdalam@....qualcomm.com>, Dmitry Baryshkov <lumag@...nel.org>, dmaengine@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-crypto@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for
 BAM locking

On Fri, Jan 9, 2026 at 3:15 PM Bartosz Golaszewski <brgl@...nel.org> wrote:
>
> On Fri, Jan 9, 2026 at 3:27 AM Vinod Koul <vkoul@...nel.org> wrote:
> >
> > >
> > > We need an API because we send a locking descriptor, then a regular
> > > descriptor (or descriptors) for the actual transaction(s) and then an
> > > unlocking descriptor. It's a thing the user of the DMA engine needs to
> > > decide on, not the DMA engine itself.
> >
> > I think downstream sends lock descriptor always. What is the harm in
> > doing that every time if we go down that path?
>
> No, in downstream it too depends on the user setting the right bits.
> Currently the only user of the BAM locking downstream is the NAND
> driver. I don't think the code where the crypto driver uses it is
> public yet.
>
> And yes, there is harm - it slightly impacts performance. For QCE it
> doesn't really matter as any users wanting to offload skcipher or SHA
> are better off using the Arm Crypto Extensions anyway as they are
> faster by an order of magnitude (!). It's also the default upstream,
> where the priorities are set such that the ARM CEs are preferred over
> the QCE. QCE however, is able to coordinate with the TrustZone and
> will be used to support the DRM use-cases.
>
> I prefer to avoid impacting any other users of BAM DMA.
>
> > Reg Dmitry question above, this is dma hw capability, how will client
> > know if it has to lock on older rev of hardware or not...?
> >
> > > Also: only the crypto engine needs it for now, not all the other users
> > > of the BAM engine.
> >
>
> Trying to set the lock/unlock bits will make
> dmaengine_desc_attach_metadata() fail if HW does not support it.
>
> > But they might eventually right?
> >
>
> Yes, and they will already have the interface to do it - in the form
> of descriptor metadata.
>

Hi! Have I answered all your questions? Can we proceed with this?

Bartosz