On Mon, Jul 23, 2012 at 5:27 AM, AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote:
> Dear Corentin,
>
> 2012/7/20 Corentin Chary <corentincj@xxxxxxxxxx>:
>> On Fri, Jul 20, 2012 at 5:26 AM, AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote:
>>> If the user bit is set, that mean BIOS can't set and record the wlan
>>> status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
>>> while we query the wlan status by id ASUS_WMI_DEVID_WLAN through WMI.
>>> So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
>>> while setting the wlan status through WMI.
>>> This is also the behavior that windows app will do.
>>>
>>> Quote from ASUS application engineer
>>> ===
>>> When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return
>>>
>>> (1) 0x00050001 (On)
>>> (2) 0x00050000 (Off)
>>> (3) 0x00030001 (On)
>>> (4) 0x00030000 (Off)
>>> (5) 0x00000002 (Unknown)
>>>
>>> (1), (2) means that the model has hardware GPIO for WLAN, you can call
>>> WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off
>>
>> Will it handle the LED too, or do you have to call 0x00010012 ?
> In this case, we don't have to worry about the LED, BIOS will pull
> up/down the LED pin
> after receiving the enable/disable wireless command through WMI.
>
>>
>>> (3), (4) means that the model doesn’t have hardware GPIO, you need to use
>>> API or driver library to turn WLAN on/off, and call
>>> WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status.
>>> After you set WLAN LED status, you can see the WLAN status is changed with
>>> WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly
>>> (ex: Windows), you can use it for synchronization.
>>
>> That means WMIMethod(DSTS, 0x00010011, 0) will do nothing ? Or will it
>> control both the led and the device ?
> Yes, WMIMethod(DSTS, 0x00010011, 0) will do nothing if we try to
> enable/disable it.
> It won't turn on/off the wifi nor the LED.
> But, we still can read the status of wireless through this command, but
> need to use 0x00010012 to set wifi status.
>
>> How can you then call WMIMethod(DSTS, 0x00010012, 0/1) since nobody
>> switched wlan on or off ?
>> If you just want a way to control the led, expose it under
>> /sys/class/leds, and remove wlan from /sys/class/rfkill if it doesn't
>> work.
> ASUS' BIOS engineer told us that it's a way to change the status of
> wifi(read from id 0x00010011)
> by writing the value to 0x00010012, and ms windows application do that as well.
> It's a poor design by ASUS' BIOS, they really surprise me while telling me that.
>
> But, the advantage of doing this is the value stored in the 0x00010012
> (should be read from id 0x00010011) will be preserved to next reboot.
> So that we can track the status of wifi.
> And once we can get the correct wifi state, we then can block/unblock
> wifi while boot up.
> And it will have the same behavior as the one controlled by BIOS.
So, in this case, 0x00010012 controls:
- The LED
- The LED *and* the WLAN device
- The WLAN device
- Nothing, it just stores a value
Just to be sure to understand ... Be sure to add a comment when using
0x00010012 to tell exactly what it does.
>>
>>> (5) means that the model doesn’t have WLAN device.
>>>
>>> WLAN is the ONLY special case with upper rule.
>>>
>>> For other device, like Bluetooth, you just need use
>>> WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0)
>>> to set.
>>> ===
>>>
>>> Signed-off-by: AceLan Kao <acelan.kao@xxxxxxxxxxxxx>
>>> ---
>>> drivers/platform/x86/asus-wmi.c | 27 ++++++++++++++++++++++++++-
>>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
>>> index 556cbb4..638facf 100644
>>> --- a/drivers/platform/x86/asus-wmi.c
>>> +++ b/drivers/platform/x86/asus-wmi.c
>>> @@ -98,6 +98,7 @@ MODULE_LICENSE("GPL");
>>> #define ASUS_WMI_DEVID_WIRELESS_LED 0x00010002
>>> #define ASUS_WMI_DEVID_CWAP 0x00010003
>>> #define ASUS_WMI_DEVID_WLAN 0x00010011
>>> +#define ASUS_WMI_DEVID_WLAN_LED 0x00010012
>>
>> What's the difference between this one and ASUS_WMI_DEVID_WIRELESS_LED ?
>> What is really 0x00010002 ?
> That's another weird part, that's the name defined in the ASUS WMI spec.
> Please see the attached pic.
> 0x00010002 is the read one which can control the wireless LED,
> I don't know why there is another one exists in the spec.
>
>>> #define ASUS_WMI_DEVID_BLUETOOTH 0x00010013
>>> #define ASUS_WMI_DEVID_GPS 0x00010015
>>> #define ASUS_WMI_DEVID_WIMAX 0x00010017
>>> @@ -723,10 +724,34 @@ error_workqueue:
>>> */
>>> static int asus_rfkill_set(void *data, bool blocked)
>>> {
>>> + static u32 wlan_status = 0xffffffff;
>>
>> Don't use a static variable, add a field into struct asus_wmi instead.
> got it.
>
>>
>>> struct asus_rfkill *priv = data;
>>> u32 ctrl_param = !blocked;
>>> + u32 dev_id = priv->dev_id;
>>> + int result;
>>>
>>> - return asus_wmi_set_devstate(priv->dev_id, ctrl_param, NULL);
>>> + /*
>>> + * If the user bit is set, BIOS can't set and record the wlan status,
>>> + * it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
>>> + * while we query the wlan status through WMI.
>>> + * So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
>>> + * while setting the wlan status through WMI.
>>> + * This is also the behavior that windows app will do.
>>> + */
>>> + if (dev_id == ASUS_WMI_DEVID_WLAN) {
>>> + if (wlan_status == 0xffffffff)
>>> + asus_wmi_get_devstate(priv->asus,
>>> + ASUS_WMI_DEVID_WLAN,
>>> + &wlan_status);
>>
>> Maybe you could read that on startup instead of using lazy loading ?
>> Read the state of the wlan device, and set a flag "led should be controlled"
> ok
>
>>
>>> + if (wlan_status &
>>> + (ASUS_WMI_DSTS_PRESENCE_BIT | ASUS_WMI_DSTS_USER_BIT))
>>> + dev_id = ASUS_WMI_DEVID_WLAN_LED;
>>> + }
>>> +
>>> + result = asus_wmi_set_devstate(dev_id, ctrl_param, NULL);
>>> +
>>> + return result;
>>> }
>>>
>>> static void asus_rfkill_query(struct rfkill *rfkill, void *data)
>>
>> While this patch work, I'll prefer an approach using a led class and a
>> led trigger. The led trigger would be set by default, but the user
>> would also be able to switch the trigger to another one, or to control
>> the led using /sys/class/leds/
> I think the problem is not so seriously, we just need to record the wifi status
> if the wifi device is controlled by application.
> And the solution is to store the status in 0x00010012.
> So that rfkill could work as expected.
>
> Best regards,
> AceLan Kao.
>
> --
> Chia-Lin Kao(AceLan)
> http://blog.acelan.idv.tw/
> E-Mail: acelan.kaoATcanonical.com (s/AT/@/)
--
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
