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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f6b520c-203d-48cc-8bef-18959672052c@lunn.ch>
Date: Wed, 28 Jan 2026 22:45:32 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
Cc: Marco Felsch <m.felsch@...gutronix.de>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	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

On Wed, Jan 28, 2026 at 10:04:03PM +0100, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Jan 28, 2026 at 9:51 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > The issue was with the out-of-band reset coming from the FEC driver
> > > which doesn't honor the phy state-machine.
> >
> > Could you explain this is more details. Is the FEC doing something
> > wrong?
> 
> The fact that the phy should be reset when the clk is provided to it, is not
> connected at all with the fec. I think that fec_main does not register itself
> as clock provider, You "should" define the phy to have a clock if this is needed
> during the restoration and we should not give any "magic" at controller level.

Do we know which clock the PHY is consuming?

The FEC has code for the clock "enet_out" which it enables and
disables. If the PHY is also consuming this clock, we could also make
it a consumer. The CCF reference counts enables/disables of clocks, so
if the PHY enables it, the MAC won't be able to disable it.

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ