From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH v2 3/3] dt-bindings: net: Document support for Aeonsemi PHYs
Date: Wed, 26 Mar 2025 16:16:37 +0100 [thread overview]
Message-ID: <67e41a57.df0a0220.21de93.f609@mx.google.com> (raw)
In-Reply-To: <77a366f8-0b58-4e1f-9020-b57f7c90b3bb@lunn.ch>
On Wed, Mar 26, 2025 at 04:08:31PM +0100, Andrew Lunn wrote:
> > + A PHY with not firmware loaded will be exposed on the MDIO bus with ID
> > + 0x7500 0x7500 or 0x7500 0x9410 on C45 registers.
>
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id7500.9410
> > + - ethernet-phy-id7500.9402
> > + - ethernet-phy-id7500.9412
> > + - ethernet-phy-id7500.9422
> > + - ethernet-phy-id7500.9432
> > + - ethernet-phy-id7500.9442
> > + - ethernet-phy-id7500.9452
> > + - ethernet-phy-id7500.9462
> > + - ethernet-phy-id7500.9472
> > + - ethernet-phy-id7500.9482
> > + - ethernet-phy-id7500.9492
>
> > + ethernet-phy@1f {
> > + compatible = "ethernet-phy-id7500.9410",
> > + "ethernet-phy-ieee802.3-c45";
>
> You need to be careful here. And fully understand what this means. In
> general, you don't list a compatible here, or only
> ethernet-phy-ieee802.3-c45. This is because the bus can be enumerated,
> you can get the ID from the device. What is in the device is more
> likely to be correct than whatever the DT author put here. However,
> you can state a compatible with an ID, and when you do that, it means
> the PHY device ID in the silicon is broken, ignore it, probe based on
> the value here. So if you state ethernet-phy-id7500.9410, it does not
> matter if there is firmware or not in the PHY, what ID the PHY has, it
> will get probed as a ethernet-phy-id7500.9410.
>
> Except, if there is a .match_phy_device in the driver ops. If there is
> a .match_phy_device the driver does whatever it wants to try to
> identify the device and perform a match.
>
Yep I will note this for the PHY driver. I really need to use
match_phy_device for the FW load OPs to prevent any kind of bad
compatible.
In C22 75007500 is reported while in C45 a more correct 75009410 is
reported, this is why the c45 compatible.
Aside from this, the compatible listed here are really just to document
the need for firmware-name and to what PHY it should be needed. It's a
pattern I followed from the aquantia schema.
Example for PHY with ID 7500.9410 in C45, firmware-name is required, for
anything else (example 7500.9422) firmware-name property should not be
used (case with a SPI attached for example).
--
Ansuel
prev parent reply other threads:[~2025-03-26 15:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 0:23 [net-next RFC PATCH v2 0/3] net: phy: Add support for new Aeonsemi PHYs Christian Marangi
2025-03-26 0:23 ` [net-next RFC PATCH v2 1/3] net: phy: permit PHYs to register a second time Christian Marangi
2025-03-26 0:23 ` [net-next RFC PATCH v2 2/3] net: phy: Add support for Aeonsemi AS21xxx PHYs Christian Marangi
2025-03-26 13:53 ` Russell King (Oracle)
2025-03-26 13:57 ` Andrew Lunn
2025-03-26 14:47 ` Christian Marangi
2025-03-26 14:43 ` Christian Marangi
2025-03-26 18:02 ` Russell King (Oracle)
2025-03-26 14:00 ` Simon Horman
2025-03-26 14:05 ` Simon Horman
2025-03-26 14:56 ` Andrew Lunn
2025-03-26 15:09 ` Christian Marangi
2025-03-26 18:08 ` Russell King (Oracle)
2025-03-26 18:18 ` Christian Marangi
2025-03-26 18:32 ` Russell King (Oracle)
2025-03-26 0:23 ` [net-next RFC PATCH v2 3/3] dt-bindings: net: Document support for Aeonsemi PHYs Christian Marangi
2025-03-26 15:08 ` Andrew Lunn
2025-03-26 15:16 ` Christian Marangi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67e41a57.df0a0220.21de93.f609@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).