On Fri, Jul 20, 2012 at 5:26 AM, AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote: > For those machines with wapf=4, BIOS won't update the wireless LED, > since wapf=4 means user application will take in chage of the wifi and bt. > So, we have to turn on/off the wireless LED explicitly. > > But I found there is another wireless LED bug in launchpad and which is > not in the wapf=4 quirk. > So, I think maybe we should set wireless LED status explicitly for all > machines. > > BugLink: https://launchpad.net/bugs/901105 > > Signed-off-by: AceLan Kao <acelan.kao@xxxxxxxxxxxxx> > --- > drivers/platform/x86/asus-wmi.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c > index 638facf..75699b3 100644 > --- a/drivers/platform/x86/asus-wmi.c > +++ b/drivers/platform/x86/asus-wmi.c > @@ -719,6 +719,12 @@ error_workqueue: > return ret; > } > > +static void wlan_led_update(struct asus_wmi *asus) > +{ > + int status = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WLAN); > + asus_wmi_set_devstate(ASUS_WMI_DEVID_WIRELESS_LED, status, NULL); > +} > + > /* > * Rfkill devices > */ > @@ -750,6 +756,7 @@ static int asus_rfkill_set(void *data, bool blocked) > } > > result = asus_wmi_set_devstate(dev_id, ctrl_param, NULL); > + wlan_led_update(priv->asus); > > return result; > } For this one, if it's really a led, please expose it using the generic led class and assign it a default trigger linked to asus rfkill state. Also, only expose the led if really present (if there is a way to know that). Thanks, -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
