[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101224155641.209fe64a@queued.net>
Date: Fri, 24 Dec 2010 15:56:41 -0800
From: Andres Salomon <dilinger@...ued.net>
To: Daniel Drake <dsd@...top.org>
Cc: Samuel Ortiz <sameo@...ux.intel.com>, Paul Fox <pgf@...top.org>,
linux-kernel@...r.kernel.org
Subject: Re: MFD cell structure and sharing of resources
On Thu, 16 Dec 2010
15:38:52 +0000 Daniel Drake <dsd@...top.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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists