linux-kernel - Re: PHY reset question

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]

Date:   Tue, 6 Oct 2020 12:36:20 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Andrew Lunn <andrew@...n.ch>
Cc:     David Jander <david@...tonic.nl>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Russell King <linux@...linux.org.uk>, mkl@...gutronix.de,
        Marek Vasut <marex@...x.de>
Subject: Re: PHY reset question



On 10/6/2020 1:04 AM, Oleksij Rempel wrote:
> Hello PHY experts,
> 
> Short version:
> what is the proper way to handle the PHY reset before identifying PHY?
> 
> Long version:
> I stumbled over following issue:
> If PHY reset is registered within PHY node. Then, sometimes,  we will not be
> able to identify it (read PHY ID), because PHY is under reset.
> 
> mdio {
> 	compatible = "virtual,mdio-gpio";
> 
> 	[...]
> 
> 	/* Microchip KSZ8081 */
> 	usbeth_phy: ethernet-phy@3 {
> 		reg = <0x3>;
> 
> 		interrupts-extended = <&gpio5 12 IRQ_TYPE_LEVEL_LOW>;
> 		reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
> 		reset-assert-us = <500>;
> 		reset-deassert-us = <1000>;
> 	};
> 
> 	[...]
> };
> 
> On simple boards with one PHY per MDIO bus, it is easy to workaround by using
> phy-reset-gpios withing MAC node (illustrated in below DT example), instead of
> using reset-gpios within PHY node (see above DT example).
> 
> &fec {
> 	[...]
> 	phy-mode = "rmii";
> 	phy-reset-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
> 	[...]
> };
> 
> On boards with multiple PHYs (for example attached to a switch) and separate
> reset lines to each PHY, it becomes more challenging. In my case, after power
> cycle the system is working as expected:
> - pinmux is configured to GPIO mode with internal pull-up
> - GPIO is by default in input state. So the internal pull-up will automatically
>    dessert the PHY reset.
> 
> On reboot, the system will assert the reset. GPIO configuration will survive the
> reboot and PHYs will stay in the reset state, and not detected by the system.
> 
> So far I have following options/workarounds:
> - do all needed configurations in the bootloader.
>    Disadvantage:
>    - not clear at which init level it should be done?
>      1. Boot ROM script (in case of iMX). One fix per each board. Ease to forget.
>      2. Pre bootloader. Same as 1.
>      3. GPIO driver in the bootloader. What if some configuration was done in
>         1. or 2.?
>    - we will go back to the same problem if we jumped to Kexec
> 
> - Use compatible ("compatible = "ethernet-phy-id0022.1560") in the devicetree,
>    so that reading the PHYID is not needed
>    - easy to solve.
>    Disadvantage:
>    - losing PHY auto-detection capability
>    - need a new devicetree if different PHY is used (for example in different
>      board revision)

Or you can punt that to the boot loader to be able to tell the 
difference and populate different compatible, or even manage the PHY 
reset to be able to read the actual PHY OUI. To me that is still the 
best solution around.

> 
> - modify PHY framework to deassert reset before identifying the PHY.
>    Disadvantages?

The disadvantages would be that you would have to use 
__of_reset_control_get() against the PHY device tree node because there 
are no phy_device being created yet because you have not been able to 
identify it. Given that there are people working on the ACPIzation of 
the PHY framework, that would be a set back.
-- 
Florian