linux-kernel - Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Jun 2015 16:56:21 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Alex Hung <alex.hung@...onical.com>
Cc:	dvhart@...radead.org, corentin.chary@...il.com,
	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

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?

-- 
Pali Rohár
pali.rohar@...il.com
--
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/