On Wed, Dec 9, 2009 at 7:53 AM, Ike Panhc <ike.pan@xxxxxxxxxxxxx> wrote: > Corentin Chary wrote: >> On Tue, Dec 8, 2009 at 4:41 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: >>> On Tue, Dec 08, 2009 at 03:37:09PM +0800, Ike Panhc wrote: >>> >>>> ASUS_HANDLE(rled_set, ASUS_HOTK_PREFIX "RLED"); /* W1JC */ >>>> ASUS_HANDLE(pled_set, ASUS_HOTK_PREFIX "PLED"); /* A7J */ >>>> ASUS_HANDLE(gled_set, ASUS_HOTK_PREFIX "GLED"); /* G1, G2 (probably) */ >>> The driver is controlling the ATKD device, which has a HID of ATK0101. >>> These devices are all underneath it... >>> >>>> +ASUS_HANDLE(lled_set, "\\_SB_.PCI0.SBRG.EC0_.HKEY.TVLS"); /* LenovoCare */ >>> And this one isn't, which is a bit jarring. Looking closer, it's under >>> the LEN0014 device, which means that you're trying to touch a method >>> that belongs to a device other than the one this driver is bound to. >>> That's wrong. You want a separate ACPI driver for the LEN0014 device, >>> and this should be called for there. Looking at it, you seem to get >>> rfkill as well (the GWAN/SWAN, GBDC/SBDF and GUWB/SUWB methods) and >>> maybe some other stuff. >>> >>> So this shouldn't go in asus-laptop. You'll need to add another separate >>> driver for the SL-specific functionality. >> >> That means asus-laptop and sl-laptop will be both needed for a SL >> laptop, but I don't think this is a problem. >> > I think your suggestion is that one acpi driver for one acpi device. > It makes sense to me. I will build a new driver. > > You should take a look at the new eeepc-laptop driver in http://git.iksaif.net/?p=acpi4asus.git;a=summary Alan Jenkins cleaned it a lot so it can be an example for new drivers :) -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
