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]
Message-ID: <877czbs8w7.fsf@mpe.ellerman.id.au>
Date:   Thu, 01 Dec 2022 21:42:00 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        soc@...nel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Rafał Miłecki 
        <zajec5@...il.com>, Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Stefan Agner <stefan@...er.ch>,
        Heiko Stuebner <heiko@...ech.de>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Tim Harvey <tharvey@...eworks.com>,
        Peng Fan <peng.fan@....com>,
        Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Michael Riesch <michael.riesch@...fvision.net>,
        Oleksij Rempel <linux@...pel-privat.de>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-sunxi@...ts.linux.dev, linux-rockchip@...ts.infradead.org,
        linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 0/5] remove label = "cpu" from DSA dt-binding

Arınç ÜNAL <arinc.unal@...nc9.com> writes:
> On 30.11.2022 18:55, Andrew Lunn wrote:
>> On Wed, Nov 30, 2022 at 05:10:35PM +0300, Arınç ÜNAL wrote:
>>> Hello folks,
>>>
>>> With this patch series, we're completely getting rid of 'label = "cpu";'
>>> which is not used by the DSA dt-binding at all.
>>>
>>> Information for taking the patches for maintainers:
>>> Patch 1: netdev maintainers (based off netdev/net-next.git main)
>>> Patch 2-3: SoC maintainers (based off soc/soc.git soc/dt)
>>> Patch 4: MIPS maintainers (based off mips/linux.git mips-next)
>>> Patch 5: PowerPC maintainers (based off powerpc/linux.git next-test)
>> 
>> Hi Arınç
>> 
>> So your plan is that each architecture maintainer merges one patch?
>
> Initially, I sent this series to soc@...nel.org to take it all but Rob 
> said it must be this way instead.
>
>> 
>> That is fine, but it is good to be explicit, otherwise patches will
>> fall through the cracks because nobody picks them up. I generally use
>> To: to indicate who i expect to merge a patch, and everybody else in
>> the Cc:
>
> Thanks for this, I'll follow suit if I don't see any activity for a few 
> weeks.

IMHO the best solution if the patches are truly independent is to send
them independantly to each maintainer. That way there's no confusion
about whether someone else will take the series.

It's also simpler for maintainers to apply a single standalone patch vs
pick a single patch from a larger series.

cheers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ