LKML Archive on
help / color / mirror / Atom feed
From: Thomas Renninger <>
Cc: Zhang Rui <>,
	Maxim Levitsky <>,,,,,,
	Holger Macht <>
Subject: Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup
Date: Wed, 19 Mar 2008 14:06:22 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 2008-01-11 at 07:55 +0800, Yi Yang wrote:
> > > 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
> > and David's patch set here:
> >
> >
> > You can have a look at this thread as well:
> >
> > 
> 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. 

Any news on this?
I ran into a problem with the current implementation:

If one GPE is tight to several devices you get a message:
echo XYZ >/tmp/acpi/wakeup
ACPI: 'XXX' and 'XYZ' have the same GPE, can't disable/enable one
ACPI: 'YYY' and 'XYZ' have the same GPE, can't disable/enable one
and none of the devices are activated to be able to wake the machine up.
Which I expect is wrong, all should be enabled/disabled then IMO, but
it's probably not worth much fixing in /proc/acpi/...

The correct interface to use seem to be:
But this is rather broken?
Here an output of /proc/acpi/wakeup and /sys/...:
for x in `find /sys/ |grep wakeup`;do if [ $(cat $x) ];then echo $x; cat $x;fi;done
trenn@stravinsky:/extern/trenn/packages/home:trenn> cat /proc/acpi/wakeup 
Device  S-state   Status   Sysfs node
PCI0      S5     disabled  no-bus:pci0000:00

I still think (from comments in drivers/base/power/sysfs.c, not sure
whether it really is that appropriate) it is wakeup sysfs file that
should be used for this.
I wonder why each device has a wakeup file, it should be enough to
create them dynamically if wakeup enable/disable is supported for a
specific device?
Also a second file is missing from which state (S3,S4,S5) the device can
wake the machine up.

If there can be multiple devices for one GPE, this information (the
power directory of multiple devices) could be linked together in sysfs?
is a link to:
If both are using one wake-up GPE.

Also if the ACPI device caught through acpi_get_physical device is a PCI
bridge, it should get evaluated what is behind the bridge and this
device (e.g. a network card) should get the wakeup stuff set up, not the

Does someone still look at this?
If not, shall I or is it on some queue?
Should this be discussed a bit more detailed first?


  reply	other threads:[~2008-03-19 22:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-27  6:47 [PATCH linux-acpi] Fix /proc/acpi/alarm set error Yi Yang
2007-12-27  8:41 ` [PATCH linux-acpi] Remove superfluous code and correct counting error in function acpi_system_write_alarm Yi Yang
2007-12-29  8:22   ` [PATCH linux-acpi] Correct wakeup set error and append a new column PCI ID Yi Yang
2008-01-01 23:20     ` Pavel Machek
2008-01-02  2:03       ` Yi Yang
2008-01-02 16:09         ` Pavel Machek
2008-01-03  2:02           ` Yi Yang
2008-01-03  2:11           ` Yi Yang
2008-01-04  8:16     ` [PATCH linux-acpi] fix acpi fan state set error Yi Yang
2008-01-07  6:56       ` [PATCH] ACPI: fix processor throttling " Yi Yang
2008-01-08  3:21         ` [PATCH] ACPI: fix processor limit " Yi Yang
2008-01-24  0:45           ` [PATCH] ACPI: create proc entry 'power' only if C2 or C3 is supported Yi Yang
2008-01-24 14:43             ` Mark Lord
2008-01-09 22:21         ` [PATCH] ACPI: Add sysfs interface for acpi device wakeup Yi Yang
2008-01-10  7:43           ` Maxim Levitsky
2008-01-09 23:59             ` Yi Yang
2008-01-10 10:30               ` Matthew Garrett
2008-01-13 18:16               ` Pavel Machek
2008-01-11  8:16             ` Zhang Rui
2008-01-10 23:55               ` Yi Yang
2008-03-19 13:06                 ` Thomas Renninger [this message]
2008-03-19 14:37                   ` Yi Yang
2008-03-20  4:32                     ` Zhao Yakui
2008-03-19 18:52                   ` David Brownell
2008-03-20  5:12                     ` Zhao Yakui
2008-03-20  6:12                       ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).