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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200513114258.ataikbtajhyty5y3@mobilestation>
Date:   Wed, 13 May 2020 14:42:58 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Mark Brown <broonie@...nel.org>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Georgy Vlasov <Georgy.Vlasov@...kalelectronics.ru>,
        Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Maxim Kaurkin <Maxim.Kaurkin@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Ekaterina Skachko <Ekaterina.Skachko@...kalelectronics.ru>,
        Vadim Vlasov <V.Vlasov@...kalelectronics.ru>,
        Alexey Kolotnikov <Alexey.Kolotnikov@...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>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Gareth Williams <gareth.williams.jx@...esas.com>,
        Rob Herring <robh+dt@...nel.org>, <linux-mips@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] spi: dw: Add generic DW DMA controller support

On Wed, May 13, 2020 at 12:21:16PM +0100, Mark Brown wrote:
> On Wed, May 13, 2020 at 02:04:07PM +0300, Serge Semin wrote:
> > On Wed, May 13, 2020 at 11:23:24AM +0100, Mark Brown wrote:
> 
> > > The conversion to YAML format should be the very last thing in the patch
> > > series,
> 
> > Hm, haven't heard about this requirement. Could you point me out to a doc or
> > some discussion concerning this for future reference? It's not a first DT
> > conversion patch I've submitted and non of them were addressed with such
> > request. I do understand that the order of DT concerning patches can be
> > important and agree to fix it by updating the original legacy binding first,
> > then perform a conversion. But placing the conversion in a tail of the series
> > just seems unnecessary. The patch can be dropped from any place of the series
> > if for some reason Rob would be late with review.
> 
> This is a practical observation based on the fact that there is a huge
> backlog of reviews of DT binding conversions and that those conversions
> typically go through several review cycles and that not everyone who's
> sending patches to the kernel is fully up to speed on processes or has
> strong English.  By telling people (including other people who find
> instructions on the list) to put the conversion right at the end of the
> series I am avoiding any ambiguity or confusion about ordering with
> regard to any other patches to the DT, including any new patches that
> get added to the series.
> 
> > Personally I prefer placing all DT changes in the head of the series, so Rob
> > wouldn't need to search through the whole patchset looking for the DT-related
> > patches.
> 
> Ideally the YAML conversions would be done entirely separately to other
> development rather than as part of a bigger series, they're pretty much
> orthogonal anyway.  Sadly there's obvious content collisions with any
> new development that adds DT stuff so that's not always the most
> practical thing.

Ok. I see your point. I'll move the conversion patch to the tail of the series
after rebasing the patchset on top of the spi/for-next branch. Thanks for
clarification.

-Sergey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ