linux-kernel - Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds

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

Date:   Mon, 18 May 2020 17:59:58 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Paul Burton <paulburton@...nel.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Arnd Bergmann <arnd@...db.de>,
        Allison Randal <allison@...utok.net>,
        Gareth Williams <gareth.williams.jx@...esas.com>,
        Rob Herring <robh+dt@...nel.org>, <linux-mips@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Georgy Vlasov <Georgy.Vlasov@...kalelectronics.ru>,
        Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@...el.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Clement Leger <cleger@...ray.eu>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request
 thresholds

On Mon, May 18, 2020 at 05:48:34PM +0300, Andy Shevchenko wrote:
> On Mon, May 18, 2020 at 04:43:06PM +0300, Serge Semin wrote:
> > On Mon, May 18, 2020 at 04:25:20PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 18, 2020 at 3:53 PM Serge Semin
> > > <Sergey.Semin@...kalelectronics.ru> wrote:
> > > > On Mon, May 18, 2020 at 02:03:43PM +0300, Andy Shevchenko wrote:
> > > > > On Sat, May 16, 2020 at 11:01:33PM +0300, Serge Semin wrote:
> > > > > > On Fri, May 15, 2020 at 05:38:42PM +0300, Andy Shevchenko wrote:
> > > > > > > On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote:
> 
> ...
> 
> > > > > > It's not like anyone cared about padding in this structure in the first place)
> > > > >
> > > > > I think I have been caring (to some extend).
> > > >
> > > > Well, If you have then instead of asking to rearrange just two members (which
> > > > by the way finely grouped by the Tx-Rx affiliation) why not sending a
> > > > patch, which would refactor the whole structure so to be optimal for the x64
> > > > platforms? I don't really see why this gets very important for you seeing
> > > > Mark is Ok with this. My current commit follows the common driver design
> > > > including the DW SSI data members grouping. On the second thought I'll leave
> > > > it as is then.
> > > 
> > > Again same issue here. What is really easy to do for you here, will
> > > become a burden and additional churn to anybody else.
> > > So, why not to minimize it in the first place? Same with comma in
> > > another patch. Sorry, I really don't get it.
> > 
> > If comma is more or less understandable (though adding it is absolutely
> > redundant there and doesn't worth even a bit of time spending for the
> > discussion), here you consider the patch from padding point of view.
> > The driver developer didn't care about it, but did care about grouping the
> > members in a corresponding way. The padding burden will be there anyway and
> > should be fixed for the whole structure in an additional patch. Until then
> > the way of grouping should be preserved.
> 
> Like you said, we spent already much more time than that simple change can be
> satisfied. And like you said, "deleloper ... did care about groupping members
> in a corresponding way". So, if we look at this in the original code, my
> suggestion, besides padding benefit, is consistent with existing pattern in
> that data structure.

What pattern do you mean? As I see it, my implementation is consistent with
current structure structure, while yours is not.

-Sergey

> 
> Note, I agree on extern keyword change can be postponed (it was in the original
> code), but here you introduce a new code...
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>