[PATCH] asus-wmi: explicitly set the wireless LED

[PATCH] asus-wmi: explicitly set the wireless LED

[Keng-Yu Lin]

On Asus K54C, the wireless LED is always off without setting explicitly.

Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
---
 drivers/platform/x86/asus-wmi.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index d1049ee..db514c4 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -726,6 +726,9 @@ static int asus_rfkill_set(void *data, bool blocked)
 	struct asus_rfkill *priv = data;
 	u32 ctrl_param = !blocked;
 
+	if (priv->dev_id == ASUS_WMI_DEVID_WLAN)
+		asus_wmi_set_devstate(ASUS_WMI_DEVID_WIRELESS_LED, ctrl_param, NULL);
+
 	return asus_wmi_set_devstate(priv->dev_id, ctrl_param, NULL);
 }
 
-- 
1.7.5.4

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Corentin Chary]

On Wed, Dec 7, 2011 at 9:02 AM, Keng-Yu Lin <kengyu@canonical.com> wrote:
> On Asus K54C, the wireless LED is always off without setting explicitly.
>
> Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
> ---
>  drivers/platform/x86/asus-wmi.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index d1049ee..db514c4 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -726,6 +726,9 @@ static int asus_rfkill_set(void *data, bool blocked)
>        struct asus_rfkill *priv = data;
>        u32 ctrl_param = !blocked;
>
> +       if (priv->dev_id == ASUS_WMI_DEVID_WLAN)
> +               asus_wmi_set_devstate(ASUS_WMI_DEVID_WIRELESS_LED, ctrl_param, NULL);
> +
>        return asus_wmi_set_devstate(priv->dev_id, ctrl_param, NULL);
>  }
>
> --
> 1.7.5.4
>

NACK

If this is only for K54C (works fine on my G73 anyway) then you must
do some kind of DMI matching right ? Or at least check that this led
is present. Do you have any list of laptops that export this LED and
how it behave ?

Anyway, you should use a led trigger for that, ideally the rfkill%d
led trigger, but for that you need the rfkill idx, which is not
exported, so you may need a new rfkill_idx() function. CCing rfkill
and led guys, they may have a better advice on that.
-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Corentin Chary]

On Wed, Dec 7, 2011 at 9:02 AM, Keng-Yu Lin <kengyu-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> On Asus K54C, the wireless LED is always off without setting explicitly.
>
> Signed-off-by: Keng-Yu Lin <kengyu-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
>  drivers/platform/x86/asus-wmi.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index d1049ee..db514c4 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -726,6 +726,9 @@ static int asus_rfkill_set(void *data, bool blocked)
>        struct asus_rfkill *priv = data;
>        u32 ctrl_param = !blocked;
>
> +       if (priv->dev_id == ASUS_WMI_DEVID_WLAN)
> +               asus_wmi_set_devstate(ASUS_WMI_DEVID_WIRELESS_LED, ctrl_param, NULL);
> +
>        return asus_wmi_set_devstate(priv->dev_id, ctrl_param, NULL);
>  }
>
> --
> 1.7.5.4
>

NACK

If this is only for K54C (works fine on my G73 anyway) then you must
do some kind of DMI matching right ? Or at least check that this led
is present. Do you have any list of laptops that export this LED and
how it behave ?

Anyway, you should use a led trigger for that, ideally the rfkill%d
led trigger, but for that you need the rfkill idx, which is not
exported, so you may need a new rfkill_idx() function. CCing rfkill
and led guys, they may have a better advice on that.
-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Johannes Berg]

On Thu, 2011-12-15 at 08:07 +0100, Corentin Chary wrote:

> Anyway, you should use a led trigger for that, ideally the rfkill%d
> led trigger, but for that you need the rfkill idx, which is not
> exported, so you may need a new rfkill_idx() function. CCing rfkill
> and led guys, they may have a better advice on that.

Since you wouldn't want to build the string yourself, you'd probably
want a new rfkill_ledtrigname() function like this:

static const char *rfkill_ledtrigname(struct rfkill *rfkill)
{
#ifdef CONFIG_RFKILL_LEDS
	return rfkill->ledtrigname;
#endif
	return NULL;
}

which you use to assign the LED class device's default trigger.

johannes

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Johannes Berg]

On Thu, 2011-12-15 at 08:07 +0100, Corentin Chary wrote:

> Anyway, you should use a led trigger for that, ideally the rfkill%d
> led trigger, but for that you need the rfkill idx, which is not
> exported, so you may need a new rfkill_idx() function. CCing rfkill
> and led guys, they may have a better advice on that.

Since you wouldn't want to build the string yourself, you'd probably
want a new rfkill_ledtrigname() function like this:

static const char *rfkill_ledtrigname(struct rfkill *rfkill)
{
#ifdef CONFIG_RFKILL_LEDS
	return rfkill->ledtrigname;
#endif
	return NULL;
}

which you use to assign the LED class device's default trigger.

johannes


------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Corentin Chary]

On Thu, Dec 15, 2011 at 9:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2011-12-15 at 08:07 +0100, Corentin Chary wrote:
>
>> Anyway, you should use a led trigger for that, ideally the rfkill%d
>> led trigger, but for that you need the rfkill idx, which is not
>> exported, so you may need a new rfkill_idx() function. CCing rfkill
>> and led guys, they may have a better advice on that.
>
> Since you wouldn't want to build the string yourself, you'd probably
> want a new rfkill_ledtrigname() function like this:
>
> static const char *rfkill_ledtrigname(struct rfkill *rfkill)
> {
> #ifdef CONFIG_RFKILL_LEDS
>        return rfkill->ledtrigname;
> #endif
>        return NULL;
> }
>
> which you use to assign the LED class device's default trigger.
>
> johannes
>

Right, but is rfkill->ledtrigname really set somewhere ?

rfkill->led_trigger.name seems safer to use.


-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Johannes Berg]

On Thu, 2011-12-15 at 09:25 +0100, Corentin Chary wrote:

> > static const char *rfkill_ledtrigname(struct rfkill *rfkill)
> > {
> > #ifdef CONFIG_RFKILL_LEDS
> >        return rfkill->ledtrigname;
> > #endif
> >        return NULL;
> > }

> Right, but is rfkill->ledtrigname really set somewhere ?
> 
> rfkill->led_trigger.name seems safer to use.

Hm, indeed -- looks like we can get rid of ledtrigname completely since
nothing ever touches it.

johannes

Re: [PATCH] asus-wmi: explicitly set the wireless LED

[Johannes Berg]

On Thu, 2011-12-15 at 09:25 +0100, Corentin Chary wrote:

> > static const char *rfkill_ledtrigname(struct rfkill *rfkill)
> > {
> > #ifdef CONFIG_RFKILL_LEDS
> >        return rfkill->ledtrigname;
> > #endif
> >        return NULL;
> > }

> Right, but is rfkill->ledtrigname really set somewhere ?
> 
> rfkill->led_trigger.name seems safer to use.

Hm, indeed -- looks like we can get rid of ledtrigname completely since
nothing ever touches it.

johannes


------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/