linux-kernel - Re: [net-next PATCH 1/2] net: phy: Add support for new 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: <67e314f2.050a0220.f130b.7b84@mx.google.com>
Date: Tue, 25 Mar 2025 21:41:20 +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 PATCH 1/2] net: phy: Add support for new Aeonsemi PHYs

On Tue, Mar 25, 2025 at 09:33:26PM +0100, Andrew Lunn wrote:
> On Tue, Mar 25, 2025 at 01:04:30PM +0100, Christian Marangi wrote:
> > On Mon, Mar 24, 2025 at 04:16:09PM +0100, Andrew Lunn wrote:
> > > On Mon, Mar 24, 2025 at 03:16:08PM +0100, Christian Marangi wrote:
> > > > On Mon, Mar 24, 2025 at 03:03:51PM +0100, Andrew Lunn wrote:
> > > > > > Supported PHYs AS21011JB1, AS21011PB1, AS21010JB1, AS21010PB1,
> > > > > > AS21511JB1, AS21511PB1, AS21510JB1, AS21510PB1, AS21210JB1,
> > > > > > AS21210PB1 that all register with the PHY ID 0x7500 0x7500
> > > > > > before the firmware is loaded.
> 
> Do you have details of how these different PHY differ? Do they have
> different features?
>

No but I can ask more details. From what I can assume, gigabit, 2.5g 10g
and probably a PHY that expose multiple port (PHY package thing)

> > Ok update on this... The PHY report 7500 7500 but on enabling PTP clock,
> > a more specific ""family"" ID is filled in MMD that is 0x7500 0x9410.
> 
> Do they all support PTP?
> 

With PTP it's not the PTP we think but I guess it's something internal to
the PHY to actually start it. From comments it's called PTP Clock...

> > They all use the same firmware so matching for the family ID might not
> > be a bad idea... The alternative is either load the firmware in
> > match_phy_device or introduce some additional OPs to handle this
> > correctly...
> > 
> > Considering how the thing are evolving with PHY I really feel it's time
> > we start introducing specific OP for firmware loading and we might call
> > this OP before PHY ID matching is done (or maybe do it again).
> 
> You cannot download firmware before doing some sort of match, because
> you have no idea what PHY you actually have until you do a match, and
> if the PHY needs firmware.
> 
> match_phy_device() gives you a bit more flexibility. It will be called
> for every PHY on the board, independent of the ID registers. So you
> can read the ID registers, see if it is at least a vendor you know how
> to download firmware to, do the download, and then look at the ID
> registers again to see if it is the version of the PHY you want to
> drive. If not, return -ENODEV, and the core will try the next driver
> entry.
>

I'm finishing preparing V2 and I'm curious what you will think of the
implementation.

The approach I found works good is permit PHY device to register a
second time and the PHY driver toggle this.

This way in a PHY driver we register OPs for the to-be-init PHY and then
we probe the real one.

-- 
	Ansuel