On Monday, 30 of June 2008, Zhao Yakui wrote:
> On Sat, 2008-06-28 at 02:40 +0200, Rafael J. Wysocki wrote:
> > On Friday, 27 of June 2008, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rjw@xxxxxxx>
> > @@ -107,10 +113,15 @@ void acpi_disable_wakeup_device(u8 sleep
> > list_for_each_safe(node, next, &acpi_wakeup_device_list) {
> > struct acpi_device *dev =
> > container_of(node, struct acpi_device, wakeup_list);
> > + struct device *ldev;
> > + bool wakeup_enabled;
> >
> > if (!dev->wakeup.flags.valid)
> > continue;
> > - if (!dev->wakeup.state.enabled ||
> > + ldev = acpi_get_physical_device(dev->handle);
> > + wakeup_enabled = dev->wakeup.state.enabled ||
> > + (ldev ? device_may_wakeup(ldev) : false);
> > + if (!wakeup_enabled ||
> > sleep_state > (u32) dev->wakeup.sleep_state) {
> > if (dev->wakeup.flags.run_wake) {
> > spin_unlock(&acpi_device_lock);
> It seems that the device_init_wakeup(dev,1) will be called in many
> drivers regardless of userspace, which will enable the corresponding
> GPE. Maybe some laptops will be resumed immediately from the sleeping
> state.
>
> Is it more reasonable that default state is set as "wake-up disabled" in
> driver and userspace can change it from "disabled" to "enabled"?
Yes, it is, IMO.
One possible way to make it happen is to modify device_init_wakeup() so that
it always clears power.should_wakeup.
Still, that may lead to functional "regressions", ie. if we do that, some
people will have to manually write "enable" to /sys/devices/.../power/wakeup to
make their usual wake-up devices work.
Either way, there is possibility of breaking something.
Thanks,
Rafael
--
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
