Re: best way to handle LEDs

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Wed, Nov 02, 2005 at 08:52:41PM -0600, John Lenz wrote:
> On Wed, November 2, 2005 3:33 pm, Robert Schwebel said:
> > On Wed, Nov 02, 2005 at 10:13:34PM +0100, Pavel Machek wrote:
> >> We have some leds that are *not* on GPIO pins (like driven by
> >> ACPI). We'd like to support those, too.
> >
> > One more argument to have a LED framework which sits ontop of a lowlevel
> > one.
> >
> 
> Except the led code that is being proposed CAN sit on top of a generic
> GPIO layer.

I also have issues with a generic GPIO layer.  As I mentioned in the
past, there's serious locking issues with any generic abstraction of
GPIOs.

1. You want to be able to change GPIO state from interrupts.  This
   implies you can not sleep in GPIO state changing functions.

2. Some GPIOs are implemented on I2C devices.  This means that to
   change state, you must sleep.

(1) and (2) are incompatible requirements, so you can not offer a
generic interface for these GPIOs which has a consistent behaviour -
where users of the interface know whether the function may sleep or
may be used from interrupt context.

If you also consider that LEDs may be connected to these GPIOs, and
you may wish to change their state from interrupt context, you also
run into these same issues - you have an interface which has ill-
defined behaviour and ill-defined calling requirements.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/