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
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
