All of lore.kernel.org
 help / color / mirror / Atom feed
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?

      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 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.