Re: [PATCH RFC v11 07/12] crypto: qce - Communicate the base physical address to the dmaengine

[Vinod Koul <vkoul@kernel.org>]

On 04-03-26, 16:05, Bartosz Golaszewski wrote:
> On Wed, Mar 4, 2026 at 3:39 PM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 02-03-26, 16:57, Bartosz Golaszewski wrote:
> > > In order to let the BAM DMA engine know which address is used for
> > > register I/O, call dmaengine_slave_config() after requesting the RX
> > > channel and use the config structure to pass that information to the
> > > dmaengine core. This is done ahead of extending the BAM driver with
> > > support for pipe locking, which requires performing dummy writes when
> > > passing the lock/unlock flags alongside the command descriptors.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > ---
> > >
> > >       dma->txchan = devm_dma_request_chan(dev, "tx");
> > >       if (IS_ERR(dma->txchan))
> > > @@ -121,6 +123,12 @@ int devm_qce_dma_request(struct qce_device *qce)
> > >               return dev_err_probe(dev, PTR_ERR(dma->rxchan),
> > >                                    "Failed to get RX DMA channel\n");
> > >
> > > +     cfg.dst_addr = qce->base_phys;
> > > +     cfg.direction = DMA_MEM_TO_DEV;
> >
> > So is this the address of crypto engine address where dma data is
> > supposed to be pushed to..?
> 
> No. In case I wasn't clear enough in the cover letter: this is the
> address of the *crypto engine* register which we use as a scratchpad
> for the dummy write when issuing the lock/unlock command. Mani
> suggested under the cover letter to use the descriptor metadata for
> that.

This is overloading of address field. If we go this was I would add a
comment in code explaining this and why in the setup the engine does not
need peripheral address. Meta data sounds okay as well.

-- 
~Vinod