On Sun, May 08, 2005 at 05:24:09PM -0700, David Brownell wrote: > This is a refresh of a patch I sent before. I suspect it'd be > appropriate to merge this, given the agreement I thought I > heard last time I posted it. > > Follow-on patches would update other subsystems to use this: > > * USB, replacing existing HCD support, when activating > configurations that support remote wakeup, and when > deciding whether to activate remote wakeup for a device > as it's being suspended; > > * ACPI, since there's a table flagging devices that can > support wakeup, and that info is basically invisible > to the drivers for those devices (unless the device > also supports PCI PM); > > * Networking, where I suspect the "ethtool" commands to > set wake-on-LAN should update the "may_wakeup" bit > > * ... and surely more; this after all only affects the > policy applying to a device wakeup, it doesn't do > anything to have wakeup actually work on the hardware. > > The main thing I dislike about this patch is that it always > creates the sysfs attribute, even for devices for which it's > meaningful. That should be fixable by just adding the > attributes one-at-a-time. > > - Dave I actually was working on a similar patch, but decided to stop. I have some concerns about the generic-ness of "wakeup". For example, some devices may have multiple wakeup modes or wakeup criteria. Under these situations having a global "wakeup" parameter might become clumsy. So should drivers be exporting these sort of things on their own? "Wake-on-lan", as an example, could have 4 or 5 different packet types to look for. So when the user specifies one of these, he or she is expecting "wake-on-lan" to just work. In the case of your patch, I think the sysfs attribute would also need to be configured. "wakeup" seems to fit most ACPI and PCI devices well. I'm not sure how it would apply to usb, firewire, pcmcia, etc., especially when determining if it supports wake. It may just be something that only the driver knows. A few more points: Wakeup configuration may vary between system states, how can we account for this? Should wakeup information be reconfigured by userspace before entering a sleep or off state? Would there be any value in exporting a list of system states in which wake is supported on a per-device basis? > This is a refresh of an earlier patch to add "wakeup" support to > to the PM-core model: > > * struct device_pm_info has two bits that are initialized as > part of setting up the enclosing struct device: > - "can_wakeup", reflecting system hardware capabilities > - "may_wakeup", the policy setting (when CONFIG_PM) > > * there's a writeable sysfs "wakeup" file, with one of three values: > - "enabled", when the policy is to allow wakeup > - "disabled", when the policy is not to allow it > - "" (empty string), when the hardware doesn't support wakeup > > * this patch includes support to initialize these bits for devices > that support PCI PM. > > It would be preferable to not have the attribute for devices that aren't > wired with wakeup support, but that'd involve extra sysfs magic. This probably isn't too difficult. The question is how consistent we want the interface to be. Thanks, Adam
