On Fri, 30 Nov 2012, "Andy Green (林安廸)" wrote: > I have everything discussed above ready for a try#2, including the > descendant matching stuff in separate patches. The code got a lot > smaller and better with the _ops struct. > > The new code can attach the assets to the targeted hub port as discussed > (using only "-0:1.0/port1" and only checking ehci-omap.0 descendants at > device_add() time), but the hub port device never probes, unless I > missed the point it's because it actually never binds to a driver, it's > a very unusual standalone logical device. That's right; it gets registered but it never binds. It doesn't need a driver because all the port-related activity is done by the hub driver. > If that's the case I could work around that by doing the probe() asset > stuff at device_add() time if there's no driver name on the device, but > actually I am not sure that's where we wanted to end up. > > Now we got so far as to succeed to associate regulator + clock assets to > the logical hub port device, isn't it that we want the assets to be > enabled and disabled according to hub port power state? In that case it > needs to go in the direction of calling device_asset helpers in the > hub.c code that handles enable and disable hub port power. Is this > sounding like the right way, or something else? I'm not so sure about this. Maybe we're trying to solve too many different kinds of problem at once. The original device asset scheme is fine if all you want to do is turn on the regulator when ehci-omap binds and turn it off when the driver unbinds. But if we want to go farther, maybe the device asset approach isn't the right way. In particular, we would like the regulator to get turned off and on by the port driver as part of its suspend/resume handling. The most straightforward way to do this is to modify the PM code in port.c. This would be specific to USB ports. I toyed around with the idea of a more general-purpose approach using "PM assets" that could hook into various PM callbacks, but it seemed to get too complicated. And besides, it only ended up looking like a way to put something into a PM domain without the driver's knowledge. So maybe something like Ming Lei's suggestion really would be best. We could add code specifically for regulators and clocks to port.c. Trying to write something that can work for all types of devices, not just USB ports, may be over-reaching. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
