netdev - 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-next>] [day] [month] [year] [list]

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

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. With the above
in one way or the other we end up in of_mdiobus_register_phy() where we
have:

        if (!is_c45 && !of_get_phy_id(child, &phy_id))
                phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
        else
                phy = get_phy_device(mdio, addr, is_c45);

get_phy_device() tries to read the phy_id from the MDIO bus.
Unfortunately the "reset-gpios" property is only handled later in
phy_device_register(), so it can only work when the bootloader has left
the reset GPIO deasserted.  Note it works when of_get_phy_id() returns
the phy_id, which is the case when the phy_id is explicitly given with
"ethernet-phy-idxxxx.yyyy", but giving the exact phy_id shouldn't be
mandatory, right?

I think the phy_id is unknown at phy_device_create() time, so I looked
into removing the phy_id argument there and specifying it elsewhere,
maybe by adding a phy_device_set_id() function. Another point is that
phy_device_create() currently calls phy_request_driver_module() to get
the driver modules for a given phy_id. That would have to be called
later as well. Is this the path to go or are there any other ideas how
to solve this issue?

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 |