> > > I think that it would be much much better to place wake-up attributes under
> > > corresponding PCI and PNP devices.
> > > Probably it is even better to link this code to PCI code, so PCI drivers will be aware of ACPI.
> > I like this idea, maxim. :)
> > And that's what we actually did about half a year ago.
> >
> > Yi,
> > Please refer to
http://bugzilla.kernel.org/show_bug.cgi?id=6892
> > and David's patch set here:
> >
http://marc.info/?l=linux-mm-commits&m=117701595209299&w=2
> >
http://marc.info/?l=linux-mm-commits&m=117701866524935&w=2
> > You can have a look at this thread as well:
> >
http://marc.info/?l=linux-acpi&m=119982937409968&w=2
> >
> I checked those patches you mentioned, they did bind two wakeup flag to
> some extent, but they can't be exchanged to use and they are just partly
> in current linus tree, two flags bind isn't in linus tree.
>
> According to my test on the latest linus tree, wakeup flag of
> acpi_device hasn't any association with device's, i don't know if they
> are the same thing. if we enbale or disable it manually, what will
> happen? From source code, it is just a flag, it doesn't trigger any
> event or hardware operation.
>
> > thanks,
> > Rui
> > > For example it will fix the 'EHCI instantly wakes up the system from S4' on my system, since here USB doesn't wake
> > > up anything from S4, and ACPI tables correctly show that.
> > >
> > > If ehci driver was aware of that it could disable #PME on entrance to S4.
> > > And we even can reuse its 'wakeup' attribute, thus enabling wakeup automatically.
> > >
> > > Going ever further, I think that it will be great to get rid of ACPI device tree, since
> > > most acpi devices are ether PCI of PNP ones.
> > >
> > > Or, even better have a small ACPI tree, that will contain 'true' ACPI devices, like cpus
> > > thermal sensors, buttons, etc.
