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

śr., 24 cze 2020 o 11:43 Mark Brown [off-list ref] napisał(a):

On Tue, Jun 23, 2020 at 12:49:15PM -0700, Florian Fainelli wrote:

quoted

On 6/22/20 6:51 AM, Mark Brown wrote:

quoted

quoted

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.

quoted

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.

That all sounds very normal and is covered by both cases I describe?

quoted

quoted

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.

quoted

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?

Like I say I'm suggesting doing something at the device model level.

I didn't expect to open such a can of worms...

This has evolved into several new concepts being proposed vs my
use-case which is relatively simple. The former will probably take
several months of development, reviews and discussions and it will
block supporting the phy supply on pumpkin boards upstream. I would
prefer not to redo what other MAC drivers do (phy-supply property on
the MAC node, controlling it from the MAC driver itself) if we've
already established it's wrong.

Is there any compromise we could reach to add support for a basic,
common use-case of a single regulator supplying a PHY that needs
enabling before reading its ID short-term (just like we currently
support a single reset or reset-gpios property for PHYs) and
introducing a whole new concept to the device model for more advanced
(but currently mostly hypothetical) cases long-term?

Bart