From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
kernel@pengutronix.de
Subject: Re: ethernet-phy-ieee802.3-c22 binding and reset-gpios
Date: Wed, 26 Aug 2020 10:58:57 +0200 [thread overview]
Message-ID: <20200826085857.GO13023@pengutronix.de> (raw)
In-Reply-To: <20200825131400.GO2588906@lunn.ch>
Hi Andrew,
On Tue, Aug 25, 2020 at 03:14:00PM +0200, Andrew Lunn wrote:
> On Tue, Aug 25, 2020 at 11:09:33AM +0200, Sascha Hauer wrote:
> > Hi All,
> >
> > I am using the ethernet phy binding here that looks like:
> >
> > ethphy1: ethernet-phy@1 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > reg = <1>;
> > eee-broken-1000t;
> > reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
> > };
> >
> > It seems the "reset-gpios" is inherently broken in Linux.
>
> Hi Sascha
>
> I think it would be better to say, it does not do what people expect,
> rather than broken.
>
> This code was developed for a PHY which needed to be reset after
> enumeration. That PHY did enumerate, either because it was not held in
> reset, or would still answer ID requests while held in reset.
>
> It does however not work for PHYs which are held in reset during probe
> and won't enumerate. This is a known issues, but could be better
> documented.
I think the behaviour should rather be improved than documented.
>
> > Is this the path to go or are there any other ideas how to solve
> > this issue?
>
> There is two different reset gpios in DT. There is a per PHY reset,
> which you are trying to use. And a per MDIO bus reset, which should
> apply to all PHYs on the bus. This per bus reset works more as
> expected. If this works for you, you could use that.
Well there is only one phy connected to the bus, so it makes no
difference if I say the reset GPIO is for the whole bus or for a single
phy only. The per bus reset should work, but currently it doesn't. First
reason I found out that mdiobus_register() doesn't handle -EPROBE_DEFER
returned by the devm_gpiod_get_optional() properly, patch follows.
Second reason is that the phy is not detected (id read returns 0xffff)
when the reset is attached to the bus. So far I haven't found the reason
for that.
>
> Otherwise, you need to modify of_mdiobus_register() to look in device
> tree while it is performing the scan and see if there is a reset
> property for each address on the bus. If so, take the device out of
> reset before reading the ID registers.
Ok.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2020-08-26 8:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 9:09 ethernet-phy-ieee802.3-c22 binding and reset-gpios Sascha Hauer
2020-08-25 13:14 ` Andrew Lunn
2020-08-26 8:58 ` Sascha Hauer [this message]
2020-08-26 12:56 ` Andrew Lunn
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=20200826085857.GO13023@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=netdev@vger.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).