devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Buday Csaba <buday.csaba@prolan.hu>
To: Rob Herring <robh@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>, <netdev@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] dt-bindings: net: mdio: add phy-id-read-needs-reset property
Date: Wed, 22 Oct 2025 08:43:47 +0200	[thread overview]
Message-ID: <aPh9IzFNZx8FD1hR@debianbuilder> (raw)
In-Reply-To: <20251021201023.GA741540-robh@kernel.org>

On Tue, Oct 21, 2025 at 03:10:23PM -0500, Rob Herring wrote:
> On Wed, Oct 15, 2025 at 03:45:02PM +0200, Buday Csaba wrote:
> > Some Ethernet PHYs require a hard reset before accessing their MDIO
> > registers. When the ID is not provided by a compatible string,
> > reading the PHY ID may fail on such devices.
> > 
> > This patch introduces a new device tree property called
> > `phy-id-read-needs-reset`, which can be used to hard reset the
> > PHY before attempting to read its ID via MDIO.
> > 
> > Signed-off-by: Buday Csaba <buday.csaba@prolan.hu>
> > ---
> >  Documentation/devicetree/bindings/net/ethernet-phy.yaml | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > index 2ec2d9fda..b570f8038 100644
> > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > @@ -215,6 +215,14 @@ properties:
> >        Delay after the reset was deasserted in microseconds. If
> >        this property is missing the delay will be skipped.
> >  
> > +  phy-id-read-needs-reset:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description:
> > +      Some PHYs require a hard reset before accessing MDIO registers.
> > +      This workaround allows auto-detection of the PHY ID in such cases.
> > +      When the PHY ID is provided with the 'compatible' string, setting
> > +      this property has no effect.
> 
> If the phy is listed in DT, then it should have a compatible. Therefore, 
> you don't need this property.
> 
> Rob
> 

Yes, it has a compatible, but most of the time it is just
"ethernet-phy-ieee802.e-c22" (or c45), and the specific ID is not provided.

Doing a quick search: of all the DTs only 126 specify a chip ID.
There are 198 matches for "ethernet-phy-ieee802.3-c22" only.

The current description reads: 
"
      - pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
        description:
          If the PHY reports an incorrect ID (or none at all) then [...]
"

This description tells me, that we are only encouraged to hardcode the 
chip ID in the DT, when it is read incorrectly.

The PHY we are having trouble with reports its ID perfectly, once properly
initialized: clock established and hard reset asserted after that.

I only wish to implement this condition. Andrew had a concern, that if we
unconditionally assert the reset, that may lead breaking compatibility with
some existing systems, so my best idea was to come up with a DT property
that can be used to flag this.

I also wish to emphasize: there are 43 DTs out there still using the
deprecated "phy-reset-gpios" property of the fec driver, probably for the
same reason: there is no replacement for it. Because that property does
reset the PHY before the ID read, but it has all kind of other problems.
The worst is that reset gpio handle is tossed after the initialization,
see fec_reset_phy().

If we ever want to truly deprecate that, there must be some alternative
logic to implement the same funcionality.

Csaba


  reply	other threads:[~2025-10-22  6:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 13:45 [PATCH v2 1/4] net: mdio: common handling of phy reset properties Buday Csaba
2025-10-15 13:45 ` [PATCH v2 2/4] net: mdio: change property read from fwnode_property_read_u32() to device_property_read_u32() Buday Csaba
2025-10-15 13:45 ` [PATCH v2 3/4] dt-bindings: net: mdio: add phy-id-read-needs-reset property Buday Csaba
2025-10-21 20:10   ` Rob Herring
2025-10-22  6:43     ` Buday Csaba [this message]
2025-10-22  9:15     ` Buday Csaba
2025-10-15 13:45 ` [PATCH v2 4/4] net: mdio: reset PHY before attempting to access registers in fwnode_mdiobus_register_phy Buday Csaba
2025-10-15 17:04   ` Simon Horman
2025-10-16  5:20   ` kernel test robot
2025-10-17  7:33   ` Buday Csaba
2025-10-17 14:40     ` Andrew Lunn
2025-10-15 14:02 ` [PATCH v2 1/4] net: mdio: common handling of phy reset properties Buday Csaba

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=aPh9IzFNZx8FD1hR@debianbuilder \
    --to=buday.csaba@prolan.hu \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).