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

Message-ID: <20201006080424.GA6988@pengutronix.de>
Date:   Tue, 6 Oct 2020 10:04:24 +0200
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     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>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: PHY reset question

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)

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

Regards,
Oleksij
-- 
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 |