Date:	Wed, 1 Jul 2015 00:09:41 +0800
From:	Alex Hung <alex.hung@...onical.com>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Darren Hart <dvhart@...radead.org>,
	Corentin Chary <corentin.chary@...il.com>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	acpi4asus-user@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for
 Windows 8

Thanks for the information, and I really appreciate it.

I took a quick look at my HP laptop and it has a led as below:

/sys/class/leds/hp::hddprotect$ cat trigger
[none] AC-online BAT0-charging-or-full BAT0-charging BAT0-full
BAT0-charging-blink-full-solid usb-gadget usb-host cpu0 cpu1 cpu2 cpu3
cpu4 cpu5 cpu6 cpu7 mmc0 rfkill1 rfkill2 rfkill8

and I learned that LED can be triggered by rfkill.  I also checked
asus-wmi and its default_trigger is its rfkill name "asus-wlan".

ATK4001 is an independent ACPI device, and Method(HSWC) is its method
to control LED (actually it has other functions but only LED is needed
so far). asus-rbtn does not have anything to be triggered because it
only translate an ACPI event to KEY_RFKILL unless a rfkill is created,
but this wouldn't make sense that I use both rfkill and led when I can
only use one.

The other concern is that I'd like the LED to be ORed by both WLAN and
BT in long term.  default_trigger seems to be linked to one trigger.

On Tue, Jun 30, 2015 at 4:58 PM, Pali Rohár <pali.rohar@...il.com> wrote:
> Hi!
>
> Ideally, try to touch led trigger configuration from userspace yourself,
> so you will see how it works. Take some machine which has some
> configurable led exported in /sys/class/leds/ and try to set some
> trigger via "trigger" entry.
>
> I think that default trigger for led device (from kernel) can be set via
> "default_trigger" property in struct led_classdev. See file linux/leds.h
>
> On Tuesday 30 June 2015 16:38:18 Alex Hung wrote:
>> Pali,
>>
>> Thanks for comments, but will you be able to provide more details so
>> it is more clear how this works?
>>
>> On Mon, Jun 29, 2015 at 8:29 PM, Pali Rohár <pali.rohar@...il.com> wrote:
>> > On Friday 26 June 2015 23:24:10 Alex Hung wrote:
>> >> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár <pali.rohar@...il.com> wrote:
>> >> > Hi!
>> >> >
>> >> > On Wednesday 24 June 2015 10:57:51 Alex Hung wrote:
>> >> >> ASUS introduced a new approach to handle wireless hotkey
>> >> >> since Windows 8.  When the hotkey is pressed, BIOS generates
>> >> >> a notification 0x88 to a new ACPI device, ATK4001.  This
>> >> >> new driver not only translates the notification to KEY_RFKILL
>> >> >> but also toggles its LED accordingly.
>> >> >>
>> >> >> Signed-off-by: Alex Hung <alex.hung@...onical.com>
>> >> >
>> >> > ...
>> >> >
>> >> >> +static int asus_radio_led_set(bool blocked)
>> >> >> +{
>> >> >> +     acpi_status status;
>> >> >> +     union acpi_object arg0 = { ACPI_TYPE_INTEGER };
>> >> >> +     struct acpi_object_list args = { 1, &arg0 };
>> >> >> +     unsigned long long output;
>> >> >> +
>> >> >> +     arg0.integer.value = blocked;
>> >> >> +     status = acpi_evaluate_integer(asus_rbtn_device->handle, "HSWC",
>> >> >> +                                    &args, &output);
>> >> >
>> >> > What is this ACPI call doing? Just set LED control? Or something more?
>> >> >
>> >> >> +     if (!ACPI_SUCCESS(status) || output == 0) {
>> >> >> +             pr_err("fail to change wireless LED.\n");
>> >> >> +             return -EINVAL;
>> >> >> +     }
>> >> >> +
>> >> >> +     return 0;
>> >> >> +}
>> >> >> +
>> >> >> +static int asus_rfkill_set(void *data, bool blocked)
>> >> >> +{
>> >> >> +     radio_led_state = blocked ? 0 : 1;
>> >> >> +
>> >> >> +     return asus_radio_led_set(radio_led_state);
>> >> >> +}
>> >> >
>> >> > In my opinion this is not good idea that "rfkill block" call from
>> >> > userspace just change LED on/off state and nothing more...
>> >> >
>> >> > If above ACPI call just change LED, then should not be this in LED
>> >> > subsystem instead rfkill one? Or why do you prefer to use rfkill
>> >> > interface instead led?
>> >>
>> >> It indeed controls LED only at the moment.  My intention was to have
>> >> have everything work without the need to modify any userspace
>> >> applications.  Current it is 1) aus-rbtn issues KEY_RFKILL 2) an
>> >> userspace application changes rfkill states, and 3) both radio and LED
>> >> work.  It will also work when a user enable/disable wireless devices
>> >> on a user application which uses rfkill interface.
>> >>
>> >> Come to think about it now, I may have to handle LED with WLAN and BT
>> >> but I will have to find a system with both devices later.
>> >>
>> >> I am not too familiar with userspace applications v.s. LED.  Is it
>> >> possible to do the same (i.e. without touching userspace)? I think
>> >> rfkill is good interface to handle whatever needs doing when changing
>> >> wireless states, such as LED controls.  However, if other approach can
>> >> meet the need I am happy to investigate.
>> >>
>> >
>> > There are triggers for led which automatically enable/disable led. I
>> > think that configuring default wifi/bluetooth trigger for that new led
>> > could work...
>> >
>> > --
>> > Pali Rohár
>> > pali.rohar@...il.com
>>
>>
>>
>
> --
> Pali Rohár
> pali.rohar@...il.com



-- 
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists