public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Jens Emil Schulz Ostergaard
	<jensemil.schulzostergaard@microchip.com>,
	Andrew Lunn <andrew@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	o.rempel@pengutronix.de,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	Daniel Machon <daniel.machon@microchip.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] net: phy: micrel: Add support for lan9645x internal phy
Date: Fri, 20 Feb 2026 21:49:21 +0000	[thread overview]
Message-ID: <aZjW4dXiSepPNHQ1@shell.armlinux.org.uk> (raw)
In-Reply-To: <4674c965-f4d1-4ba9-9e36-9d3bbbb37f64@gmail.com>

On Fri, Feb 20, 2026 at 10:30:36PM +0100, Heiner Kallweit wrote:
> On 20.02.2026 22:10, Russell King (Oracle) wrote:
> > On Fri, Feb 20, 2026 at 09:50:44PM +0100, Heiner Kallweit wrote:
> >> No, BMCR_RESET usually doesn't reset configuration registers. That's why the
> >> function is called genphy_*soft*_reset. In case your PHY behaves different,
> >> which configuration registers does it change?
> > 
> > I don't think your statement is correct.
> > 
> > Looking at AR8035 for example, the WoL interrupt enable is doumented as
> > being cleared on soft reset. Smart Speed configuration also gets reset.
> > 
> > 802.3 22.2.4.1.1 states that setting 0.15 results in the status and
> > control registers shall be set to their default states.
> > 
> > So, we should not assume that setting 0.15 will retain configuration in
> > the PHY - at least phylib should not assume that a call to
> > genphy_soft_reset will not clear the configuration registers. If we
> > have code in phylib that makes that assumption, phylib is buggy to
> > 802.3.
> > 
> 
> Indeed I was wondering why c22 states "reset control registers"
> whilst the PHY's I'm dealing with don't do this. At least for the
> Marvell PHY's I used the spec says "resets PHY state machine".
> For Realtek the spec statement was "resets BMCR and BMSR".
> And often config bits are described as "becomes effective after
> reset". But yes, there may be PHY's implementing exactly the c22
> behavior, so we shouldn't rely on "soft" in general.

Looking at LAN8841
(https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8841-Data-Sheet-00004726A.pdf)
this states:

5.28.1 SOFTWARE RESET
The Gigabit Ethernet PHY may be reset by software by using the IEEE
802.3 standard PHY Soft Reset (RESET) bit in the Basic Control
Register. This resets all the PHY and all its registers to their
default state, with the following exceptions.

(none mention standard 802.3 registers)

An additional software reset is available by using the bit Software
Reset bit in the Control Register. This resets all of the PHY except
for its registers.

So, setting 0.15 will be disruptive to the control registers on this
PHY. Register definitions can be found at:
https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ApplicationNotes/ApplicationNotes/AN4783-LAN8841-Register-Definitions-Application-Note-DS00004783A.pdf

Bit 1 of register 31 resets the PHY without clearing the registers.

As one of their PHYs behaves like this, I suspect it'll be common
amongst their LAN PHYs. The KSZ PHYs seem to either be more like
Marvell, or maybe the documentation isn't clear enough.

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

  reply	other threads:[~2026-02-20 21:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30  9:12 [PATCH net-next v2] net: phy: micrel: Add support for lan9645x internal phy Jens Emil Schulz Østergaard
2026-01-31  6:29 ` Jens Emil Schulz Ostergaard
2026-01-31 10:00   ` Heiner Kallweit
2026-02-20 20:38     ` Jens Emil Schulz Ostergaard
2026-02-20 20:50       ` Heiner Kallweit
2026-02-20 21:10         ` Russell King (Oracle)
2026-02-20 21:22           ` Andrew Lunn
2026-02-20 21:30           ` Heiner Kallweit
2026-02-20 21:49             ` Russell King (Oracle) [this message]
2026-02-25 12:35         ` Jens Emil Schulz Ostergaard
2026-02-25 13:39           ` Andrew Lunn
2026-02-25 20:57             ` Jens Emil Schulz Ostergaard

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=aZjW4dXiSepPNHQ1@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=Steen.Hegelund@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=jensemil.schulzostergaard@microchip.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.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