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@xxxxxxxxxxxxx>
...
> +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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
