From: Richard Purdie <rpurdie@rpsys.net>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Alan Stern <stern@rowland.harvard.edu>,
David Brownell <david-b@pacbell.net>,
gitster@pobox.com, corbet@lwn.net, mingo@elte.hu, mb@bu3sch.de,
linux-kernel@vger.kernel.org, khali@linux-fr.org,
geert@linux-m68k.org, akpm@linux-foundation.org
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c
Date: Wed, 26 Mar 2008 16:46:09 +0000 [thread overview]
Message-ID: <1206549969.13642.6.camel@dax.rpnet.com> (raw)
In-Reply-To: <20080326161724.GA3562@khazad-dum.debian.net>
On Wed, 2008-03-26 at 13:17 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 26 Mar 2008, Alan Stern wrote:
> > On Tue, 25 Mar 2008, David Brownell wrote:
> > > I _almost_ hate bringing this lovely flamage back onto $SUBJECT ... but
> > > what's the resolution for the leds-gpio.c issue? I've not seen a merge
> > > notice for the patch I submitted a week ago now:
> > >
> > > http://marc.info/?l=linux-kernel&m=120597839009399&w=2
>
[...]
> I have changed the thinkpad-acpi leds code to always assume an atomic
> context, but I too would appreciate a proper flag (or secondary hook)
> from the LED class to know when I am in an atomic context or not.
>
> LED Triggers also need to be modified, they are mostly called from an
> atomic context so we have to assume that by default, but we'd do well to
> add a way to call them from non-atomic contexts.
>
> Richard? AFAIK, the ball *is* in your court as the LED maintainer. You
> have to decide which way to go and tell us. I suppose either I or Alan
> could write up patches to implement it, but I have better things to do
> than to write patches that would be rejected anyway... OTOH, I don't
> mind writing ones that I know are at least attempting to implement an
> approved idea and would be rejected only if they need some fixing.
I've been meaning to merge David's patch and will get that done shortly,
sorry for the delay.
As I've said, I don't really think we need context flags for the LED
class at the moment. As you say, most of the triggers are atomic context
and those which can sleep are not time critical so I don't really see
the point in the added complexity.
Cheers,
Richard
next prev parent reply other threads:[~2008-03-26 16:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-16 18:43 Henrique de Moraes Holschuh
2008-03-16 19:46 ` David Brownell
2008-03-18 7:14 ` Andrew Morton
2008-03-18 19:06 ` David Brownell
2008-03-18 20:07 ` Andrew Morton
2008-03-20 22:56 ` Henrique de Moraes Holschuh
2008-03-20 23:47 ` Andrew Morton
2008-03-21 0:36 ` Henrique de Moraes Holschuh
2008-03-21 1:08 ` Andrew Morton
2008-03-21 1:31 ` Alan Stern
2008-03-21 1:36 ` Michael Buesch
2008-03-21 2:27 ` Andrew Morton
2008-03-21 3:07 ` Alan Stern
2008-03-21 3:17 ` Andrew Morton
2008-03-21 9:53 ` Jean Delvare
2008-03-21 17:37 ` Andrew Morton
2008-03-21 18:05 ` Alan Stern
2008-03-24 19:34 ` Jonathan Corbet
2008-03-24 19:42 ` Andrew Morton
2008-03-24 19:53 ` Jonathan Corbet
2008-03-25 8:52 ` Junio C Hamano
2008-03-25 10:39 ` Jean Delvare
2008-03-25 13:44 ` Jonathan Corbet
2008-03-25 23:20 ` David Brownell
2008-03-26 14:28 ` Alan Stern
2008-03-26 16:17 ` Henrique de Moraes Holschuh
2008-03-26 16:46 ` Richard Purdie [this message]
2008-03-27 18:51 ` David Brownell
2008-03-21 15:11 ` Tetsuo Handa
2008-03-21 16:54 ` Stefan Richter
2008-03-21 17:02 ` Stefan Richter
2008-03-23 5:53 ` Tetsuo Handa
2008-03-21 13:47 ` Heiko Carstens
2008-03-21 16:54 ` Greg KH
2008-03-21 19:59 ` Andrew Morton
2008-03-21 20:16 ` Michael Buesch
2008-03-21 20:20 ` Michael Buesch
2008-03-21 9:21 ` Stefan Richter
2008-03-21 9:27 ` Stefan Richter
2008-03-21 12:37 ` Henrique de Moraes Holschuh
2008-03-21 13:16 ` Stefan Richter
2008-03-22 11:29 ` Stefan Richter
2008-03-21 17:04 ` David Brownell
2008-03-21 0:56 ` Richard Purdie
2008-03-21 2:10 ` Henrique de Moraes Holschuh
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=1206549969.13642.6.camel@dax.rpnet.com \
--to=rpurdie@rpsys.net \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david-b@pacbell.net \
--cc=geert@linux-m68k.org \
--cc=gitster@pobox.com \
--cc=hmh@hmh.eng.br \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mb@bu3sch.de \
--cc=mingo@elte.hu \
--cc=stern@rowland.harvard.edu \
/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
all inboxes | Powered by JetHome®