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

On 2020-06-24 17:50, Russell King - ARM Linux admin wrote:

On Wed, Jun 24, 2020 at 09:06:28AM -0700, Florian Fainelli wrote:

quoted

On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote:

quoted

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.

You are not new to Linux development, so none of this should come as a
surprise to you. Your proposed solution has clearly short comings and is
a hack, especially around the PHY_ID_NONE business to get a phy_device
only then to have the real PHY device ID. You should also now that "I
need it now because my product deliverable depends on it" has never been
received as a valid argument to coerce people into accepting a solution
for which there are at review time known deficiencies to the proposed
approach.

It /is/ a generic issue.  The same problem exists for AMBA Primecell
devices, and that code has an internal deferred device list that it
manages.  See drivers/amba/bus.c, amba_deferred_retry_func(),
amba_device_try_add(), and amba_device_add().

As we see more devices gain this property, it needs to be addressed
in a generic way, rather than coming up with multiple bus specific
implementations.

Maybe struct bus_type needs a method to do the preparation to add
a device (such as reading IDs etc), which is called by device_add().
If that method returns -EPROBE_DEFER, the device gets added to a
deferred list, which gets retried when drivers are successfully
probed.  Possible maybe?

FWIW that would be ideal for solving an ordering a problem we have in 
the IOMMU subsystem too (which we currently sort-of-handle by deferring 
driver probe from dma_configure(), but it really needs to be done 
earlier and not depend on drivers being present at all).

Robin.