linux-kernel - Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init

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] [day] [month] [year] [list]

Message-ID: <CAOf5uw=J_Vj2aOFJi2jyfj_7osZgv9BB=2P=KZ76qV_mwJfHQA@mail.gmail.com>
Date: Wed, 28 Jan 2026 15:34:42 +0100
From: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Marco Felsch <m.felsch@...gutronix.de>, Andrew Lunn <andrew@...n.ch>, Wei Fang <wei.fang@....com>, 
	Shenwei Wang <shenwei.wang@....com>, Clark Wang <xiaoning.wang@....com>, 
	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>, 
	Heiner Kallweit <hkallweit1@...il.com>, 
	"open list:FREESCALE IMX / MXC FEC DRIVER" <imx@...ts.linux.dev>, 
	"open list:FREESCALE IMX / MXC FEC DRIVER" <netdev@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init_hw

Hi Russell

On Wed, Jan 28, 2026 at 2:58 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Wed, Jan 28, 2026 at 02:33:24PM +0100, Michael Nazzareno Trimarchi wrote:
> > Hi Andrew
> >
> > On Wed, Jan 28, 2026 at 2:25 PM Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > On Wed, Jan 28, 2026 at 10:46:41AM +0100, Michael Trimarchi wrote:
> > > > The current implementation of phy_reset_after_clk_enable requires MAC drivers
> > > > (like fec_main.c) to manually track PHY probing states and trigger resets
> > > > at specific points in their clock management flow and was created just for a SoC
> > > > vendor.
> > >
> > > We try to keep workarounds for specific SoC vendors out of the core,
> > > when possible. It just makes the core more complex for an edge case
> > > which most people don't care about. It is better to hide the
> > > complexity away in the driver which needs it.
> >
> > We should not merge things in the core that are for one Soc and
> > after d65af21842f8a7821fc3b28dc043c2f92b2b312c, I need to anyway to do:
> >
> > net: phy: smsc: Fix functionality of lan8710 in combination with NXP fec
> >
> > Revert "net: phy: smsc: LAN8710/20: remove PHY_RST_AFTER_CLK_EN flag"
> > d65af21842
>
> That commit is an example of a poor commit description. It doesn't
> describe the problem, nor which hardware this affects, so when we end
> up with this kind of situation, we're lacking the context behind why
> the change was made.
>
> So, how do we know that reverting that commit is not going to cause a
> regression for whatever platform the patch was proposed for?
>
> If you read the preceeding commit (which is referenced by the commit
> you intend to revert) itgives more information about the problem, and
> I would expect that reverting it will cause a regression with
> interrupts.

First the PHY_RST_AFTER_CLK_EN was introduced just for the phy that
needs a specific reset  sequence and we need to guarantee that the
clock to the phy is
active during the reset. Now phy clock can be provided even by the
fec_main and the code
there was written really to support in my opinion some reference
design they had at that time.
The entire code that I suggest to re-think is on top of this use case.
For the platform I get this problem
was an imx6ull and reverting that patch that triggered the nxp code
was the only way to have the
reset properly across the clock reset sequence. During this revert I
found this code and I have tried
to figure out it was possible to just let this specific flag used only
on the phy level.

>
> Adding Marco to this thread for comment.
>
> Also, maybe you could clearly state what the issue that you are trying
> to address - why do you need special reset handling for the combination
> of FEC + this PHY. Consider including that description in the commit
> message for any proposed solution so that - as is the case here looking
> back at Macro's commit - we can see _why_ the change is being made.
>

Michael

> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!



--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@...rulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@...rulasolutions.com
www.amarulasolutions.com