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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <885abb40-cf1c-b464-bf09-08c7235410ef@gmail.com>
Date:   Thu, 3 Sep 2020 14:50:05 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, Rob Herring <robh+dt@...nel.org>
Cc:     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 9/3/2020 2:42 PM, Andrew Lunn wrote:
> 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?

For MDIO since we have a fixed number of devices on the bus, we could 
pre-populate the MDIO map for all addresses, and free up the devices 
that we did not probe.

When using DT we can first parse the address, create a mdio_device 
there, and then turn on clocks/regulators/GPIOs whatever since we now 
have a device reference. Only then do we bind the device with its driver.

If we are using the DT scanning loop because the node did not provide a 
"reg" property, then the PHY must be in a functional state to be probed, 
we cannot guess what we do not know.

All of this uses MDIO implementation knowledge though.

> 
>> 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
> 

-- 
Florian