Problems porting asus_acpi to LED subsystem

[Thomas Tuttle <thinkinginbinary@gmail.com>]

Summary:

I'm trying to link asus_acpi into the LED subsystem.  My set_brightness
callback evaluates an ACPI method to set the LED state.  It works fine
manually changing the brightness, but when the callback is called by a
timer (using the timer or ide-disk triggers), it eventually causes an
Oops.  I can post my code or the Oops if it would help.  I'm new at
kernel coding, and I'm not on the list, so please CC me on any reply.
Sorry if this isn't appropriate on the list.

Long version:

I have an Asus laptop with two LED's that are supported by the asus_acpi
driver, and I'm trying to link the asus_acpi driver's LED features
(currently available only with a /proc interface) into the new LED
subsystem.

I tried to do this, by registering two LED devices with the LED
subsystem when the asus_acpi device is created.  This works, and the LED
devices show up in /sys/class/leds/.  I can change the brightness by
hand, by writing /sys/class/leds/asus:mail/brightness.  But if I try to
set the trigger to something that uses a timer, like ide-disk or timer,
it eventually causes an Oops.  I will try to capture the actual text of
the message, but the last one involved a stack of acpi_* functions,
followed by a couple of timer functions, the last being schedule_timer.

I haven't written any kernel code before, and I can't figure out what
I'm doing wrong.  The two functions that I created as the brightness_set
methods for the LED devices are essentially identical to the two used by
asus_acpi itself for the /proc interface.  All I can guess is that
either the ACPI methods are taking too long to run and the timer is
firing a new event while the old one is still running (but I don't
believe it is this, because timer_function in ledtrig-timer only
restarts the timer after it changes the LED value), or that the timer is
going off while the kernel is accessing something else with ACPI, and
things are getting corrupted.  Is there a way to schedule the ACPI call
that changes the LED state so it doesn't happen until it's "safe", or is
there some lock I should be acquiring before I change the LED state?

Alternatively, should the led timer trigger be more careful about when
it calls the LED set_brightness methods?  I don't know if there is a
convention for the context of that call--is it my responsibility to
ensure I'm not fiddling with ACPI stuff, or is it the timer's
responsibility to call my set_brightness method at a "good time"?

I'm sorry for posting to LKML with an issue like this, since I should
probably be able to figure it out myself, but I'm new at this and eager
to get this working.  I can post my code somewhere if anyone wants to
look at it.  (It's only about 20 lines added to asus_acpi.c.)

I'm not subscribed to the list, so I'd appreciate a CC on any reply.
I'll also keep an eye on the archives, just in case.

Thanks,

Thomas Tuttle

-- 
Thomas Tuttle (thinkinginbinary@gmail.com)
A List Apart: For people who make websites. alistapart.com
aim/y!m:thinkinginbinary; icq:198113263; jabber:thinkinginbinary@jabber.org
msn: thinkinginbinary@hotmail.com; pgp: 0xAF5112C6

Attachment: pgpRKHWPRuzQu.pgp
Description: PGP signature