From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Colin Cross <ccross@android.com>,
lkml <linux-kernel@vger.kernel.org>,
Bryan Wu <bryan.wu@canonical.com>
Subject: Re: sysfs permissions on dynamic attributes (led delay_on and delay_off)
Date: Sat, 21 Jul 2012 08:33:30 +0100 [thread overview]
Message-ID: <1342856010.21788.47.camel@ted> (raw)
In-Reply-To: <20120721040816.GA7313@kroah.com>
On Fri, 2012-07-20 at 21:08 -0700, Greg KH wrote:
> On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
> > I'm trying to use the standard ledtrig-timer.c code to handle led
> > blinking for notifications on an Android device, and I'm hitting some
> > issues with setting permissions on the dynamically created delay_on
> > and delay_off attributes. For most sysfs files, we have userspace
> > uevent parser that watches for device add notifications and
> > chowns/chmods attributes. This doesn't work for delay_on and
> > delay_off, because they are created later, when "timer" is written to
> > the trigger attribute. There is no uevent when the new files are
> > created, and sysfs doesn't support inotify, so I don't see any way to
> > receive an event to set the permissions. This issue exists any time
> > that device_create_file is called after device_add.
> >
> > What is the appropriate way to get an event to set the permissions?
> > Add inotify support for sysfs file creation? Send a KOBJ_CHANGE
> > uevent in device_create_file?
>
> No.
>
> > Send a KOBJ_CHANGE uevent from the driver after calling
> > device_create_file?
>
> Yes.
>
> > Dynamically create a timer device under /sys/class/leds/<led> so a new
> > add uevent gets sent?
>
> Ick.
>
> > Promote blinking to be a core led feature instead of a trigger, so the
> > files are always present?
>
> That's the best thing, why not just do that?
This implies we should make every trigger a core led feature and
effectively do away with triggers. I'm not sure that makes sense.
Cheers,
Richard
next prev parent reply other threads:[~2012-07-21 8:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 0:46 sysfs permissions on dynamic attributes (led delay_on and delay_off) Colin Cross
2012-07-21 4:08 ` Greg KH
2012-07-21 5:14 ` Colin Cross
2012-07-21 15:07 ` Greg KH
2012-07-21 7:33 ` Richard Purdie [this message]
2012-07-21 8:26 ` Colin Cross
2012-07-21 11:21 ` Richard Purdie
2012-07-21 14:31 ` Henrique de Moraes Holschuh
2012-07-21 15:42 ` Colin Cross
2012-07-21 16:08 ` Henrique de Moraes Holschuh
2012-07-21 16:15 ` Greg KH
2012-07-21 16:23 ` Colin Cross
2012-07-21 16:13 ` Greg KH
2012-07-21 16:22 ` Colin Cross
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=1342856010.21788.47.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=bryan.wu@canonical.com \
--cc=ccross@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/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.