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

[Robin Murphy]

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:
> > On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote:
> > > 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.