linux-kernel - Re: [PATCH v7 05/11] dmaengine: Introduce DMA-device device

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: <20200713201306.4rfmvtjzklcldajc@mobilestation>
Date:   Mon, 13 Jul 2020 23:13:06 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Vinod Koul <vkoul@...nel.org>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Viresh Kumar <vireshk@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Arnd Bergmann <arnd@...db.de>,
        Rob Herring <robh+dt@...nel.org>, <linux-mips@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <dmaengine@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 05/11] dmaengine: Introduce DMA-device device_caps
 callback

Hello Vinod,
  
Could you please keep on this patchset review? Really, the patchset isn't that
big and complicated to be working on it for such a long time. I've sent it out
at the time of the kernel 5.6. I've considered all the Andy's comments since
then. There is going to be 5.9 merge window soon, but the patchset still under
review procedure, while I still have some work, which depends on the changes
provided by this patchset. It would be great to at least submit it for review
before the next merge window, and super-great have it merged in before that.

There is a Peter Ujfalusi comment to the patch
"[PATCH v7 04/11] dmaengine: Introduce max SG list entries capability", which
needs your attention. Could you please take a look at that? So I could submit
the next patchset revision if you agree with the Peter' suggestion.

-Sergey

On Mon, Jul 13, 2020 at 12:21:31PM +0530, Vinod Koul wrote:
> On 10-07-20, 12:38, Serge Semin wrote:
> > On Fri, Jul 10, 2020 at 11:45:03AM +0300, Andy Shevchenko wrote:
> > > On Fri, Jul 10, 2020 at 01:45:44AM +0300, Serge Semin wrote:
> > > > There are DMA devices (like ours version of Synopsys DW DMAC) which have
> > > > DMA capabilities non-uniformly redistributed between the device channels.
> > > > In order to provide a way of exposing the channel-specific parameters to
> > > > the DMA engine consumers, we introduce a new DMA-device callback. In case
> > > > if provided it gets called from the dma_get_slave_caps() method and is
> > > > able to override the generic DMA-device capabilities.
> > > 
> > 
> > > In light of recent developments consider not to add 'slave' and a such words to the kernel.
> > 
> > As long as the 'slave' word is used in the name of the dma_slave_caps
> > structure and in the rest of the DMA-engine subsystem, it will be ambiguous
> > to use some else terminology. If renaming needs to be done, then it should be
> > done synchronously for the whole subsystem.
> 
> Right, I have plans to tackle that during next merge window and have
> started changes. Thankfully slave_dma can be replaced by peripheral dma
> easily. But getting that in would be tricky as we need to change users
> too.
> 
> -- 
> ~Vinod