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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.