śr., 24 cze 2020 o 11:43 Mark Brown <broonie@xxxxxxxxxx> napisał(a): > > On Tue, Jun 23, 2020 at 12:49:15PM -0700, Florian Fainelli wrote: > > On 6/22/20 6:51 AM, Mark Brown wrote: > > > > 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. > > That all sounds very normal and is covered by both cases I describe? > > > > 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? > > 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
