LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: yi.y.yang@intel.com
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
lenb@kernel.org, acpi-bugzilla@lists.sourceforge.net
Subject: Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup
Date: Thu, 10 Jan 2008 09:43:08 +0200 [thread overview]
Message-ID: <200801100943.08780.maximlevitsky@gmail.com> (raw)
In-Reply-To: <1199917306.9596.3.camel@yangyi-dev.bj.intel.com>
On Thursday, 10 January 2008 00:21:46 Yi Yang wrote:
> Subject: ACPI: convert procfs to sysfs for /proc/acpi/wakeup
> From: Yi Yang <yi.y.yang@intel.com>
>
> /proc/acpi/wakeup is deprecated but it has to exist because
> we haven't a sysfs interface to replace it yet, this patch
> converts /proc/acpi/wakeup to sysfs interface, under every
> acpi device sysfs node, a user can see a directory "wakeup"
> if the acpi device can support wakeup, there are six files
> under this directory:
>
> acpi_bus_id bus_id pci_id run_wakeup sleep_state status
>
> All the files are read-only exclude "status" which is used
> to enable or disable wakeup of the acpi device.
>
> "acpi_bus_id" is acpi bus ID of the acpi device.
>
> "bus_id" is pci bus id of the device associated to the acpi
> device, it will be empty if there isn't any device associated
> to it.
>
> "pci_id" is PCI ID of the pci device associated to the acpi
> device, it will be empty if there isn't any device associated
> to it.
>
> "run_wake" is a flag indicating if a wakeup process is being
> handled.
>
> "sleep_state" is sleep state of the acpi device such as "S0".
>
> "status" is wakeup status of the acpi device, it is enabled
> or disabled, a user can change it be echoing "0", "1",
> "disabled" or "enabled" to /sys/devices/.../wakeup/status.
>
> Here is the test result:
>
> [root@localhost ~]# cat /proc/acpi/wakeup
> Device S-state Status Sysfs node PCI ID
> C093 S5 disabled pci:0000:00:1e.0 0x2448
> C0E8 S3 disabled pci:0000:00:1d.0 0x27c8
> C0EF S3 disabled pci:0000:00:1d.1 0x27c9
> C0F0 S3 disabled pci:0000:00:1d.2 0x27ca
> C0F1 S3 disabled pci:0000:00:1d.3 0x27cb
> C0F2 S3 disabled pci:0000:00:1d.7 0x27cc
> C0F9 S0 disabled pci:0000:00:1c.0 0x27d0
> C21D S0 disabled pci:0000:08:00.0 0x16fd
> C109 S5 disabled pci:0000:00:1c.1 0x27d2
> C228 S5 disabled pci:0000:10:00.0 0x4222
> C10F S5 disabled pci:0000:00:1c.3 0x27d6
> C229 S5 disabled
> [root@localhost ~]# find /sys -name "*" | grep sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:05/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0d/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:11/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:15/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:1d/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2b/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2b/device:2c/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2d/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2d/device:2e/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/wakeup/sleep_state
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/sleep_state
> [root@localhost ~]# ls /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup
> acpi_bus_id bus_id pci_id run_wakeup sleep_state status
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/acpi_bus_id
> cat: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/acpi_bus_id: No such file or directory
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/acpi_bus_id
> C229
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/sleep_state
> S5
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/status
> disabled
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/bus_id
>
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/pci_id
>
> [root@localhost ~]# echo 1 > /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/status
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/device:30/wakeup/status
> enabled
> [root@localhost ~]# cat /proc/acpi/wakeup
> Device S-state Status Sysfs node PCI ID
> C093 S5 disabled pci:0000:00:1e.0 0x2448
> C0E8 S3 disabled pci:0000:00:1d.0 0x27c8
> C0EF S3 disabled pci:0000:00:1d.1 0x27c9
> C0F0 S3 disabled pci:0000:00:1d.2 0x27ca
> C0F1 S3 disabled pci:0000:00:1d.3 0x27cb
> C0F2 S3 disabled pci:0000:00:1d.7 0x27cc
> C0F9 S0 enabled pci:0000:00:1c.0 0x27d0
> C21D S0 enabled pci:0000:08:00.0 0x16fd
> C109 S5 enabled pci:0000:00:1c.1 0x27d2
> C228 S5 enabled pci:0000:10:00.0 0x4222
> C10F S5 enabled pci:0000:00:1c.3 0x27d6
> C229 S5 enabled
> [root@localhost ~]# vi /var/log/dmesg
> [root@localhost ~]# dmesg | grep "same GPE"
> ACPI: 'C0F9' and 'C229' have the same GPE, can't disable/enable one seperately
> ACPI: 'C21D' and 'C229' have the same GPE, can't disable/enable one seperately
> ACPI: 'C109' and 'C229' have the same GPE, can't disable/enable one seperately
> ACPI: 'C228' and 'C229' have the same GPE, can't disable/enable one seperately
> ACPI: 'C10F' and 'C229' have the same GPE, can't disable/enable one seperately
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/*/wakeup/status
> disabled
> disabled
> disabled
> disabled
> disabled
> disabled
> enabled
> enabled
> enabled
> [root@localhost ~]# cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/*/*/wakeup/status
> enabled
> enabled
> enabled
> [root@localhost ~]#
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.
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.
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2008-01-10 7:43 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801100943.08780.maximlevitsky@gmail.com \
--to=maximlevitsky@gmail.com \
--cc=acpi-bugzilla@lists.sourceforge.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.y.yang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).