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: <aWBndOfbtweRr0uS@vaman>
Date: Fri, 9 Jan 2026 07:57:00 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Bartosz Golaszewski <brgl@...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 02-01-26, 18:14, Bartosz Golaszewski wrote:
> On Fri, Jan 2, 2026 at 5:59 PM Vinod Koul <vkoul@...nel.org> wrote:
> >
> > On 02-01-26, 10:26, Bartosz Golaszewski wrote:
> > > On Thu, Jan 1, 2026 at 1:00 PM Vinod Koul <vkoul@...nel.org> wrote:
> > > >
> > > > > >
> > > > > > > It will perform register I/O with DMA using the BAM locking mechanism
> > > > > > > for synchronization. Currently linux doesn't use BAM locking and is
> > > > > > > using CPU for register I/O so trying to access locked registers will
> > > > > > > result in external abort. I'm trying to make the QCE driver use DMA
> > > > > > > for register I/O AND use BAM locking. To that end: we need to pass
> > > > > > > information about wanting the command descriptor to contain the
> > > > > > > LOCK/UNLOCK flag (this is what we set here in the hardware descriptor)
> > > > > > > from the QCE driver to the BAM driver. I initially used a global flag.
> > > > > > > Dmitry said it's too Qualcomm-specific and to use metadata instead.
> > > > > > > This is what I did in this version.
> > > > > >
> > > > > > Okay, how will client figure out should it set the lock or not? What are
> > > > > > the conditions where the lock is set or not set by client..?
> > > > > >
> > > > >
> > > > > I'm not sure what you refer to as "client". The user of the BAM engine
> > > > > - the crypto driver? If so - we convert it to always lock/unlock
> > > > > assuming the TA *may* use it and it's better to be safe. Other users
> > > > > are not affected.
> > > >
> > > > Client are users of dmaengine. So how does the crypto driver figure out
> > > > when to lock/unlock. Why not do this always...?
> > > >
> > >
> > > It *does* do it always. We assume the TA may be doing it so the crypto
> > > driver is converted to *always* perform register I/O with DMA *and* to
> > > always lock the BAM for each transaction later in the series. This is
> > > why Dmitry inquired whether all the HW with upstream support actually
> > > supports the lock semantics.
> >
> > Okay then why do we need an API?
> >
> > Just lock it always and set the bits in the dma driver
> >
> 
> 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?
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.

But they might eventually right?

-- 
~Vinod