From: Andres Salomon <dilinger@queued.net>
To: Daniel Drake <dsd@laptop.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>, Paul Fox <pgf@laptop.org>,
linux-kernel@vger.kernel.org
Subject: Re: MFD cell structure and sharing of resources
Date: Fri, 24 Dec 2010 15:56:41 -0800 [thread overview]
Message-ID: <20101224155641.209fe64a@queued.net> (raw)
In-Reply-To: <AANLkTi=ypose5day4=ypV8_SsiFq4vf9vqZh-OWret0x@mail.gmail.com>
On Thu, 16 Dec 2010
15:38:52 +0000 Daniel Drake <dsd@laptop.org> wrote:
[...]
>
> Secondly, the olpc-xo1-pm driver is going to have a couple of sysfs
> nodes that will be used by userspace.
>
> Under the current design they appear as e.g.:
> /sys/devices/pci0000:00/0000:00:0f.0/cs5535-acpi/wakeup_reason
>
> However, it only appears under cs5535-acpi because that's the device
> that appeared second (out of acpi + pms). If the probe order ever
> changed, the path would change too.
> This could be worked around by storing both pointers (acpi + pms) and
> choosing one that the olpc-xo1-pm parts will always live under. But as
> this detail represents an interface to userspace we should be careful
> and try and get it right first time. That wakeup_reason node is not
> really related to cs5535, it's an OLPC-specific thing (since the
> wakeups can be caused by things totally separate from the geode hw).
> So I'd feel a lot more comfortable if that path was less related to
> cs5535.
I'd just like to point out that power_kobj is available (from
linux/kobject.h) as an option. If we're short on
options, /sys/power/wakeup_reason is a potential solution that
would be extremely simple for userspace to deal with.
Currently OLPC patches throw random strings like "lid" and "key press"
into wakeup_reason (well, wackup_source in the ancient patches that I'm
looking at), but one can imagine a more structured approach that's
more generally useful. Perhaps a list of sources that are
registered, with each being a kobj - either defined specifically for
the purpose of being a wakeup source, or an existing device object
(eg, a wlan object for WOL events).
That said, I'm failing to recall why we need a sysfs file exporting a
wakeup reason in the first place; can't we just send netlink/udev events
when a wakeup occurs with the reason for the wakeup?
prev parent reply other threads:[~2010-12-24 23:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-10 15:37 MFD cell structure and sharing of resources Daniel Drake
2010-12-10 16:34 ` Daniel Drake
2010-12-16 10:35 ` Samuel Ortiz
2010-12-16 15:38 ` Daniel Drake
2010-12-24 10:45 ` Samuel Ortiz
2010-12-25 6:48 ` Andres Salomon
2010-12-25 14:23 ` Mark Brown
2010-12-24 23:56 ` Andres Salomon [this message]
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=20101224155641.209fe64a@queued.net \
--to=dilinger@queued.net \
--cc=dsd@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pgf@laptop.org \
--cc=sameo@linux.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