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: <Y8QzI2VUY6//uBa/@lunn.ch>
Date:   Sun, 15 Jan 2023 18:08:51 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Pierluigi Passaro <pierluigi.passaro@...il.com>
Cc:     hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        eran.m@...iscite.com, nate.d@...iscite.com,
        francesco.f@...iscite.com, pierluigi.p@...iscite.com
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal

On Sun, Jan 15, 2023 at 05:10:06PM +0100, Pierluigi Passaro wrote:
> When the reset gpio is defined within the node of the device tree
> describing the PHY, the reset is initialized and managed only after
> calling the fwnode_mdiobus_phy_device_register function.
> However, before calling it, the MDIO communication is checked by the
> get_phy_device function.
> When this happen and the reset GPIO was somehow previously set down,
> the get_phy_device function fails, preventing the PHY detection.
> These changes force the deassert of the MDIO reset signal before
> checking the MDIO channel.
> The PHY may require a minimum deassert time before being responsive:
> use a reasonable sleep time after forcing the deassert of the MDIO
> reset signal.
> Once done, free the gpio descriptor to allow managing it later.

This has been discussed before. The problem is, it is not just a reset
GPIO. There could also be a clock which needs turning on, a regulator,
and/or a linux reset controller. And what order do you turn these on?

The conclusions of the discussion is you assume the device cannot be
found by enumeration, and you put the ID in the compatible. That is
enough to get the driver to load, and the driver can then turn
everything on in the correct order, with the correct delays, etc.

I think there has been some work on generic power sequencing. I've not
being following it, so i've no idea how far it has got. If that could
be used to solve this problem for all the possible controls of a PHY,
i would be open for such patches.

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ