[alsa-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
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.
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 | 45 +++++++++++++++++++ drivers/platform/x86/Kconfig | 4 ++ drivers/platform/x86/dell-laptop.c | 27 +++++++++--- drivers/platform/x86/thinkpad_acpi.c | 66 +++++++++++++++++++++------- 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
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).
Signed-off-by: Takashi Iwai tiwai@suse.de --- drivers/leds/trigger/Kconfig | 7 +++++ drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-audio.c | 45 ++++++++++++++++++++++++++++ include/linux/leds.h | 20 +++++++++++++ 4 files changed, 73 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 000000000000..cf2b6837f570 --- /dev/null +++ b/drivers/leds/trigger/ledtrig-audio.c @@ -0,0 +1,45 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Audio Mute LED trigger +// + +#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/leds.h> + +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", + &ledtrig_audio[LED_AUDIO_MUTE]); + led_trigger_register_simple("audio-micmute", + &ledtrig_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 */
Hi Takashi,
Thank you for the patch set.
On 11/26/2018 06:11 PM, Takashi Iwai wrote:
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).
Signed-off-by: Takashi Iwai tiwai@suse.de
drivers/leds/trigger/Kconfig | 7 +++++ drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-audio.c | 45 ++++++++++++++++++++++++++++ include/linux/leds.h | 20 +++++++++++++ 4 files changed, 73 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 followingthe audio mute and mic-mute changes.If unsure, say Nendif # 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 000000000000..cf2b6837f570 --- /dev/null +++ b/drivers/leds/trigger/ledtrig-audio.c @@ -0,0 +1,45 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Audio Mute LED trigger +//
+#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/leds.h>
+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",
&ledtrig_audio[LED_AUDIO_MUTE]);- led_trigger_register_simple("audio-micmute",
&ledtrig_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 */
For this patch and FWIW for the whole patch set:
Acked-by: Jacek Anaszewski jacek.anaszewski@gmail.com
On Mon, 26 Nov 2018 21:59:24 +0100, Jacek Anaszewski wrote:
For this patch and FWIW for the whole patch set:
Acked-by: Jacek Anaszewski jacek.anaszewski@gmail.com
Thanks, now added to the series.
The latest patches are found in topic/leds-trigger branch of my sound git tree.
I'm going to resubmit v2 series tomorrow or later, then merge the branch to for-next branch.
Takashi
On Mon, Nov 26, 2018 at 7:14 PM Takashi Iwai tiwai@suse.de wrote:
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).
+#include <linux/module.h>
+#include <linux/init.h>
Only on of above is needed, I think you meant module.h.
On Mon, 26 Nov 2018 23:58:36 +0100, Andy Shevchenko wrote:
On Mon, Nov 26, 2018 at 7:14 PM Takashi Iwai tiwai@suse.de wrote:
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).
+#include <linux/module.h>
+#include <linux/init.h>
Only on of above is needed, I think you meant module.h.
Right, dropped init.h inclusion. Also sorted now.
thanks,
Takashi
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 "dell::micmute" sysfs entry. 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.
Signed-off-by: Takashi Iwai tiwai@suse.de --- 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..6a647e2d09ee 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 = "dell::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(&dell_laptop_notifier);
+ micmute_led_cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE); + ret = led_classdev_register(&platform_device->dev, &micmute_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(&micmute_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(&micmute_led_cdev); dell_cleanup_rfkill(); if (platform_device) { platform_device_unregister(platform_device);
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, tpacpi::mute and tpacpi::micmute, will be added for controlling the mute LED and mic-mute LED, respectively.
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.
Signed-off-by: Takashi Iwai tiwai@suse.de --- drivers/platform/x86/Kconfig | 2 + drivers/platform/x86/thinkpad_acpi.c | 56 +++++++++++++++++++++++++--- 2 files changed, 52 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..3c09afae1248 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -9203,17 +9203,57 @@ 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 = "tpacpi::mute", + .max_brightness = 1, + .brightness_set_blocking = tpacpi_led_mute_set, + .default_trigger = "audio-mute", + }, + [TPACPI_LED_MICMUTE] = { + .name = "tpacpi::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 = &led_tables[i]; - if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) - mute_led_on_off(t, false); - else + if (!ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) { t->state = -ENODEV; + continue; + } + + mute_led_cdev[i].brightness = ledtrig_audio_get(types[i]); + err = led_classdev_register(&tpacpi_pdev->dev, &mute_led_cdev[i]); + if (err < 0) { + while (--i >= 0) + if (led_tables[i].state >= 0) + led_classdev_unregister(&mute_led_cdev[i]); + return err; + } } return 0; } @@ -9222,8 +9262,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(&mute_led_cdev[i]); + tpacpi_led_set(i, false); + } + } }
static void mute_led_resume(void)
On Mon, Nov 26, 2018 at 7:13 PM Takashi Iwai tiwai@suse.de wrote:
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, tpacpi::mute and tpacpi::micmute, will be added for controlling the mute LED and mic-mute LED, respectively.
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.
if (!ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) {
ACPI_FAILURE()
t->state = -ENODEV;
continue;}
err = led_classdev_register(&tpacpi_pdev->dev, &mute_led_cdev[i]);if (err < 0) {
while (--i >= 0)
Needs { } due to two liner below.
Might be converted to simple
while (i--) { ... }
btw.
if (led_tables[i].state >= 0)led_classdev_unregister(&mute_led_cdev[i]);return err;}
-- With Best Regards, Andy Shevchenko
On Tue, 27 Nov 2018 00:04:40 +0100, Andy Shevchenko wrote:
On Mon, Nov 26, 2018 at 7:13 PM Takashi Iwai tiwai@suse.de wrote:
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, tpacpi::mute and tpacpi::micmute, will be added for controlling the mute LED and mic-mute LED, respectively.
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.
if (!ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) {ACPI_FAILURE()
t->state = -ENODEV;
continue;}
err = led_classdev_register(&tpacpi_pdev->dev, &mute_led_cdev[i]);if (err < 0) {
while (--i >= 0)Needs { } due to two liner below.
Might be converted to simple
while (i--) { ... }
btw.
Both addressed now. Thanks.
Takashi
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 he whole ugly binding with request_symbol() are dropped, and also 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.
Signed-off-by: Takashi Iwai tiwai@suse.de --- 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..000000000000 --- 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 <linux/dell-led.h> - -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 <linux/string.h> #include <linux/bitops.h> #include <linux/module.h> +#include <linux/leds.h> #include <sound/core.h> #include <sound/jack.h> #include <sound/tlv.h> @@ -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 auto-parse mode */ diff --git a/sound/pci/hda/hda_generic.h b/sound/pci/hda/hda_generic.h index 10123664fa61..78d77042b05a 100644 --- a/sound/pci/hda/hda_generic.h +++ b/sound/pci/hda/hda_generic.h @@ -357,5 +357,7 @@ int snd_hda_gen_fix_pin_power(struct hda_codec *codec, hda_nid_t pin);
int snd_hda_gen_add_micmute_led(struct hda_codec *codec, void (*hook)(struct hda_codec *)); +void snd_hda_gen_fixup_micmute_led(struct hda_codec *codec, + const struct hda_fixup *fix, int action);
#endif /* __SOUND_HDA_GENERIC_H */ diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fa61674a5605..993d34c141c2 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5368,9 +5368,6 @@ static void alc_fixup_thinkpad_acpi(struct hda_codec *codec, hda_fixup_thinkpad_acpi(codec, fix, action); }
-/* for dell wmi mic mute led */ -#include "dell_wmi_helper.c" - /* for alc295_fixup_hp_top_speakers */ #include "hp_x360_helper.c"
@@ -5448,7 +5445,7 @@ enum { ALC292_FIXUP_TPT440_DOCK, ALC292_FIXUP_TPT440, ALC283_FIXUP_HEADSET_MIC, - ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED, + ALC255_FIXUP_MIC_MUTE_LED, ALC282_FIXUP_ASPIRE_V5_PINS, ALC280_FIXUP_HP_GPIO4, ALC286_FIXUP_HP_GPIO_LED, @@ -5740,7 +5737,7 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode, .chained = true, - .chain_id = ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED + .chain_id = ALC255_FIXUP_MIC_MUTE_LED }, [ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC] = { .type = HDA_FIXUP_FUNC, @@ -5966,7 +5963,7 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode_alc255, .chained = true, - .chain_id = ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED + .chain_id = ALC255_FIXUP_MIC_MUTE_LED }, [ALC255_FIXUP_HEADSET_MODE_NO_HP_MIC] = { .type = HDA_FIXUP_FUNC, @@ -6001,9 +5998,9 @@ static const struct hda_fixup alc269_fixups[] = { { }, }, }, - [ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED] = { + [ALC255_FIXUP_MIC_MUTE_LED] = { .type = HDA_FIXUP_FUNC, - .v.func = alc_fixup_dell_wmi, + .v.func = snd_hda_gen_fixup_micmute_led, }, [ALC282_FIXUP_ASPIRE_V5_PINS] = { .type = HDA_FIXUP_PINS, @@ -6062,7 +6059,7 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode_dell_alc288, .chained = true, - .chain_id = ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED + .chain_id = ALC255_FIXUP_MIC_MUTE_LED }, [ALC288_FIXUP_DELL1_MIC_NO_PRESENCE] = { .type = HDA_FIXUP_PINS, @@ -6719,7 +6716,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC255_FIXUP_DELL2_MIC_NO_PRESENCE, .name = "alc255-dell2"}, {.id = ALC293_FIXUP_DELL1_MIC_NO_PRESENCE, .name = "alc293-dell1"}, {.id = ALC283_FIXUP_HEADSET_MIC, .name = "alc283-headset"}, - {.id = ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED, .name = "alc255-dell-mute"}, + {.id = ALC255_FIXUP_MIC_MUTE_LED, .name = "alc255-dell-mute"}, {.id = ALC282_FIXUP_ASPIRE_V5_PINS, .name = "aspire-v5"}, {.id = ALC280_FIXUP_HP_GPIO4, .name = "hp-gpio4"}, {.id = ALC286_FIXUP_HP_GPIO_LED, .name = "hp-gpio-led"}, diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c index 568575b72f2f..4089feb8c68e 100644 --- a/sound/pci/hda/thinkpad_helper.c +++ b/sound/pci/hda/thinkpad_helper.c @@ -3,12 +3,11 @@ * to be included from codec driver */
-#if IS_ENABLED(CONFIG_THINKPAD_ACPI) +#if IS_ENABLED(CONFIG_THINKPAD_ACPI) && IS_REACHABLE(CONFIG_LEDS_TRIGGER_AUDIO)
#include <linux/acpi.h> -#include <linux/thinkpad_acpi.h> +#include <linux/leds.h>
-static int (*led_set_func)(int, bool); static void (*old_vmaster_hook)(void *, int);
static bool is_thinkpad(struct hda_codec *codec) @@ -23,50 +22,20 @@ static void update_tpacpi_mute_led(void *private_data, int enabled) if (old_vmaster_hook) old_vmaster_hook(private_data, enabled);
- if (led_set_func) - led_set_func(TPACPI_LED_MUTE, !enabled); -} - -static void update_tpacpi_micmute(struct hda_codec *codec) -{ - struct hda_gen_spec *spec = codec->spec; - - led_set_func(TPACPI_LED_MICMUTE, spec->micmute_led.led_value); + ledtrig_audio_set(LED_AUDIO_MUTE, enabled ? LED_OFF : LED_ON); }
static void hda_fixup_thinkpad_acpi(struct hda_codec *codec, const struct hda_fixup *fix, int action) { struct hda_gen_spec *spec = codec->spec; - bool removefunc = false;
if (action == HDA_FIXUP_ACT_PROBE) { if (!is_thinkpad(codec)) return; - if (!led_set_func) - led_set_func = symbol_request(tpacpi_led_set); - if (!led_set_func) { - codec_warn(codec, - "Failed to find thinkpad-acpi symbol tpacpi_led_set\n"); - return; - } - - removefunc = true; - if (led_set_func(TPACPI_LED_MUTE, false) >= 0) { - old_vmaster_hook = spec->vmaster_mute.hook; - spec->vmaster_mute.hook = update_tpacpi_mute_led; - removefunc = false; - } - if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0 && - !snd_hda_gen_add_micmute_led(codec, - update_tpacpi_micmute)) - removefunc = false; - } - - if (led_set_func && (action == HDA_FIXUP_ACT_FREE || removefunc)) { - symbol_put(tpacpi_led_set); - led_set_func = NULL; - old_vmaster_hook = NULL; + old_vmaster_hook = spec->vmaster_mute.hook; + spec->vmaster_mute.hook = update_tpacpi_mute_led; + snd_hda_gen_fixup_micmute_led(codec, fix, action); } }
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.
Signed-off-by: Takashi Iwai tiwai@suse.de --- 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 6a647e2d09ee..40236895b263 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -29,7 +29,6 @@ #include <linux/mm.h> #include <linux/i8042.h> #include <linux/debugfs.h> -#include <linux/dell-led.h> #include <linux/seq_file.h> #include <acpi/video.h> #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(&buffer, token->location, token->value, 0, 0); dell_send_request(&buffer, 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..000000000000 --- 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
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.
Signed-off-by: Takashi Iwai tiwai@suse.de --- 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 3c09afae1248..0113873dfd13 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -81,7 +81,6 @@ #include <linux/acpi.h> #include <linux/pci_ids.h> #include <linux/power_supply.h> -#include <linux/thinkpad_acpi.h> #include <sound/core.h> #include <sound/control.h> #include <sound/initval.h> @@ -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 = &led_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 = "tpacpi::mute", .max_brightness = 1, .brightness_set_blocking = tpacpi_led_mute_set, .default_trigger = "audio-mute", }, - [TPACPI_LED_MICMUTE] = { + [LED_AUDIO_MICMUTE] = { .name = "tpacpi::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(&tpacpi_pdev->dev, &mute_led_cdev[i]); if (err < 0) { while (--i >= 0) diff --git a/include/linux/thinkpad_acpi.h b/include/linux/thinkpad_acpi.h deleted file mode 100644 index 9fb317970c01..000000000000 --- 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
On Mon, Nov 26, 2018 at 7:14 PM Takashi Iwai tiwai@suse.de 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.
Few minor comments, otherwise I like this series. Acked-by: Andy Shevchenko andy.shevchenko@gmail.com for PDx86 bits.
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 | 45 +++++++++++++++++++ drivers/platform/x86/Kconfig | 4 ++ drivers/platform/x86/dell-laptop.c | 27 +++++++++--- drivers/platform/x86/thinkpad_acpi.c | 66 +++++++++++++++++++++------- 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
On Tue, 27 Nov 2018 00:09:17 +0100, Andy Shevchenko wrote:
On Mon, Nov 26, 2018 at 7:14 PM Takashi Iwai tiwai@suse.de 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.
Few minor comments, otherwise I like this series. Acked-by: Andy Shevchenko andy.shevchenko@gmail.com for PDx86 bits.
Thanks, added your ack to platform patches.
The latest patches are found in topic/leds-trigger branch of my sound git tree.
I'm going to resubmit v2 series tomorrow or later, then merge the branch to for-next branch.
Takashi
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.
Thanks a lot for doing this!
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.
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".
With that:
Acked-by: Pavel Machek pavel@ucw.cz
Pavel
On Tue, 27 Nov 2018 09:44:18 +0100, Pavel Machek 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.
Thanks a lot for doing this!
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.
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".
OK, replaced them, and also add explanation in the patch logs.
With that:
Acked-by: Pavel Machek pavel@ucw.cz
Added now to the series in topic/leds-trigger branch.
I'm going to resubmit v2 series tomorrow or later, then merge the branch to for-next branch.
Thanks!
Takashi
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?
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
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
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
On Wed, Nov 28, 2018 at 2:59 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 28 Nov 2018 13:25:05 +0100,
On Wed 2018-11-28 12:38:19, Takashi Iwai wrote:
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.
sys sounds plausible to me. In any case we may revisit in the future if something happens to it. OTOH it would be part of ABI, right?
On 11/28/2018 01:25 PM, 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?)
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 devicename:color:function and "sys" does not look as something resembling device name.
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 devicename:color:function 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
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 devicename:color:function 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.
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 devicename:color:function 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?
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
On 11/28/2018 10:22 PM, Pavel Machek wrote:
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, ...?
One doubt: say we have hdd activity LED on the "main box" - it would be named "platform::disk".
Now, we add external USB disk. Previously we were considering the naming for disk LEDs in the form e.g. "sdb::disk".
If so, there would be discrepancy between internal and external disk LED names. Similarly in case of eth/adsl/wlan/camera LEDs.
Regarding sound devices - how would we name micmute LED for USB microphone? I suppose that it is possible to discover some unique identifier in runtime - this is a question to ALSA people.
On Thu, 29 Nov 2018 22:23:31 +0100, Jacek Anaszewski wrote:
On 11/28/2018 10:22 PM, Pavel Machek wrote:
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, ...?
One doubt: say we have hdd activity LED on the "main box" - it would be named "platform::disk".
Now, we add external USB disk. Previously we were considering the naming for disk LEDs in the form e.g. "sdb::disk".
If so, there would be discrepancy between internal and external disk LED names. Similarly in case of eth/adsl/wlan/camera LEDs.
Regarding sound devices - how would we name micmute LED for USB microphone? I suppose that it is possible to discover some unique identifier in runtime - this is a question to ALSA people.
There are little USB-audio devices supporting the LED control, so we haven't had any chance for LED class for USB-audio.
At most, we may create LED class devices for some HD-audio (usually driven via exotic verbs or GPIO over HD-audio), but I wouldn't go in that direction; it'll need too make things more complex than the direct hook as of now.
thanks,
Takashi
On Thu, Nov 29, 2018 at 10:23:31PM +0100, Jacek Anaszewski wrote:
Regarding sound devices - how would we name micmute LED for USB microphone? I suppose that it is possible to discover some unique identifier in runtime - this is a question to ALSA people.
USB path (e.g. 2-1.1.2.4.3) + '::' + name ?
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, ...?
One doubt: say we have hdd activity LED on the "main box" - it would be named "platform::disk".
Now, we add external USB disk. Previously we were considering the naming for disk LEDs in the form e.g. "sdb::disk".
If so, there would be discrepancy between internal and external disk LED names. Similarly in case of eth/adsl/wlan/camera LEDs.
Well, it really depends if the "plaform::disk" is for all the disks, or if it is for sda. In the second case, it might be better to name it sda::disk...
Anyway... I believe we should start documenting good and bad LEDs, so that patch authors know what is there, and can try to be consistent, and so that userland knows what names to probe for.
What about following? Any other LEDs worth mentioning?
commit c56708addf9c312cefd760bca218a0545258b217 Author: Pavel pavel@ucw.cz Date: Sat Dec 1 15:32:13 2018 +0100
leds: Add list of well-known LED names
Signed-off-by: Pavel Machek pavel@ucw.cz
diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt new file mode 100644 index 0000000..9a262db --- /dev/null +++ b/Documentation/leds/well-known-leds.txt @@ -0,0 +1,42 @@ +-*- org -*- + +It is somehow important to provide consistent interface to the +userland. LED devices have one problem there, and that is naming of +directories in /sys/class/leds. It would be nice if userland would +just know right "name" for given LED function, but situation got more +complex. + +Anyway, if backwards compatibility is not an issue, new code should +use one of the "good" names from this list, and you should extend the +list where applicable. + +Bad names are listed, too, in case you are writing application that +wants to use particular feature, you should probe for good name first +but then try the bad ones, too". + +* Keyboards + +Good: "input*:*:capslock" +Good: "input*:*:scrolllock" +Good: "input*:*:numlock" + +Set of common keyboard LEDs, going back to PC AT or so. + +Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads) +Bad: "lp5523:kb{1,2,3,4,5,6,7}" (Nokia N900) + +Keyboard frontlight/backlight. + +* Sound subsystem + +Good: "platform:*:mute" +Good: "platform:*:micmute" + +LEDs on notebook body, indicating that sound input / output is muted. + +* System notification + +Good: "status-led:{red,green,blue}" (Motorola Droid 4) +Bad: "lp5523:{r,g,b}" (Nokia N900) + +Phones usually have multi-color status LED.
Hi Pavel,
On 12/1/18 3:41 PM, Pavel Machek wrote:
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, ...?
One doubt: say we have hdd activity LED on the "main box" - it would be named "platform::disk".
Now, we add external USB disk. Previously we were considering the naming for disk LEDs in the form e.g. "sdb::disk".
If so, there would be discrepancy between internal and external disk LED names. Similarly in case of eth/adsl/wlan/camera LEDs.
Well, it really depends if the "plaform::disk" is for all the disks, or if it is for sda. In the second case, it might be better to name it sda::disk...
Anyway... I believe we should start documenting good and bad LEDs, so that patch authors know what is there, and can try to be consistent, and so that userland knows what names to probe for.
The idea looks reasonable. In addition to that, I'd change one thing in the LED naming pattern - replace "devicename " with "affiliation". AFAICS that would fit best for both "platform" and e.g. "input*".
Also in the DT we would need related "affiliation" property. In most cases it would be "platform" probably. Possible is also "camera" - but we would have to state it clear how to proceed in case of video devices - shouldn't v4l2 drivers create LEDs similarly to how network drivers do that. Then it would be possible to provide videoN name.
What about following? Any other LEDs worth mentioning?
disk: sdX network devices: ethN, adslN
These "affiliations" would have to be provided by the network drivers creating LED class devices.
commit c56708addf9c312cefd760bca218a0545258b217 Author: Pavel pavel@ucw.cz Date: Sat Dec 1 15:32:13 2018 +0100
leds: Add list of well-known LED names
Signed-off-by: Pavel Machek pavel@ucw.cz
diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt new file mode 100644 index 0000000..9a262db --- /dev/null +++ b/Documentation/leds/well-known-leds.txt @@ -0,0 +1,42 @@ +-*- org -*-
+It is somehow important to provide consistent interface to the +userland. LED devices have one problem there, and that is naming of +directories in /sys/class/leds. It would be nice if userland would +just know right "name" for given LED function, but situation got more +complex.
+Anyway, if backwards compatibility is not an issue, new code should +use one of the "good" names from this list, and you should extend the +list where applicable.
+Bad names are listed, too, in case you are writing application that +wants to use particular feature, you should probe for good name first +but then try the bad ones, too".
+* Keyboards
+Good: "input*:*:capslock" +Good: "input*:*:scrolllock" +Good: "input*:*:numlock"
+Set of common keyboard LEDs, going back to PC AT or so.
+Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads) +Bad: "lp5523:kb{1,2,3,4,5,6,7}" (Nokia N900)
+Keyboard frontlight/backlight.
Isn't example missing here?
+* Sound subsystem
+Good: "platform:*:mute" +Good: "platform:*:micmute"
+LEDs on notebook body, indicating that sound input / output is muted.
+* System notification
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
Two problems here: - "status-led" is in place of "devicename" instead of "function" - "-led" is obvious and non-generic - we will have "status" in the "functions.h"
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+Phones usually have multi-color status LED.
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 devicename:color:function 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
On Mon, 26 Nov 2018, Takashi Iwai wrote:
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.
For the thinkpad-acpi bits, provided that Andy's comments are addressed: Acked-by: Henrique de Moraes Holschuh hmh@hmh.eng.br
I checked briefly on my Dell laptop, and a Thinkpad model.
Thanks :-)
On Tue, 27 Nov 2018 11:26:32 +0100, Henrique de Moraes Holschuh wrote:
On Mon, 26 Nov 2018, Takashi Iwai wrote:
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.
For the thinkpad-acpi bits, provided that Andy's comments are addressed: Acked-by: Henrique de Moraes Holschuh hmh@hmh.eng.br
Thanks, added now to topic/leds-trigger branch.
I'm going to resubmit v2 series tomorrow or later, then merge the branch to for-next branch.
Takashi
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.rohar@gmail.com.
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 pali.rohar@gmail.com.
Added your ack now. Thanks!
Takashi
participants (7)
-
Andy Shevchenko -
Andy Shevchenko -
Henrique de Moraes Holschuh -
Jacek Anaszewski -
Pali Rohár -
Pavel Machek -
Takashi Iwai