Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752744AbbF3Iib (ORCPT ); Tue, 30 Jun 2015 04:38:31 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:35797 "EHLO mail-qk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbbF3IiT convert rfc822-to-8bit (ORCPT ); Tue, 30 Jun 2015 04:38:19 -0400 MIME-Version: 1.0 In-Reply-To: <20150629122953.GF16230@pali> References: <1435114671-24380-1-git-send-email-alex.hung@canonical.com> <20150626145621.GU2890@pali> <20150629122953.GF16230@pali> Date: Tue, 30 Jun 2015 16:38:18 +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: 3371 Lines: 91 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 -- 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/