Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531AbbF3I61 (ORCPT ); Tue, 30 Jun 2015 04:58:27 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34404 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952AbbF3I6S (ORCPT ); Tue, 30 Jun 2015 04:58:18 -0400 Date: Tue, 30 Jun 2015 10:58:14 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Alex Hung Cc: Darren Hart , Corentin Chary , "platform-driver-x86@vger.kernel.org" , acpi4asus-user@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8 Message-ID: <20150630085814.GE27720@pali> References: <1435114671-24380-1-git-send-email-alex.hung@canonical.com> <20150626145621.GU2890@pali> <20150629122953.GF16230@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3987 Lines: 103 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 -- 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/