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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ