netdev - Re: ethernet-phy-ieee802.3-c22 binding and reset-gpios

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200825131400.GO2588906@lunn.ch>
Date:   Tue, 25 Aug 2020 15:14:00 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Sascha Hauer <s.hauer@...gutronix.de>
Cc:     netdev@...r.kernel.org, Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>, kernel@...gutronix.de
Subject: Re: ethernet-phy-ieee802.3-c22 binding and reset-gpios

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.

> 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.

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.

	Andrew