linux-kernel - Re: [PATCH 00/30] spi: dw: Add full Baikal-T1 SPI Controllers support

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:   Wed, 30 Sep 2020 01:43:03 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Mark Brown <broonie@...nel.org>
CC:     Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        "wuxu . wu" <wuxu.wu@...wei.com>, Feng Tang <feng.tang@...el.com>,
        Rob Herring <robh+dt@...nel.org>, <linux-spi@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/30] spi: dw: Add full Baikal-T1 SPI Controllers support

Hi Mark

On Tue, Sep 29, 2020 at 03:43:51PM +0100, Mark Brown wrote:
> On Sun, Sep 20, 2020 at 02:28:44PM +0300, Serge Semin wrote:
> 
> > First two patches are just cleanups to simplify the DW APB SSI device
> > initialization a bit. We suggest to discard the IRQ threshold macro as
> > unused and use a ternary operator to initialize the set_cs callback
> > instead of assigning-and-updating it.
> 
> > Then we've discovered that the n_bytes field of the driver private data is
> > used by the DW APB SSI IRQ handler, which requires it to be initialized
> 

> This is a *huge* patch series which is a bit unweildy to review
> (especially given the other 10+ patch series you sent at the same time),

Yeah, sorry about the bulky series. If most of the changes have been more
complicated than that, less inter-dependent and less directed to having the code
prepared for the main alterations I would have definitely split them up in
different series. But the biggest part of the patchset is just a preparation
before adding the mem-ops, poll-based transfers and Baikal-T1 SPI support. So
having them submitted without the main part of the patchset would be just weird.

The other 10+ patches were sent months ago. I've just resent them with minor
alterations to get more attention.) Anyway since they concern an absolutely
different functionality (DW APB SSI DMA driver) of course I've delivered them in
the framework of the different patchset.

> once you start getting over 10 patches it's time to pay attention to
> series length and the fact that you're outlining a bunch of tangentially
> related areas which could have been split out easily enough.  It is much
> better to send smaller sets of patches at once, or if you're sending a
> lot then to split them into smaller serieses.  This will tend to make
> the review more approachable which will in turn tend to make things go
> faster, people are much more likely to put off going through a huge
> series.

I see you have already merged in the first nine patches. So would you like me
to split the rest of them up into two series or it would be ok to resend (if
required) them as one series seeing it's not that bulky anymore?

-Sergey