linux-kernel - Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration

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: <dca54c57-a3bd-1147-63b2-4631194963f0@gmail.com>
Date:   Tue, 23 Jun 2020 12:49:15 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Mark Brown <broonie@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Yisen Zhuang <yisen.zhuang@...wei.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Iyappan Subramanian <iyappan@...amperecomputing.com>,
        Keyur Chudgar <keyur@...amperecomputing.com>,
        Quan Nguyen <quan@...amperecomputing.com>,
        Frank Rowand <frowand.list@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Liam Girdwood <lgirdwood@...il.com>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Fabien Parent <fparent@...libre.com>,
        Stephane Le Provost <stephane.leprovost@...iatek.com>,
        Pedro Tsai <pedro.tsai@...iatek.com>,
        Andrew Perepech <andrew.perepech@...iatek.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY
 registration

On 6/22/20 6:51 AM, Mark Brown wrote:
> On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote:
> 
>> The PHY subsystem cannot be the first to run into this problem, that
>> you need a device structure to make use of the regulator API, but you
>> need the regulator API to probe the device. How do other subsystems
>> work around this?
> 
> If the bus includes power management for the devices on the bus the
> controller is generally responsible for that rather than the devices,
> the devices access this via facilities provided by the bus if needed.
> If the device is enumerated by firmware prior to being physically
> enumerable then the bus will generally instantiate the device model
> device and then arrange to wait for the physical device to appear and
> get joined up with the device model device, typically in such situations
> the physical device might appear and disappear dynamically at runtime
> based on what the driver is doing anyway.

In premise there is nothing that prevents the MDIO bus from taking care
of the regulators, resets, prior to probing the PHY driver, what is
complicated here is that we do need to issue a read of the actual PHY to
know its 32-bit unique identifier and match it with an appropriate
driver. The way that we have worked around this with if you do not wish
such a hardware access to be made, is to provide an Ethernet PHY node
compatible string that encodes that 32-bit OUI directly. In premise the
same challenges exist with PCI devices/endpoints as well as USB, would
they have reset or regulator typically attached to them.

> 
>> Maybe it is time to add a lower level API to the regulator framework?
> 
> I don't see any need for that here, this is far from the only thing
> that's keyed off a struct device and having the device appear and
> disappear at runtime can make things like runtime PM look really messy
> to userspace.
> 
> We could use a pre-probe stage in the device model for hotpluggable
> buses in embedded contexts where you might need to bring things out of
> reset or power them up before they'll appear on the bus for enumeration
> but buses have mostly handled that at their level.
> 

That sounds like a better solution, are there any subsystems currently
implementing that, or would this be a generic Linux device driver model
addition that needs to be done?
-- 
Florian