Power Mangement Interfaces

[Jens Axboe]

On Tue, Jun 19 2007, Marcelo Tosatti wrote:
> > > > I see /sys/devices/acpi_system:00/button_power:00 on this system; and
> > > > /sys/devices/acpi_system:00/device:00/PNP0C0D:00 has path \_SB_.LID_ ...
> > > > such device nodes already exist, even though they're not really hooked
> > > > up to anything much.  Notably, their "wakeup" state is not initialized.
> > > > 
> > > > And while it seems that the three USB controllers on this system show up
> > > > as /sys/devices/acpi_system:00/device:00/PNP0A03:00/device:{01,02,03} I
> > > > have no idea which one is /sys/devices/pci0000:00/0000:00:02.2 versus
> > > > 0000:00:02.1 or 0000:00:02.0 ... I know that USB0 is device:01 and so
> > > > on (by reading "path"), but associating one with a PCI device seems to
> > > > involve pure guesswork.
> > > 
> > > I guess we'll probably have to do something similar for our OLPC PM code
> > > - but thats the sort of platform specific fragmentation thing I was trying
> > > to avoid.
> > 
> > Since OLPC isn't using ACPI,  it can be more like embedded Linux,
> > and just Do The Right Thing ... create platform devices, etc.  :)
> 
> As you know we want user configuration of enabled wakeup events (unlike
> embedded platforms where this is hardcoded). It seems that the current
> interface available for that is /sys/devices/../power/wakeup hook (when
> !ACPI).
> 
> However there are several wakeup capable devices in OLPC which do not
> have drivers, thus no platform devices:
> 
> - power button 
> - lid
> 
> It seems that creating platform devices for these two just for the
> purpose of a having an interface for enabling wakeup events is overkill.

I'll go ahead and disagree with that, I think a platform device is
clearly the best way to go. It's the cleanest approach.

-- 
Jens Axboe