Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753570AbbF3QJs (ORCPT ); Tue, 30 Jun 2015 12:09:48 -0400 Received: from mail-qk0-f180.google.com ([209.85.220.180]:36144 "EHLO mail-qk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751854AbbF3QJm convert rfc822-to-8bit (ORCPT ); Tue, 30 Jun 2015 12:09:42 -0400 MIME-Version: 1.0 In-Reply-To: <20150630085814.GE27720@pali> References: <1435114671-24380-1-git-send-email-alex.hung@canonical.com> <20150626145621.GU2890@pali> <20150629122953.GF16230@pali> <20150630085814.GE27720@pali> Date: Wed, 1 Jul 2015 00:09:41 +0800 Message-ID: Subject: Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8 From: Alex Hung To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Darren Hart , Corentin Chary , "platform-driver-x86@vger.kernel.org" , acpi4asus-user@lists.sourceforge.net, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5180 Lines: 132 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 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 wrote: >> > On Friday 26 June 2015 23:24:10 Alex Hung wrote: >> >> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár 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 >> >> > >> >> > ... >> >> > >> >> >> +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@gmail.com >> >> >> > > -- > Pali Rohár > pali.rohar@gmail.com -- Cheers, Alex Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/