Re: use of preempt_count instead of in_atomic() at leds-gpio.c

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

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
> > 
> > Just a "leaning..." comment:
> > 
> > 	http://marc.info/?l=linux-kernel&m=120606104619198&w=2
> > 
> > Seems to me that by now there ought to be resolution on at least
> > one of the issues brought up on this thread.  :)
> 
> Is it reasonable to have two version of that subroutine: one meant to 
> be called in a sleepable context and the other to be called when 
> sleeping isn't allowed?

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh