On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote: > I don't see the point of all this. Obviously the device can't be used > until it physically appears on the bus. What benefit do you get from > registering it and making it available to userspace before that? Two things. One is that some devices have the ability to perform useful functions when powered down sufficiently that they can't run a complex bus, providing notification when they need to wake up (or being woken up if the power on comes from userspace). The other is that then userspace can just see the device and start using it when it needs it without having to have a mechanism to discover that there's something there with manual power control. This can also be an issue in cases where we compose multiple physical devices into composite ones for userspace (embedded audio and video do this a lot for example). A given bit of hardware may only be useful in some circumstances. > Well, basic "power this on" stuff is pretty much all we have discussed > in this thread so far. What other sorts of things are going to be > needed for a general solution? If you look elsewhere at the stuff I've been saying about Slimbus that's the nastiest case I'm aware of in terms of the bus itself - that's got the devices with low power modes that do useful things with the device (and bus) mostly powered off and things like that. Things like activity detection of various kinds where the device is monitoring for activity in a low power state. I've also mentioned the devices that need platform data which is a part of this too; one reason for knowing that the device is there before it appears is so that we can pass platform data/DT/whatever to it. > Now I'm getting confused. It seems we're talking about at least three > very different things here: > A: Devising a mechanism for platform code to do things involving > devices that are dynamically registered on discoverable buses. If we need random platform code then we're failing, half the point of things like DT and ACPI is to avoid writing random board code. we do want to pass data to devices for their drivers to use but having to have random bits of per board code would be really sad. > B: Telling the subsystem and driver code for a discoverable bus > that a particular device is present before it has been > detected. > C: Implementing a mechanism whereby drivers can take a device > off-line while still pretending to userspace that the device > is still present, by bringing it back on-line as needed. > I don't see much connection between these things. Perhaps you can > explain in more detail. I think the solutions for these overlap so much they're the same thing. The situation we're in in in your case B is just the idle case for condition C - if we know about the device before it's been detected then if it's been removed we just go back into the situation where we know about it but it isn't powered. > (BTW, it's worth mentioning that C has already been done, in the form > of runtime PM. The difference may be that you propose to take the > device so far off-line that it disappears from the bus. AFAICS, this > would be purely a private matter to be arranged between the subsystem > and the driver; it does not need to be handled at the level of the > device-model or PM core.) Actually runtime PM is actually already used for completely offlining devices on buses that are too blind to notice - it's only an issue on buses that can notice insertion and removal and want to do something about it. The use cases I'm describing already happen in mainline today for devices on the dumber buses. I think if we've got something which the hardware engineers can do on multiple buses then they probably will so we should have at least a pattern for how it's going to work over multiple buses rather than having to handle different models for different buses. I'll try to have a think about what that pattern might be at some point (in my copious free time).
Attachment:
signature.asc
Description: Digital signature
