netdev - Re: [PATCH net-next 1/3] net: phy: Support enabling clocks prior to bus probe

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200903214238.GF3112546@lunn.ch>
Date:   Thu, 3 Sep 2020 23:42:38 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>, adam.rudzinski@....net.pl,
        Marco Felsch <m.felsch@...gutronix.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Richard Leitner <richard.leitner@...data.com>,
        Dejin Zheng <zhengdejin5@...il.com>,
        devicetree@...r.kernel.org, Sascha Hauer <kernel@...gutronix.de>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 1/3] net: phy: Support enabling clocks prior to
 bus probe

On Thu, Sep 03, 2020 at 03:28:22PM -0600, Rob Herring wrote:
> What if a device requires clocks enabled in a certain order or timing?
> It's not just clocks, you could have some GPIOs or a regulator that
> need enabling first. It's device specific, so really needs a per
> device solution. This is not just an issue with MDIO. I think we
> really need some sort of pre-probe hook in the driver model in order
> to do any non-discoverable init for discoverable buses.

Hi Rob

How do you solve the chicken/egg of knowing what device specific init
is needed before you can discover what device you have on the bus?

> Or perhaps forcing probe when there are devices defined in DT if
> they're not discovered by normal means.

The PHY subsystem has this. You came specify in DT the ID of the
device which we would normally read during bus discovery. The correct
driver is then loaded and probed. But it is good practice to avoid
this. OEMs are known to change the PHY in order to perform cost
optimisation. So we prefer to do discover and do the right thing if
the PHY has changed.

As for GPIOS and regulators, i expect this code will expand pretty
soon after being merged to handle those. There are users wanting
it. We already have some standard properties defined, in terms of
gpios, delay while off, delay after turning it on. As for ordering, i
guess it would make sense to enable the clocks and then hit it with a
reset? If there is a device which cannot be handled like this, it can
always hard code its ID in device tree, and fully control its
resources in the driver.

	  Andrew