Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752246AbbFZO4s (ORCPT ); Fri, 26 Jun 2015 10:56:48 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:34866 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752475AbbFZO4Z (ORCPT ); Fri, 26 Jun 2015 10:56:25 -0400 Date: Fri, 26 Jun 2015 16:56:21 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Alex Hung Cc: dvhart@infradead.org, corentin.chary@gmail.com, 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: <20150626145621.GU2890@pali> References: <1435114671-24380-1-git-send-email-alex.hung@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1435114671-24380-1-git-send-email-alex.hung@canonical.com> 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: 1694 Lines: 56 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? -- 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/