[ibm-acpi-devel] [PATCH v2 5/6] platform/x86: dell-laptop: Drop superfluous exported function
Since we've switched to the LED trigger for binding with HD-audio,
we can drop the exported function as well as the whole
linux/dell-led.h.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Andy Shevchenko
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
drivers/platform/x86/dell-laptop.c | 22 +-
include/linux/dell-led.h | 7 ---
2 files changed, 5 insertions(+), 24 deletions(-)
delete mode 100644 include/linux/dell-led.h
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 0db2dbf7b0d1..fb071e6a5058 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include "dell-rbtn.h"
@@ -2109,17 +2108,17 @@ static struct notifier_block dell_laptop_notifier = {
.notifier_call = dell_laptop_notifier_call,
};
-int dell_micmute_led_set(int state)
+static int micmute_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
{
struct calling_interface_buffer buffer;
struct calling_interface_token *token;
+ int state = brightness != LED_OFF;
if (state == 0)
token = dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE);
- else if (state == 1)
- token = dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE);
else
- return -EINVAL;
+ token = dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE);
if (!token)
return -ENODEV;
@@ -2127,18 +2126,7 @@ int dell_micmute_led_set(int state)
dell_fill_request(, token->location, token->value, 0, 0);
dell_send_request(, CLASS_TOKEN_WRITE, SELECT_TOKEN_STD);
- return state;
-}
-EXPORT_SYMBOL_GPL(dell_micmute_led_set);
-
-static int micmute_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
-{
- int state = brightness != LED_OFF;
- int err;
-
- err = dell_micmute_led_set(state);
- return err < 0 ? err : 0;
+ return 0;
}
static struct led_classdev micmute_led_cdev = {
diff --git a/include/linux/dell-led.h b/include/linux/dell-led.h
deleted file mode 100644
index 92521471517f..
--- a/include/linux/dell-led.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __DELL_LED_H__
-#define __DELL_LED_H__
-
-int dell_micmute_led_set(int on);
-
-#endif
--
2.19.1
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH v2 0/6] Introduce audio-mute LED trigger (and conversions to it)
Hi, this is revised patch series for adding a new LED trigger audio-mute and audio-micmute, and converting the HD-audio driver and the platform drivers to use the LED trigger instead of the ugly direct dynamic symbol binding. v2 series addressed a couple of issues Andy suggested, and changed the led class dev names to "platform::xxx" as discussed in the previous thread. The latest version of patches are found in topic/leds-trigger branch in my sound git tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git As these are cross-tree patches, the branch above is based cleanly on v4.20-rc3. From now on, it'll stay as an immutable branch, so feel free to merge into other trees. thanks, Takashi === Takashi Iwai (6): leds: trigger: Introduce audio mute LED trigger platform/x86: dell-laptop: Add micmute LED trigger support platform/x86: thinkpad_acpi: Add audio mute LED classdev support ALSA: hda - Support led audio trigger platform/x86: dell-laptop: Drop superfluous exported function platform/x86: thinkpad_acpi: Drop superfluous exported function drivers/leds/trigger/Kconfig | 7 +++ drivers/leds/trigger/Makefile| 1 + drivers/leds/trigger/ledtrig-audio.c | 44 ++ drivers/platform/x86/Kconfig | 4 ++ drivers/platform/x86/dell-laptop.c | 27 --- drivers/platform/x86/thinkpad_acpi.c | 67 +--- include/linux/dell-led.h | 7 --- include/linux/leds.h | 20 + include/linux/thinkpad_acpi.h| 16 --- sound/pci/hda/dell_wmi_helper.c | 48 sound/pci/hda/hda_generic.c | 31 + sound/pci/hda/hda_generic.h | 2 + sound/pci/hda/patch_realtek.c| 17 +++ sound/pci/hda/thinkpad_helper.c | 43 +++--- 14 files changed, 194 insertions(+), 140 deletions(-) create mode 100644 drivers/leds/trigger/ledtrig-audio.c delete mode 100644 include/linux/dell-led.h delete mode 100644 include/linux/thinkpad_acpi.h delete mode 100644 sound/pci/hda/dell_wmi_helper.c -- 2.19.1 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH v2 2/6] platform/x86: dell-laptop: Add micmute LED trigger support
This patch adds the LED trigger support for audio mic-mute control.
As of this patch, the LED device isn't tied with the audio driver, and
can be changed via user-space at "platform::micmute" sysfs entry.
(This new prefix "platform" is the agreement among people for
indicating the generic laptop / system-wide attribute.)
The binding with HD-audio is still done via the existing exported
dell_micmute_led_set(). It will be replaced with the LED trigger
binding in later patches.
Also this selects CONFIG_LEDS_TRIGGERS and CONFIG_LEDS_TRIGGERS_AUDIO
unconditionally. Strictly speaking, these aren't 100% mandatory, but
leaving these manual selections would lead to a functional regression
easily once after converting from the dynamic symbol binding to the
LEDs trigger in a later patch.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Andy Shevchenko
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
drivers/platform/x86/Kconfig | 2 ++
drivers/platform/x86/dell-laptop.c | 25 +
2 files changed, 27 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 54f6a40c75c6..9b9cc3cc33e9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -177,6 +177,8 @@ config DELL_LAPTOP
select POWER_SUPPLY
select LEDS_CLASS
select NEW_LEDS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_AUDIO
---help---
This driver adds support for rfkill and backlight control to Dell
laptops (except for some models covered by the Compal driver).
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 06978c14c83b..0db2dbf7b0d1 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -2131,6 +2131,23 @@ int dell_micmute_led_set(int state)
}
EXPORT_SYMBOL_GPL(dell_micmute_led_set);
+static int micmute_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ int state = brightness != LED_OFF;
+ int err;
+
+ err = dell_micmute_led_set(state);
+ return err < 0 ? err : 0;
+}
+
+static struct led_classdev micmute_led_cdev = {
+ .name = "platform::micmute",
+ .max_brightness = 1,
+ .brightness_set_blocking = micmute_led_set,
+ .default_trigger = "audio-micmute",
+};
+
static int __init dell_init(void)
{
struct calling_interface_token *token;
@@ -2175,6 +2192,11 @@ static int __init dell_init(void)
dell_laptop_register_notifier(_laptop_notifier);
+ micmute_led_cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
+ ret = led_classdev_register(_device->dev, _led_cdev);
+ if (ret < 0)
+ goto fail_led;
+
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
@@ -2220,6 +2242,8 @@ static int __init dell_init(void)
fail_get_brightness:
backlight_device_unregister(dell_backlight_device);
fail_backlight:
+ led_classdev_unregister(_led_cdev);
+fail_led:
dell_cleanup_rfkill();
fail_rfkill:
platform_device_del(platform_device);
@@ -2239,6 +2263,7 @@ static void __exit dell_exit(void)
touchpad_led_exit();
kbd_led_exit();
backlight_device_unregister(dell_backlight_device);
+ led_classdev_unregister(_led_cdev);
dell_cleanup_rfkill();
if (platform_device) {
platform_device_unregister(platform_device);
--
2.19.1
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH v2 6/6] platform/x86: thinkpad_acpi: Drop superfluous exported function
Since we've switched to the LED trigger for binding with HD-audio,
we can drop the exported function as well as the whole
linux/thinkpad_acpi.h.
The own TPACPI_LED_MUTE and TPACPI_LED_MICMUTE definitions are
replaced with the identical ones for LEDS, i.e. LED_AUDIO_MUTE and
LED_AUDIO_MICMUTE, respectively. They are no longer needed as
referred only locally.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Andy Shevchenko
Acked-by: Henrique de Moraes Holschuh
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++--
include/linux/thinkpad_acpi.h| 16 ---
2 files changed, 11 insertions(+), 35 deletions(-)
delete mode 100644 include/linux/thinkpad_acpi.h
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 3d2c1f5f22e2..21ffb961585a 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -81,7 +81,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -9150,6 +9149,7 @@ static struct ibm_struct fan_driver_data = {
* Mute LED subdriver
*/
+#define TPACPI_LED_MAX 2
struct tp_led_table {
acpi_string name;
@@ -9158,13 +9158,13 @@ struct tp_led_table {
int state;
};
-static struct tp_led_table led_tables[] = {
- [TPACPI_LED_MUTE] = {
+static struct tp_led_table led_tables[TPACPI_LED_MAX] = {
+ [LED_AUDIO_MUTE] = {
.name = "SSMS",
.on_value = 1,
.off_value = 0,
},
- [TPACPI_LED_MICMUTE] = {
+ [LED_AUDIO_MICMUTE] = {
.name = "MMTS",
.on_value = 2,
.off_value = 0,
@@ -9189,40 +9189,36 @@ static int mute_led_on_off(struct tp_led_table *t, bool
state)
return state;
}
-int tpacpi_led_set(int whichled, bool on)
+static int tpacpi_led_set(int whichled, bool on)
{
struct tp_led_table *t;
- if (whichled < 0 || whichled >= TPACPI_LED_MAX)
- return -EINVAL;
-
t = _tables[whichled];
if (t->state < 0 || t->state == on)
return t->state;
return mute_led_on_off(t, on);
}
-EXPORT_SYMBOL_GPL(tpacpi_led_set);
static int tpacpi_led_mute_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
- return tpacpi_led_set(TPACPI_LED_MUTE, brightness != LED_OFF);
+ return tpacpi_led_set(LED_AUDIO_MUTE, brightness != LED_OFF);
}
static int tpacpi_led_micmute_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
- return tpacpi_led_set(TPACPI_LED_MICMUTE, brightness != LED_OFF);
+ return tpacpi_led_set(LED_AUDIO_MICMUTE, brightness != LED_OFF);
}
-static struct led_classdev mute_led_cdev[] = {
- [TPACPI_LED_MUTE] = {
+static struct led_classdev mute_led_cdev[TPACPI_LED_MAX] = {
+ [LED_AUDIO_MUTE] = {
.name = "platform::mute",
.max_brightness = 1,
.brightness_set_blocking = tpacpi_led_mute_set,
.default_trigger = "audio-mute",
},
- [TPACPI_LED_MICMUTE] = {
+ [LED_AUDIO_MICMUTE] = {
.name = "platform::micmute",
.max_brightness = 1,
.brightness_set_blocking = tpacpi_led_micmute_set,
@@ -9232,10 +9228,6 @@ static struct led_classdev mute_led_cdev[] = {
static int mute_led_init(struct ibm_init_struct *iibm)
{
- static enum led_audio types[] = {
- [TPACPI_LED_MUTE] = LED_AUDIO_MUTE,
- [TPACPI_LED_MICMUTE] = LED_AUDIO_MICMUTE,
- };
acpi_handle temp;
int i, err;
@@ -9246,7 +9238,7 @@ static int mute_led_init(struct ibm_init_struct *iibm)
continue;
}
- mute_led_cdev[i].brightness = ledtrig_audio_get(types[i]);
+ mute_led_cdev[i].brightness = ledtrig_audio_get(i);
err = led_classdev_register(_pdev->dev,
_led_cdev[i]);
if (err < 0) {
while (i--) {
diff --git a/include/linux/thinkpad_acpi.h b/include/linux/thinkpad_acpi.h
deleted file mode 100644
index 9fb317970c01..
--- a/include/linux/thinkpad_acpi.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __THINKPAD_ACPI_H__
-#define __THINKPAD_ACPI_H__
-
-/* These two functions return 0 if success, or negative error code
- (e g -ENODEV if no led present) */
-
-enum {
- TPACPI_LED_MUTE,
- TPACPI_LED_MICMUTE,
- TPACPI_LED_MAX,
-};
-
-int tpacpi_led_set(int whichled, bool on);
-
-#endif
--
2.19.1
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH v2 4/6] ALSA: hda - Support led audio trigger
Now all relevant platform drivers are providing the LED audio trigger,
we can switch the mute LED control with the LED trigger, finally.
For the mic-mute LED trigger, a common fixup function,
snd_hda_gen_fixup_micmute_led(), is provided to be called for the
corresponding quirk entries. This sets up the capture sync hook with
ledtrig_audio_set() call appropriately.
For the mute LED trigger, which is done currently only for
thinkpad_acpi, the call is replaced with ledtrig_audio_set() as well.
Overall, the beauty of the new implementation is that the whole ugly
bindings with request_symbol() are dropped, and also that it provides
more flexibility to users.
One potential behavior change by this patch is that the mute LED enum
may be created on machines that actually have no LED device. In the
former code, we did test-call and abort binding if the test failed.
But with the LED-trigger binding, this test isn't possible, and the
actual check is done in the LED class device side. So it's the
downside of simpleness.
Also, note that the HD-audio codec driver doesn't select CONFIG_LEDS
and co by itself. It's supposed to be selected by the platform
drivers instead.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
sound/pci/hda/dell_wmi_helper.c | 48 -
sound/pci/hda/hda_generic.c | 31 +
sound/pci/hda/hda_generic.h | 2 ++
sound/pci/hda/patch_realtek.c | 17 +---
sound/pci/hda/thinkpad_helper.c | 43 +
5 files changed, 46 insertions(+), 95 deletions(-)
delete mode 100644 sound/pci/hda/dell_wmi_helper.c
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
deleted file mode 100644
index bbd6c87a4ed6..
--- a/sound/pci/hda/dell_wmi_helper.c
+++ /dev/null
@@ -1,48 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/* Helper functions for Dell Mic Mute LED control;
- * to be included from codec driver
- */
-
-#if IS_ENABLED(CONFIG_DELL_LAPTOP)
-#include
-
-static int (*dell_micmute_led_set_func)(int);
-
-static void dell_micmute_update(struct hda_codec *codec)
-{
- struct hda_gen_spec *spec = codec->spec;
-
- dell_micmute_led_set_func(spec->micmute_led.led_value);
-}
-
-static void alc_fixup_dell_wmi(struct hda_codec *codec,
- const struct hda_fixup *fix, int action)
-{
- bool removefunc = false;
-
- if (action == HDA_FIXUP_ACT_PROBE) {
- if (!dell_micmute_led_set_func)
- dell_micmute_led_set_func =
symbol_request(dell_micmute_led_set);
- if (!dell_micmute_led_set_func) {
- codec_warn(codec, "Failed to find dell wmi symbol
dell_micmute_led_set\n");
- return;
- }
-
- removefunc = (dell_micmute_led_set_func(false) < 0) ||
- (snd_hda_gen_add_micmute_led(codec,
-dell_micmute_update) < 0);
- }
-
- if (dell_micmute_led_set_func && (action == HDA_FIXUP_ACT_FREE ||
removefunc)) {
- symbol_put(dell_micmute_led_set);
- dell_micmute_led_set_func = NULL;
- }
-}
-
-#else /* CONFIG_DELL_LAPTOP */
-static void alc_fixup_dell_wmi(struct hda_codec *codec,
- const struct hda_fixup *fix, int action)
-{
-}
-
-#endif /* CONFIG_DELL_LAPTOP */
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c
index 276150f29cda..4095cd7c56c6 100644
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -4035,6 +4036,36 @@ int snd_hda_gen_add_micmute_led(struct hda_codec *codec,
}
EXPORT_SYMBOL_GPL(snd_hda_gen_add_micmute_led);
+#if IS_REACHABLE(CONFIG_LEDS_TRIGGER_AUDIO)
+static void call_ledtrig_micmute(struct hda_codec *codec)
+{
+ struct hda_gen_spec *spec = codec->spec;
+
+ ledtrig_audio_set(LED_AUDIO_MICMUTE,
+ spec->micmute_led.led_value ? LED_ON : LED_OFF);
+}
+#endif
+
+/**
+ * snd_hda_gen_fixup_micmute_led - A fixup for mic-mute LED trigger
+ *
+ * Pass this function to the quirk entry if another driver supports the
+ * audio mic-mute LED trigger. Then this will bind the mixer capture switch
+ * change with the LED.
+ *
+ * Note that this fixup has to be called after other fixup that sets
+ * cap_sync_hook. Otherwise the chaining wouldn't work.
+ */
+void snd_hda_gen_fixup_micmute_led(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+{
+#if IS_REACHABLE(CONFIG_LEDS_TRIGGER_AUDIO)
+ if (action == HDA_FIXUP_ACT_PROBE)
+ snd_hda_gen_add_micmute_led(codec, call_ledtrig_micmute);
+#endif
+}
+EXPORT_SYMBOL_GPL(snd_hda_gen_fixup_micmute_led);
+
/*
* parse digital I/Os and set up NIDs in BIOS
[ibm-acpi-devel] [PATCH v2 3/6] platform/x86: thinkpad_acpi: Add audio mute LED classdev support
In the upcoming change, the binding of audio mute / mic-mute LED
controls will be switched with LED trigger. This patch is the last
piece of preparation: adding the audio mute / mic-mute LED class
devices to thinkpad_acpi driver.
Two devices, platform::mute and platform::micmute, will be added for
controlling the mute LED and mic-mute LED, respectively. The new
prefix "platform" is the suggestion by upstream for indicating the
generic laptop attribute.
Also this selects CONFIG_LEDS_TRIGGERS and CONFIG_LEDS_TRIGGERS_AUDIO
unconditionally. Strictly speaking, these aren't 100% mandatory, but
leaving these manual selections would lead to a functional regression
easily once after converting from the dynamic symbol binding to the
LEDs trigger in a later patch.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Andy Shevchenko
Acked-by: Henrique de Moraes Holschuh
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/thinkpad_acpi.c | 57 +---
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9b9cc3cc33e9..87f70e8f4dd0 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -495,6 +495,8 @@ config THINKPAD_ACPI
select NVRAM
select NEW_LEDS
select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_AUDIO
---help---
This is a driver for the IBM and Lenovo ThinkPad laptops. It adds
support for Fn-Fx key combinations, Bluetooth control, video
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index fde08a997557..3d2c1f5f22e2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9203,17 +9203,58 @@ int tpacpi_led_set(int whichled, bool on)
}
EXPORT_SYMBOL_GPL(tpacpi_led_set);
+static int tpacpi_led_mute_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ return tpacpi_led_set(TPACPI_LED_MUTE, brightness != LED_OFF);
+}
+
+static int tpacpi_led_micmute_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ return tpacpi_led_set(TPACPI_LED_MICMUTE, brightness != LED_OFF);
+}
+
+static struct led_classdev mute_led_cdev[] = {
+ [TPACPI_LED_MUTE] = {
+ .name = "platform::mute",
+ .max_brightness = 1,
+ .brightness_set_blocking = tpacpi_led_mute_set,
+ .default_trigger = "audio-mute",
+ },
+ [TPACPI_LED_MICMUTE] = {
+ .name = "platform::micmute",
+ .max_brightness = 1,
+ .brightness_set_blocking = tpacpi_led_micmute_set,
+ .default_trigger = "audio-micmute",
+ },
+};
+
static int mute_led_init(struct ibm_init_struct *iibm)
{
+ static enum led_audio types[] = {
+ [TPACPI_LED_MUTE] = LED_AUDIO_MUTE,
+ [TPACPI_LED_MICMUTE] = LED_AUDIO_MICMUTE,
+ };
acpi_handle temp;
- int i;
+ int i, err;
for (i = 0; i < TPACPI_LED_MAX; i++) {
struct tp_led_table *t = _tables[i];
- if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, )))
- mute_led_on_off(t, false);
- else
+ if (ACPI_FAILURE(acpi_get_handle(hkey_handle, t->name, )))
{
t->state = -ENODEV;
+ continue;
+ }
+
+ mute_led_cdev[i].brightness = ledtrig_audio_get(types[i]);
+ err = led_classdev_register(_pdev->dev,
_led_cdev[i]);
+ if (err < 0) {
+ while (i--) {
+ if (led_tables[i].state >= 0)
+
led_classdev_unregister(_led_cdev[i]);
+ }
+ return err;
+ }
}
return 0;
}
@@ -9222,8 +9263,12 @@ static void mute_led_exit(void)
{
int i;
- for (i = 0; i < TPACPI_LED_MAX; i++)
- tpacpi_led_set(i, false);
+ for (i = 0; i < TPACPI_LED_MAX; i++) {
+ if (led_tables[i].state >= 0) {
+ led_classdev_unregister(_led_cdev[i]);
+ tpacpi_led_set(i, false);
+ }
+ }
}
static void mute_led_resume(void)
--
2.19.1
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH v2 1/6] leds: trigger: Introduce audio mute LED trigger
This patch adds a new LED trigger for coupling the audio mixer change
with the LED on laptops or other devices. Currently there are two
trigger types, "audio-mute" and "audio-micmute".
The audio driver triggers the LED brightness change via
ledtrig_audio_set() call with the proper type (either mute or
mic-mute). OTOH, the consumers may call ledtrig_audio_get() for the
initial brightness value that may have been set by the audio driver
beforehand.
This new stuff will be used by HD-audio codec driver and some platform
drivers (thinkpad_acpi and dell-laptop, also upcoming huawei-wmi).
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Acked-by: Pali Rohár
Signed-off-by: Takashi Iwai
---
drivers/leds/trigger/Kconfig | 7 +
drivers/leds/trigger/Makefile| 1 +
drivers/leds/trigger/ledtrig-audio.c | 44
include/linux/leds.h | 20 +
4 files changed, 72 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-audio.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index b76fc3cdc8f8..23cc85e2e0e5 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -136,4 +136,11 @@ config LEDS_TRIGGER_PATTERN
which is a series of tuples, of brightness and duration (ms).
If unsure, say N
+config LEDS_TRIGGER_AUDIO
+ tristate "Audio Mute LED Trigger"
+ help
+ This allows LEDs to be controlled by audio drivers for following
+ the audio mute and mic-mute changes.
+ If unsure, say N
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 9bcb64ee8123..733a83e2a718 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
+obj-$(CONFIG_LEDS_TRIGGER_AUDIO) += ledtrig-audio.o
diff --git a/drivers/leds/trigger/ledtrig-audio.c
b/drivers/leds/trigger/ledtrig-audio.c
new file mode 100644
index ..f76621e88482
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-audio.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Audio Mute LED trigger
+//
+
+#include
+#include
+#include
+
+static struct led_trigger *ledtrig_audio[NUM_AUDIO_LEDS];
+static enum led_brightness audio_state[NUM_AUDIO_LEDS];
+
+enum led_brightness ledtrig_audio_get(enum led_audio type)
+{
+ return audio_state[type];
+}
+EXPORT_SYMBOL_GPL(ledtrig_audio_get);
+
+void ledtrig_audio_set(enum led_audio type, enum led_brightness state)
+{
+ audio_state[type] = state;
+ led_trigger_event(ledtrig_audio[type], state);
+}
+EXPORT_SYMBOL_GPL(ledtrig_audio_set);
+
+static int __init ledtrig_audio_init(void)
+{
+ led_trigger_register_simple("audio-mute",
+ _audio[LED_AUDIO_MUTE]);
+ led_trigger_register_simple("audio-micmute",
+ _audio[LED_AUDIO_MICMUTE]);
+ return 0;
+}
+module_init(ledtrig_audio_init);
+
+static void __exit ledtrig_audio_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MUTE]);
+ led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MICMUTE]);
+}
+module_exit(ledtrig_audio_exit);
+
+MODULE_DESCRIPTION("LED trigger for audio mute control");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 7393a316d9fa..580cbaef789a 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -487,4 +487,24 @@ struct led_pattern {
int brightness;
};
+enum led_audio {
+ LED_AUDIO_MUTE, /* master mute LED */
+ LED_AUDIO_MICMUTE, /* mic mute LED */
+ NUM_AUDIO_LEDS
+};
+
+#if IS_ENABLED(CONFIG_LEDS_TRIGGER_AUDIO)
+enum led_brightness ledtrig_audio_get(enum led_audio type);
+void ledtrig_audio_set(enum led_audio type, enum led_brightness state);
+#else
+static inline enum led_brightness ledtrig_audio_get(enum led_audio type)
+{
+ return LED_OFF;
+}
+static inline void ledtrig_audio_set(enum led_audio type,
+enum led_brightness state)
+{
+}
+#endif
+
#endif /* __LINUX_LEDS_H_INCLUDED */
--
2.19.1
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Hi! > > If external USB keyboard is identified as "input7" device, then > > "input7::mute" is a good name for mute key. But "sys::mute" does not say > > anything to which device or hardware it belongs nor does not solve > > problem that which device/driver/subsystem should have privilege to take > > this "sys" name. > > How about just "platform" for the LEDs being part of the device > on which the system is running? "platform" works for me. Are we in agreement that this name will be used for all similar LEDs, as long as they are on the "main box" of the device, no matter if they are connected using acpi, gpio, i2c, ...? Should we start Documentation file explaining common names we want people to use? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Hi! > > > >> A nice godfather is required here... > > > > > > > > Just use sys:: :-). > > > > > > > > laptop:: would work for me, too. (It is always laptop in the cases we > > > > are handling now, right?) > > > > > > > > When we get a keyboard with mute led, we'll have to decide if it > > > > should be input6::mute -- because it is on keyboard, or if it is > > > > sys::mute -- because the key is expected to mute whole system. > > > > > > drivers/input/input-leds.c seems to already support mute LED. > > > It will be exposed as inputN::mute. > > > > > > Documentation/leds/leds-class.txt defines LED naming pattern > > > to and "sys" does not look as > > > something resembling device name. > > > > So what is your suggestion? > > I guess we should follow documentation. Or update documentation if it > does not make sense to follow it. That's actually in progress. Let me and Jacek deal with it. We don't need great "how to name a LED" discussion here (google: bike shed paiting). > > I don't care much as long as it is same in tpacpi and dell > > case. (Neither are device names, btw :-). > > > > Actually "::mute" would make sense, too. > > "::mute" is not a good idea due to name uniqueness. > > In case you would have two drivers which both provides "mute" led, then > they need to have different name. Reason also why generic name "sys" is > not a good idea. > I think that driver name or subsystem name would be usable together with > number. > > Userspace application would be probably interested to distinguish > between "mute led which is part of laptop" and "mute led which is > available on external USB keyboard". > > If external USB keyboard is identified as "input7" device, then > "input7::mute" is a good name for mute key. But "sys::mute" does not say > anything to which device or hardware it belongs nor does not solve > problem that which device/driver/subsystem should have privilege to take > this "sys" name. Well, "sys" says this is system-wide mute LED. There are not expected to be two of those, and there never will be, with the drivers currently proposed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On 11/28/2018 09:46 PM, Pali Rohár wrote: > On Wednesday 28 November 2018 21:34:10 Pavel Machek wrote: >> Hi! >> >>> Looks good... except one detail: you have "tpacpi::micmute" and >>> "dell::micmute". I know it follows "tradition", but we are trying to >>> fix that at the moment. Laptop micmute button is a laptop micmute >>> button, and userspace should not need to know what prefix to use >>> depending on vendor. >>> >>> I'd suggest using "sys::micmute". >> >> I can imagine that in future some devices like keyboards would have also >> mute led. We already have keyboards with mute key, so it is something >> not unrealistic. What should be name convention for these mute leds? >> >> Is not "sys::" prefix too generic? > > Good point. I thought of "laptop::" but it's not always laptop. > "builtin::"? Doesn't sound great, either. > > A nice godfather is required here... Just use sys:: :-). laptop:: would work for me, too. (It is always laptop in the cases we are handling now, right?) When we get a keyboard with mute led, we'll have to decide if it should be input6::mute -- because it is on keyboard, or if it is sys::mute -- because the key is expected to mute whole system. >>> >>> drivers/input/input-leds.c seems to already support mute LED. >>> It will be exposed as inputN::mute. >>> >>> Documentation/leds/leds-class.txt defines LED naming pattern >>> to and "sys" does not look as >>> something resembling device name. >> >> So what is your suggestion? > > I guess we should follow documentation. Or update documentation if it > does not make sense to follow it. > >> I don't care much as long as it is same in tpacpi and dell >> case. (Neither are device names, btw :-). >> >> Actually "::mute" would make sense, too. > > "::mute" is not a good idea due to name uniqueness. LED core adds a numerical suffix to the original name if it is already taken. Of course it is a last resort just to avoid name clash. > In case you would have two drivers which both provides "mute" led, then > they need to have different name. Reason also why generic name "sys" is > not a good idea. > > input subsystem seems to solved this problem by appending number after > "input" word. > > I think that driver name or subsystem name would be usable together with > number. > > Userspace application would be probably interested to distinguish > between "mute led which is part of laptop" and "mute led which is > available on external USB keyboard". > > If external USB keyboard is identified as "input7" device, then > "input7::mute" is a good name for mute key. But "sys::mute" does not say > anything to which device or hardware it belongs nor does not solve > problem that which device/driver/subsystem should have privilege to take > this "sys" name. How about just "platform" for the LEDs being part of the device on which the system is running? -- Best regards, Jacek Anaszewski ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Wednesday 28 November 2018 21:34:10 Pavel Machek wrote: > Hi! > > > Looks good... except one detail: you have "tpacpi::micmute" and > > "dell::micmute". I know it follows "tradition", but we are trying to > > fix that at the moment. Laptop micmute button is a laptop micmute > > button, and userspace should not need to know what prefix to use > > depending on vendor. > > > > I'd suggest using "sys::micmute". > > >>> > > >>> I can imagine that in future some devices like keyboards would have also > > >>> mute led. We already have keyboards with mute key, so it is something > > >>> not unrealistic. What should be name convention for these mute leds? > > >>> > > >>> Is not "sys::" prefix too generic? > > >> > > >> Good point. I thought of "laptop::" but it's not always laptop. > > >> "builtin::"? Doesn't sound great, either. > > >> > > >> A nice godfather is required here... > > > > > > Just use sys:: :-). > > > > > > laptop:: would work for me, too. (It is always laptop in the cases we > > > are handling now, right?) > > > > > > When we get a keyboard with mute led, we'll have to decide if it > > > should be input6::mute -- because it is on keyboard, or if it is > > > sys::mute -- because the key is expected to mute whole system. > > > > drivers/input/input-leds.c seems to already support mute LED. > > It will be exposed as inputN::mute. > > > > Documentation/leds/leds-class.txt defines LED naming pattern > > to and "sys" does not look as > > something resembling device name. > > So what is your suggestion? I guess we should follow documentation. Or update documentation if it does not make sense to follow it. > I don't care much as long as it is same in tpacpi and dell > case. (Neither are device names, btw :-). > > Actually "::mute" would make sense, too. "::mute" is not a good idea due to name uniqueness. In case you would have two drivers which both provides "mute" led, then they need to have different name. Reason also why generic name "sys" is not a good idea. input subsystem seems to solved this problem by appending number after "input" word. I think that driver name or subsystem name would be usable together with number. Userspace application would be probably interested to distinguish between "mute led which is part of laptop" and "mute led which is available on external USB keyboard". If external USB keyboard is identified as "input7" device, then "input7::mute" is a good name for mute key. But "sys::mute" does not say anything to which device or hardware it belongs nor does not solve problem that which device/driver/subsystem should have privilege to take this "sys" name. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Hi! > Looks good... except one detail: you have "tpacpi::micmute" and > "dell::micmute". I know it follows "tradition", but we are trying to > fix that at the moment. Laptop micmute button is a laptop micmute > button, and userspace should not need to know what prefix to use > depending on vendor. > > I'd suggest using "sys::micmute". > >>> > >>> I can imagine that in future some devices like keyboards would have also > >>> mute led. We already have keyboards with mute key, so it is something > >>> not unrealistic. What should be name convention for these mute leds? > >>> > >>> Is not "sys::" prefix too generic? > >> > >> Good point. I thought of "laptop::" but it's not always laptop. > >> "builtin::"? Doesn't sound great, either. > >> > >> A nice godfather is required here... > > > > Just use sys:: :-). > > > > laptop:: would work for me, too. (It is always laptop in the cases we > > are handling now, right?) > > > > When we get a keyboard with mute led, we'll have to decide if it > > should be input6::mute -- because it is on keyboard, or if it is > > sys::mute -- because the key is expected to mute whole system. > > drivers/input/input-leds.c seems to already support mute LED. > It will be exposed as inputN::mute. > > Documentation/leds/leds-class.txt defines LED naming pattern > to and "sys" does not look as > something resembling device name. So what is your suggestion? I don't care much as long as it is same in tpacpi and dell case. (Neither are device names, btw :-). Actually "::mute" would make sense, too. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Wed, 28 Nov 2018 13:25:05 +0100, Pavel Machek wrote: > > On Wed 2018-11-28 12:38:19, Takashi Iwai wrote: > > On Wed, 28 Nov 2018 12:18:06 +0100, > > Pali Rohár wrote: > > > > > > On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote: > > > > Looks good... except one detail: you have "tpacpi::micmute" and > > > > "dell::micmute". I know it follows "tradition", but we are trying to > > > > fix that at the moment. Laptop micmute button is a laptop micmute > > > > button, and userspace should not need to know what prefix to use > > > > depending on vendor. > > > > > > > > I'd suggest using "sys::micmute". > > > > > > I can imagine that in future some devices like keyboards would have also > > > mute led. We already have keyboards with mute key, so it is something > > > not unrealistic. What should be name convention for these mute leds? > > > > > > Is not "sys::" prefix too generic? > > > > Good point. I thought of "laptop::" but it's not always laptop. > > "builtin::"? Doesn't sound great, either. > > > > A nice godfather is required here... > > Just use sys:: :-). > > laptop:: would work for me, too. (It is always laptop in the cases we > are handling now, right?) In theory, such a thing can be on all-in-one desktops, too. > When we get a keyboard with mute led, we'll have to decide if it > should be input6::mute -- because it is on keyboard, or if it is > sys::mute -- because the key is expected to mute whole system. OK, I'll wait for more comments in today and update accordingly. thanks, Takashi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Wed 2018-11-28 12:38:19, Takashi Iwai wrote: > On Wed, 28 Nov 2018 12:18:06 +0100, > Pali Rohár wrote: > > > > On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote: > > > Looks good... except one detail: you have "tpacpi::micmute" and > > > "dell::micmute". I know it follows "tradition", but we are trying to > > > fix that at the moment. Laptop micmute button is a laptop micmute > > > button, and userspace should not need to know what prefix to use > > > depending on vendor. > > > > > > I'd suggest using "sys::micmute". > > > > I can imagine that in future some devices like keyboards would have also > > mute led. We already have keyboards with mute key, so it is something > > not unrealistic. What should be name convention for these mute leds? > > > > Is not "sys::" prefix too generic? > > Good point. I thought of "laptop::" but it's not always laptop. > "builtin::"? Doesn't sound great, either. > > A nice godfather is required here... Just use sys:: :-). laptop:: would work for me, too. (It is always laptop in the cases we are handling now, right?) When we get a keyboard with mute led, we'll have to decide if it should be input6::mute -- because it is on keyboard, or if it is sys::mute -- because the key is expected to mute whole system. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Wed, 28 Nov 2018 12:18:06 +0100, Pali Rohár wrote: > > On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote: > > Looks good... except one detail: you have "tpacpi::micmute" and > > "dell::micmute". I know it follows "tradition", but we are trying to > > fix that at the moment. Laptop micmute button is a laptop micmute > > button, and userspace should not need to know what prefix to use > > depending on vendor. > > > > I'd suggest using "sys::micmute". > > I can imagine that in future some devices like keyboards would have also > mute led. We already have keyboards with mute key, so it is something > not unrealistic. What should be name convention for these mute leds? > > Is not "sys::" prefix too generic? Good point. I thought of "laptop::" but it's not always laptop. "builtin::"? Doesn't sound great, either. A nice godfather is required here... thanks, Takashi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Wed, 28 Nov 2018 12:14:34 +0100, Pali Rohár wrote: > > On Monday 26 November 2018 18:11:20 Takashi Iwai wrote: > > Hi, > > > > this is patch series I've hacked after useful conversation with > > Pavel. Basically this adds a new LED trigger audio-mute and > > audio-micmute, and convert the HD-audio driver and the platform > > drivers to use the LED trigger instead of the ugly direct dynamic > > symbol binding. > > > > The latest version of patches are found in topic/leds-trigger branch > > in my sound git tree. > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > > > As these are cross-tree patches, the branch above is based cleanly on > > v4.20-rc3, so that it can be merged well to multiple trees. > > > > Once after getting the ACK's, I'll add tags and fixate for merges. > > > > This patch series don't include huawei-wmi stuff; so Huawei patches > > need rework. I already have some piece of changes for huawei-wmi, so > > please ping me if needed. > > > > I checked briefly on my Dell laptop, and a Thinkpad model. > > Wider tests are appreciated, of course. > > Hi! Thanks for patch series. It is really improvement in current mute > led situation. I quickly looked at patches and they look good. So you > can add my Acked-By: Pali Rohár . Added your ack now. Thanks! Takashi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote: > Looks good... except one detail: you have "tpacpi::micmute" and > "dell::micmute". I know it follows "tradition", but we are trying to > fix that at the moment. Laptop micmute button is a laptop micmute > button, and userspace should not need to know what prefix to use > depending on vendor. > > I'd suggest using "sys::micmute". I can imagine that in future some devices like keyboards would have also mute led. We already have keyboards with mute key, so it is something not unrealistic. What should be name convention for these mute leds? Is not "sys::" prefix too generic? -- Pali Rohár pali.ro...@gmail.com ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
On Monday 26 November 2018 18:11:20 Takashi Iwai wrote: > Hi, > > this is patch series I've hacked after useful conversation with > Pavel. Basically this adds a new LED trigger audio-mute and > audio-micmute, and convert the HD-audio driver and the platform > drivers to use the LED trigger instead of the ugly direct dynamic > symbol binding. > > The latest version of patches are found in topic/leds-trigger branch > in my sound git tree. > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > As these are cross-tree patches, the branch above is based cleanly on > v4.20-rc3, so that it can be merged well to multiple trees. > > Once after getting the ACK's, I'll add tags and fixate for merges. > > This patch series don't include huawei-wmi stuff; so Huawei patches > need rework. I already have some piece of changes for huawei-wmi, so > please ping me if needed. > > I checked briefly on my Dell laptop, and a Thinkpad model. > Wider tests are appreciated, of course. Hi! Thanks for patch series. It is really improvement in current mute led situation. I quickly looked at patches and they look good. So you can add my Acked-By: Pali Rohár . -- Pali Rohár pali.ro...@gmail.com ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
