Re: Trying to understand new wakeup events architecture

Alan Stern
2011-01-13T16:55:44Z

On Thu, 13 Jan 2011, Daniel Drake wrote:

> On Thu, 2011-01-13 at 10:14 -0500, Alan Stern wrote:
> > On Thu, 13 Jan 2011, Daniel Drake wrote:
> >
> > > As for contents, it will read back a string. One of:
> > >
> > > rtc alarm
> > > power button
> > > lid
> > > key press
> > > battery
> > > battery state changed
> > > battery error
> > > ebook
> > > wlan packet
> > > ac power
> > > battery critical
> > > gp timer
> > > hda
> > > usb
> > > unknown
> >
> > Wouldn't it be better to read back a device pathname when the wakeup
> > source can be identified as a particular device? Whoever uses this
> > field should be responsible for converting it to one of those more
> > generic forms.
>
> It could be done, but might be ugly. The problem is that those
> individual devices don't really know that they were woken up. It's done
> by OLPC's EC driver. So the EC driver would have to either hardcode
> device paths, or have a load of device-hunting code.
>
> Another small problem is that it doesn't encode the difference between
> "battery state changed" and "battery error", for example.
>
> If it's really disliked as a string, perhaps it would be OK just to
> stash it within the sysfs directory of our device, not polluting the
> global namespace.
>
> I'm hoping this can all be a temporary measure anyway, as future closer
> integration with Rafael's wakeup events architecture plus the ability
> for that architecture to export wakeup source info should make it go
> away.

You can do whatever is best for you on the OLPC platform; I was just
offering a suggestion.

Alan Stern