Subject: Re: [PATCH net-next 0/2] net: stmmac: thead: clean up clock rate setting

From: "Russell King (Oracle)" <[email-masked]>
Date: Sun, 23 Feb 2025 11:40:14 +0000

Adding Joe Perches.

On Fri, Feb 21, 2025 at 02:15:17PM +0000, Russell King (Oracle) wrote:
> Hi,
> 
> This series cleans up the thead clock rate setting to use the
> rgmii_clock() helper function added to phylib.
> 
> The first patch switches over to using the rgmii_clock() helper,
> and the second patch cleans up the verification that the desired
> clock rate is achievable, allowing the private clock rate
> definitions to be removed.
> 
>  drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c | 28 ++++++++---------------
>  1 file changed, 9 insertions(+), 19 deletions(-)

I've been investigating why the NIPA bot complains about maintainers
not being Cc'd, such as for patch 1 of this series:

https://netdev.bots.linux.dev/static/nipa/936447/13985595/cc_maintainers/stdout

I think this is a bug in either get_maintainers.pl or the NIPA bot.

On the bare patch without any Cc: header added:

$ scripts/get_maintainer.pl 0001-net-stmmac-thead-use-rgmii_clock-for-RGMII-clock-rat.patch
Drew Fustini <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Guo Ren <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Fu Wei <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Andrew Lunn <[email-masked]> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <[email-masked]> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <[email-masked]> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <[email-masked]> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <[email-masked]> (maintainer:NETWORKING DRIVERS)
Maxime Coquelin <[email-masked]> (maintainer:ARM/STM32 ARCHITECTURE)
Alexandre Torgue <[email-masked]> (maintainer:ARM/STM32 ARCHITECTURE)
[email-masked] (open list:RISC-V THEAD SoC SUPPORT)
[email-masked] (open list:STMMAC ETHERNET DRIVER)
[email-masked] (moderated list:ARM/STM32 ARCHITECTURE)
[email-masked] (moderated list:ARM/STM32 ARCHITECTURE)

If I add those maintainers to a Cc header in the patch file (as it would
be if NIPA runs on the unmodified received email), and then re-run
get_maintainer.pl, then:

$ scripts/get_maintainer.pl 0001-net-stmmac-thead-use-rgmii_clock-for-RGMII-clock-rat.patch
Drew Fustini <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Guo Ren <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Fu Wei <[email-masked]> (maintainer:RISC-V THEAD SoC SUPPORT)
Andrew Lunn <[email-masked]> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <[email-masked]> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <[email-masked]> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <[email-masked]> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <[email-masked]> (maintainer:NETWORKING DRIVERS)
Maxime Coquelin <[email-masked]> (maintainer:ARM/STM32 ARCHITECTURE)
Alexandre Torgue <[email-masked]> (maintainer:ARM/STM32 ARCHITECTURE)
Paul Walmsley <[email-masked]> (supporter:RISC-V ARCHITECTURE:Keyword:riscv)
Palmer Dabbelt <[email-masked]> (supporter:RISC-V ARCHITECTURE:Keyword:riscv)
Albert Ou <[email-masked]> (supporter:RISC-V ARCHITECTURE:Keyword:riscv)
[email-masked] (open list:RISC-V THEAD SoC SUPPORT)
[email-masked] (open list:STMMAC ETHERNET DRIVER)
[email-masked] (moderated list:ARM/STM32 ARCHITECTURE)
[email-masked] (moderated list:ARM/STM32 ARCHITECTURE)
[email-masked] (open list)

Note the addition of Paul Walmsley, Palmer Dabbelt and Albert Ou that
was not in the original.

It seems that K: is fed everything in the file, including all headers.
In the second run, the addition of the [email-masked]
mailing list in the headers then causes a subseqent run of
get_maintainer.pl (and nipa's run of get_maintainer.pl) to then match
using K: riscv in the "RISC-V ARCHITECTURE" entry.

So, it seems running get_maintainer.pl on an email received from
mailing lists without first stripping many of the email headers can
lead to false K: matches.

This makes NIPA's cc_maintainers test unreliable.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!