From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>,
Marco Felsch <m.felsch@pengutronix.de>,
Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>,
Clark Wang <xiaoning.wang@nxp.com>,
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>,
Heiner Kallweit <hkallweit1@gmail.com>,
"open list:FREESCALE IMX / MXC FEC DRIVER" <imx@lists.linux.dev>,
"open list:FREESCALE IMX / MXC FEC DRIVER"
<netdev@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init_hw
Date: Wed, 28 Jan 2026 22:17:41 +0000 [thread overview]
Message-ID: <aXqLBXs0fUIVkQg_@shell.armlinux.org.uk> (raw)
In-Reply-To: <9f6b520c-203d-48cc-8bef-18959672052c@lunn.ch>
On Wed, Jan 28, 2026 at 10:45:32PM +0100, Andrew Lunn wrote:
> 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@lunn.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.
As I've just mentioned earlier in this thread, there seems to be nothing
special about the LAN8710-like PHYs requiring their XTAL clock to be
running for reset to be functional. The same is true of AR8035 used
on i.MX6 SolidRun platforms, and Marvell 88E151x PHYs that I've looked
at. I would suggest that, in general, _all_ PHYs require their XTAL
clock to be running.
Therefore, this is not a work of the PHY at all.
It is a quirk of the board design to provide the PHY's XTAL clock from
the SoC, and this _seems_ to be common with FEC based systems, probably
because there's an easy way to get the clock from the FEC, thus saving
the cost of a crystal.
I stated how SolidRun handles this quirk entirely in uboot so the kernel
doesn't have to care about this at all, and the kernel doesn't get to
even know that the PHY has a reset GPIO.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2026-01-28 22:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 9:46 [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init_hw Michael Trimarchi
2026-01-28 13:25 ` Andrew Lunn
2026-01-28 13:33 ` Michael Nazzareno Trimarchi
2026-01-28 13:58 ` Russell King (Oracle)
2026-01-28 14:34 ` Michael Nazzareno Trimarchi
2026-01-28 20:26 ` Marco Felsch
2026-01-28 20:51 ` Andrew Lunn
2026-01-28 21:04 ` Michael Nazzareno Trimarchi
2026-01-28 21:20 ` Michael Nazzareno Trimarchi
2026-01-28 21:45 ` Andrew Lunn
2026-01-28 22:17 ` Russell King (Oracle) [this message]
2026-01-28 22:48 ` Russell King (Oracle)
2026-01-28 22:13 ` Russell King (Oracle)
2026-01-29 10:41 ` Marco Felsch
2026-01-29 10:55 ` Russell King (Oracle)
2026-01-29 11:17 ` Marco Felsch
2026-01-29 13:12 ` Russell King (Oracle)
2026-01-29 13:19 ` Russell King (Oracle)
2026-01-29 14:30 ` Russell King (Oracle)
2026-01-30 2:25 ` Wei Fang
2026-02-11 9:21 ` Michael Nazzareno Trimarchi
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=aXqLBXs0fUIVkQg_@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.felsch@pengutronix.de \
--cc=michael@amarulasolutions.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shenwei.wang@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox