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? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
