[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <659d6affd7c58474c4bca5c92fc762925591d0d9.camel@ew.tq-group.com>
Date: Tue, 15 Apr 2025 15:36:01 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Andy Whitcroft
<apw@...onical.com>, Dwaipayan Ray <dwaipayanray1@...il.com>, Lukas Bulwahn
<lukas.bulwahn@...il.com>, Joe Perches <joe@...ches.com>, Jonathan Corbet
<corbet@....net>, Nishanth Menon <nm@...com>, Vignesh Raghavendra
<vigneshr@...com>, Siddharth Vadapalli <s-vadapalli@...com>, Roger Quadros
<rogerq@...nel.org>, Tero Kristo <kristo@...nel.org>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux@...tq-group.com
Subject: Re: [PATCH net-next 4/4] checkpatch: check for comment explaining
rgmii(|-rxid|-txid) PHY modes
On Tue, 2025-04-15 at 15:20 +0200, Andrew Lunn wrote:
>
> > + **UNCOMMENTED_RGMII_MODE**
> > + Historially, the RGMII PHY modes specified in Device Trees have been
> > + used inconsistently, often referring to the usage of delays on the PHY
> > + side rather than describing the board.
> > +
> > + PHY modes "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock
> > + signal to be delayed on the PCB; this unusual configuration should be
> > + described in a comment. If they are not (meaning that the delay is realized
> > + internally in the MAC or PHY), "rgmii-id" is the correct PHY mode.
>
> It is unclear to me how much ctx_has_comment() will return. Maybe
> include an example here of how it should look. I'm assuming:
>
> /* RGMII delays added via PCB traces */
> &enet2 {
> phy-mode = "rgmii";
> status = "okay";
>
> fails, but
>
> &enet2 {
> /* RGMII delays added via PCB traces */
> phy-mode = "rgmii";
> status = "okay";
>
> passes?
Yes, it works like that. I can't claim to fully understand the checkpatch code
handling comments, but I copied it from other similar checks and tested it on a
few test patches.
One thing to note is that I implemented it as a CHK() and not a WARN() because
that's what is used for other comment checks like DATA_RACE - meaning it will
only trigger with --strict.
>
> >
> > Commit message
> > --------------
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 784912f570e9d..57fcbd4b63ede 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3735,6 +3735,17 @@ sub process {
> > }
> > }
> >
> > +# Check for RGMII phy-mode with delay on PCB
> > + if ($realfile =~ /\.dtsi?$/ && $line =~ /^\+\s*(phy-mode|phy-connection-type)\s*=\s*"/ &&
>
> I don't grok perl. Is this only looking a dtsi files? .dts files
> should also be checked.
It is a regular expression - the ? makes the previous character optional,
matching both .dts and .dtsi files.
Best,
Matthias
>
> Thanks for working on this, it will be very useful.
>
> Andrew
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
Powered by blists - more mailing lists