From: Matthew Garrett <mjg59@srcf.ucam.org>
To: David Brownell <david-b@pacbell.net>
Cc: linux-pm@lists.osdl.org, Zhang Rui <rui.zhang@intel.com>,
lenb@kernel.org, "linux-acpi@vger" <linux-acpi@vger.kernel.org>,
linux-pm@osdl.org
Subject: Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs
Date: Sun, 7 Jan 2007 05:54:24 +0000 [thread overview]
Message-ID: <20070107055424.GA24853@srcf.ucam.org> (raw)
In-Reply-To: <200701061421.41342.david-b@pacbell.net>
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
> Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> attribute. And that ACPI is finally going to start working with those
> attributes ...
It's not necessarily possible to map from an ACPI object with a wakeup
capability to a Linux device, so there's going to have to be some degree
of interface nastiness. However, some devices can be sensibly mapped,
and ideally those should be integrated into
/sys/devices/.../power/wakeup.
However, I'm not entirely sure /how/ that integration should happen. If
both the Linux driver and ACPI know how to enable wakeup for a device,
what should writing to power/wakeup do?
> > So /proc/acpi/wakeup is deprecated by
> > /sys/devices/acpi_system/.../xxx/sleep_state && wakeup.
>
> Why is ACPI still not coupling such information to the REAL device
> nodes? On my laptop, right now without any wakeup-capable USB
> devices attached, the appended script produces:
So for example, the PCI0 device on my Thinkpad is an ACPI wakeup device.
Investigating the DSDT suggests that this is just a wrapper around a
bunch of platform devices, including the ISA bridge. In this case, what
real device should we be associating it with?
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2007-01-07 5:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-06 11:35 [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs Zhang Rui
2007-01-06 22:21 ` David Brownell
2007-01-07 5:54 ` Matthew Garrett [this message]
2007-01-08 3:31 ` [linux-pm] " David Brownell
2007-01-08 13:10 ` Pavel Machek
2007-01-25 4:14 ` Len Brown
2007-01-25 5:50 ` Matthew Garrett
2007-01-25 9:35 ` David Brownell
2007-01-08 11:40 ` Zhang Rui
2007-01-08 13:13 ` Pavel Machek
2007-01-25 2:28 ` Len Brown
2007-01-25 12:08 ` Pavel Machek
2007-01-25 13:15 ` David Brownell
2007-01-25 19:51 ` Pavel Machek
2007-01-26 1:36 ` Zhang Rui
2007-01-10 20:53 ` David Brownell
2007-01-25 4:17 ` Len Brown
2007-01-25 13:15 ` Pavel Machek
2007-01-25 3:33 ` [linux-pm] " Len Brown
2007-01-25 3:28 ` Len Brown
2007-01-25 9:54 ` David Brownell
2007-01-25 19:37 ` Pavel Machek
2007-01-07 11:15 ` Pavel Machek
2007-01-25 2:03 ` Len Brown
2007-01-25 2:52 ` Nigel Cunningham
2007-01-25 8:17 ` Rafael J. Wysocki
2007-01-25 10:00 ` [linux-pm] " David Brownell
2007-01-18 6:53 ` Zhang Rui
2007-01-21 5:48 ` [PATCH 0/3] " Zhang Rui
2007-01-25 3:50 ` Len Brown
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=20070107055424.GA24853@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=david-b@pacbell.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=linux-pm@osdl.org \
--cc=rui.zhang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.