[<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