linux-kernel - Re: [net-next RFC PATCH v2 3/3] dt-bindings: net: Document support for Aeonsemi PHYs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67e41a57.df0a0220.21de93.f609@mx.google.com>
Date: Wed, 26 Mar 2025 16:16:37 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
	"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>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next RFC PATCH v2 3/3] dt-bindings: net: Document support
 for Aeonsemi PHYs

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