linux-kernel - Re: [PATCH v3 00/50] Add support for sam9x7 SoC family

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:   Fri, 28 Jul 2023 18:36:47 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Conor Dooley <conor@...nel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Varshini Rajendran <varshini.rajendran@...rochip.com>,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, nicolas.ferre@...rochip.com,
        alexandre.belloni@...tlin.com, claudiu.beznea@...rochip.com,
        mturquette@...libre.com, sboyd@...nel.org,
        herbert@...dor.apana.org.au, davem@...emloft.net, vkoul@...nel.org,
        andi.shyti@...nel.org, tglx@...utronix.de, maz@...nel.org,
        lee@...nel.org, ulf.hansson@...aro.org, tudor.ambarus@...aro.org,
        richard@....at, vigneshr@...com, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com, linus.walleij@...aro.org,
        sre@...nel.org, p.zabel@...gutronix.de, olivia@...enic.com,
        a.zummo@...ertech.it, radu_nicolae.pirea@....ro,
        richard.genoud@...il.com, gregkh@...uxfoundation.org,
        lgirdwood@...il.com, broonie@...nel.org, wim@...ux-watchdog.org,
        linux@...ck-us.net, linux@...linux.org.uk,
        durai.manickamkr@...rochip.com, andrew@...n.ch,
        jerry.ray@...rochip.com, andre.przywara@....com, mani@...nel.org,
        alexandre.torgue@...com, gregory.clement@...tlin.com,
        arnd@...db.de, rientjes@...gle.com, deller@....de,
        42.hyeyoo@...il.com, vbabka@...e.cz, mripard@...nel.org,
        mihai.sain@...rochip.com, codrin.ciubotariu@...rochip.com,
        eugen.hristev@...labora.com, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-crypto@...r.kernel.org,
        dmaengine@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-mmc@...r.kernel.org, linux-mtd@...ts.infradead.org,
        netdev@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-rtc@...r.kernel.org,
        linux-spi@...r.kernel.org, linux-serial@...r.kernel.org,
        alsa-devel@...a-project.org, linux-usb@...r.kernel.org,
        linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v3 00/50] Add support for sam9x7 SoC family

On 28/07/2023 18:10, Conor Dooley wrote:
> On Fri, Jul 28, 2023 at 06:04:43PM +0200, Miquel Raynal wrote:
>> Hi Conor,
>>
>> conor@...nel.org wrote on Fri, 28 Jul 2023 16:50:24 +0100:
>>
>>> On Fri, Jul 28, 2023 at 01:32:12PM +0200, Krzysztof Kozlowski wrote:
>>>> On 28/07/2023 12:22, Varshini Rajendran wrote:  
>>>>> This patch series adds support for the new SoC family - sam9x7.
>>>>>  - The device tree, configs and drivers are added
>>>>>  - Clock driver for sam9x7 is added
>>>>>  - Support for basic peripherals is added
>>>>>  - Target board SAM9X75 Curiosity is added
>>>>>   
>>>>
>>>> Your threading is absolutely broken making it difficult to review and apply.  
>>>
>>> I had a chat with Varshini today, they were trying to avoid sending the
>>> patches to a massive CC list, but didn't set any in-reply-to header.
>>> For the next submission whole series could be sent to the binding &
>>> platform maintainers and the individual patches additionally to their
>>> respective lists/maintainers. Does that sound okay to you, or do you
>>> think it should be broken up?
>>
>> I usually prefer receiving the dt-bindings *and* the driver changes, so
>> I can give my feedback on the description side, as well as looking at
>> the implementation and see if that really matches what was discussed
>> with you :)
> 
> Right, that is what I was suggesting. Respective maintainers would get
> the drivers *and* bindings for their subsystems - IOW, each patch is
> sent to what get_maintainer.pl outputs for it.

For reviewers I find the easiest if this is mostly split per subsystem.
There were here few patches for USB, few clk etc, so these easily can be
separate patchsets. All the rest one-liners or one-patch-per-subsystem
could be grouped and set in one patchset, after fixing the threading.

But the moment the patchset grows to 50 it's time to re-think it whether
this grouping is necessary or even beneficial.

This is not a conversion of mach to DT (like ep93xx) which benefits of
doing everything in one step. Therefore my recommendation for this work
is to split it entirely per each subsystem.

Best regards,
Krzysztof