Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Randy Dunlap]

On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> On 14-10-2020 07:07, Randy Dunlap wrote:
>> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> 
>>> I.e.: it looks like I will lose some funcionality when I disable
>>> SND_HDA_CODEC_REALTEK.
>>
>> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
>> with no LEDS. That driver apparently wants LEDS.
> 
> Thanks but why have I gone for years without LEDS?
> I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> visible, usable, etc).
> 
> Please make this selectable instead of forcing more bulk into my kernel.
> 
> Kind regards,
> Udo

Hi Takashi,

Regarding
commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jun 18 13:08:31 2020 +0200
    ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev

and this Kconfig entry:

config SND_HDA_CODEC_REALTEK
	tristate "Build Realtek HD-audio codec support"
	select SND_HDA_GENERIC
	select SND_HDA_GENERIC_LEDS

it seems that LED support is not always wanted (please see above).
I.e., user(s) would like to build a kernel without LED support at all.

Can you make it a build option?

thanks.
-- 
~Randy

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 07:54:15 +0200,
Randy Dunlap wrote:
> 
> On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > On 14-10-2020 07:07, Randy Dunlap wrote:
> >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> > 
> >>> I.e.: it looks like I will lose some funcionality when I disable
> >>> SND_HDA_CODEC_REALTEK.
> >>
> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> >> with no LEDS. That driver apparently wants LEDS.
> > 
> > Thanks but why have I gone for years without LEDS?
> > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > visible, usable, etc).
> > 
> > Please make this selectable instead of forcing more bulk into my kernel.
> > 
> > Kind regards,
> > Udo
> 
> Hi Takashi,
> 
> Regarding
> commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> Author: Takashi Iwai <tiwai@suse.de>
> Date:   Thu Jun 18 13:08:31 2020 +0200
>     ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev
> 
> and this Kconfig entry:
> 
> config SND_HDA_CODEC_REALTEK
> 	tristate "Build Realtek HD-audio codec support"
> 	select SND_HDA_GENERIC
> 	select SND_HDA_GENERIC_LEDS
> 
> it seems that LED support is not always wanted (please see above).
> I.e., user(s) would like to build a kernel without LED support at all.
> 
> Can you make it a build option?

Something like this?


Takashi

---
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1390,6 +1390,11 @@ menuconfig EXPERT
 	  environments which can tolerate a "non-standard" kernel.
 	  Only use this if you really know what you are doing.
 
+config SUPERHACKER
+	bool "Rule the world" if EXPERT
+	help
+	  You are allowed to break things at your own risk.
+
 config UID16
 	bool "Enable 16-bit UID system calls" if EXPERT
 	depends on HAVE_UID16 && MULTIUSER
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -94,7 +94,7 @@ config SND_HDA_PATCH_LOADER
 config SND_HDA_CODEC_REALTEK
 	tristate "Build Realtek HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !SUPERHACKER
 	help
 	  Say Y or M here to include Realtek HD-audio codec support in
 	  snd-hda-intel driver, such as ALC880.
@@ -115,7 +115,7 @@ comment "Set to Y if you want auto-loading the codec driver"
 config SND_HDA_CODEC_SIGMATEL
 	tristate "Build IDT/Sigmatel HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !SUPERHACKER
 	help
 	  Say Y or M here to include IDT (Sigmatel) HD-audio codec support in
 	  snd-hda-intel driver, such as STAC9200.
@@ -160,7 +160,7 @@ comment "Set to Y if you want auto-loading the codec driver"
 config SND_HDA_CODEC_CONEXANT
 	tristate "Build Conexant HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !SUPERHACKER
 	help
 	  Say Y or M here to include Conexant HD-audio codec support in
 	  snd-hda-intel driver, such as CX20549.
--- a/sound/pci/hda/hda_generic.h
+++ b/sound/pci/hda/hda_generic.h
@@ -354,11 +354,29 @@ unsigned int snd_hda_gen_path_power_filter(struct hda_codec *codec,
 void snd_hda_gen_stream_pm(struct hda_codec *codec, hda_nid_t nid, bool on);
 int snd_hda_gen_fix_pin_power(struct hda_codec *codec, hda_nid_t pin);
 
+#ifdef CONFIG_SND_HDA_GENERIC_LEDS
 int snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
 				  int (*callback)(struct led_classdev *,
 						  enum led_brightness));
 int snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
 				     int (*callback)(struct led_classdev *,
 						     enum led_brightness));
+#else /* CONFIG_SND_HDA_GENERIC_LEDS */
+static inline int
+snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
+			      int (*callback)(struct led_classdev *,
+					      enum led_brightness))
+{
+	return -ENODEV;
+}
+
+static inline int
+snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
+				 int (*callback)(struct led_classdev *,
+						 enum led_brightness))
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_SND_HDA_GENERIC_LEDS */
 
 #endif /* __SOUND_HDA_GENERIC_H */

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 09:49:49 +0200,
Takashi Iwai wrote:
> 
> On Wed, 14 Oct 2020 07:54:15 +0200,
> Randy Dunlap wrote:
> > 
> > On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > > On 14-10-2020 07:07, Randy Dunlap wrote:
> > >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> > > 
> > >>> I.e.: it looks like I will lose some funcionality when I disable
> > >>> SND_HDA_CODEC_REALTEK.
> > >>
> > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > >> with no LEDS. That driver apparently wants LEDS.
> > > 
> > > Thanks but why have I gone for years without LEDS?
> > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > visible, usable, etc).
> > > 
> > > Please make this selectable instead of forcing more bulk into my kernel.
> > > 
> > > Kind regards,
> > > Udo
> > 
> > Hi Takashi,
> > 
> > Regarding
> > commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> > Author: Takashi Iwai <tiwai@suse.de>
> > Date:   Thu Jun 18 13:08:31 2020 +0200
> >     ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev
> > 
> > and this Kconfig entry:
> > 
> > config SND_HDA_CODEC_REALTEK
> > 	tristate "Build Realtek HD-audio codec support"
> > 	select SND_HDA_GENERIC
> > 	select SND_HDA_GENERIC_LEDS
> > 
> > it seems that LED support is not always wanted (please see above).
> > I.e., user(s) would like to build a kernel without LED support at all.
> > 
> > Can you make it a build option?
> 
> Something like this?

This one is more suitable for the merge :)


Takashi

---
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -94,7 +94,7 @@ config SND_HDA_PATCH_LOADER
 config SND_HDA_CODEC_REALTEK
 	tristate "Build Realtek HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !EXPERT
 	help
 	  Say Y or M here to include Realtek HD-audio codec support in
 	  snd-hda-intel driver, such as ALC880.
@@ -115,7 +115,7 @@ comment "Set to Y if you want auto-loading the codec driver"
 config SND_HDA_CODEC_SIGMATEL
 	tristate "Build IDT/Sigmatel HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !EXPERT
 	help
 	  Say Y or M here to include IDT (Sigmatel) HD-audio codec support in
 	  snd-hda-intel driver, such as STAC9200.
@@ -160,7 +160,7 @@ comment "Set to Y if you want auto-loading the codec driver"
 config SND_HDA_CODEC_CONEXANT
 	tristate "Build Conexant HD-audio codec support"
 	select SND_HDA_GENERIC
-	select SND_HDA_GENERIC_LEDS
+	select SND_HDA_GENERIC_LEDS if !EXPERT
 	help
 	  Say Y or M here to include Conexant HD-audio codec support in
 	  snd-hda-intel driver, such as CX20549.
--- a/sound/pci/hda/hda_generic.h
+++ b/sound/pci/hda/hda_generic.h
@@ -354,11 +354,29 @@ unsigned int snd_hda_gen_path_power_filter(struct hda_codec *codec,
 void snd_hda_gen_stream_pm(struct hda_codec *codec, hda_nid_t nid, bool on);
 int snd_hda_gen_fix_pin_power(struct hda_codec *codec, hda_nid_t pin);
 
+#ifdef CONFIG_SND_HDA_GENERIC_LEDS
 int snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
 				  int (*callback)(struct led_classdev *,
 						  enum led_brightness));
 int snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
 				     int (*callback)(struct led_classdev *,
 						     enum led_brightness));
+#else /* CONFIG_SND_HDA_GENERIC_LEDS */
+static inline int
+snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
+			      int (*callback)(struct led_classdev *,
+					      enum led_brightness))
+{
+	return -ENODEV;
+}
+
+static inline int
+snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
+				 int (*callback)(struct led_classdev *,
+						 enum led_brightness))
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_SND_HDA_GENERIC_LEDS */
 
 #endif /* __SOUND_HDA_GENERIC_H */

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

Hi!

> >>> I.e.: it looks like I will lose some funcionality when I disable
> >>> SND_HDA_CODEC_REALTEK.
> >>
> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> >> with no LEDS. That driver apparently wants LEDS.
> > 
> > Thanks but why have I gone for years without LEDS?
> > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > visible, usable, etc).
> > 
> > Please make this selectable instead of forcing more bulk into my
>> kernel.

LED core is not that big, and this avoided some rather "interesting"
hacks IIRC. If Udo wants more config complexity, lets first make him
measure the benefits, second submit a patch.

But I'd suggest to just live with it.

And yes, we should probably get rid of "CONFIG_NEW_LEDS" symbol. That
one is actually useless.

Best regards,
								Pavel
								
> and this Kconfig entry:
> 
> config SND_HDA_CODEC_REALTEK
> 	tristate "Build Realtek HD-audio codec support"
> 	select SND_HDA_GENERIC
> 	select SND_HDA_GENERIC_LEDS
> 
> it seems that LED support is not always wanted (please see above).
> I.e., user(s) would like to build a kernel without LED support at all.
> 
> Can you make it a build option?
> 
> thanks.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

Hi!

> > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > >>> SND_HDA_CODEC_REALTEK.
> > > >>
> > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > >> with no LEDS. That driver apparently wants LEDS.
> > > > 
> > > > Thanks but why have I gone for years without LEDS?
> > > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > > visible, usable, etc).
> > > > 
> > > > Please make this selectable instead of forcing more bulk into my kernel.
> > > 
> > > Hi Takashi,
> > > 
> > > Regarding
> > > commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> > > Author: Takashi Iwai <tiwai@suse.de>
> > > Date:   Thu Jun 18 13:08:31 2020 +0200
> > >     ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev
> > > 
> > > and this Kconfig entry:
> > > 
> > > config SND_HDA_CODEC_REALTEK
> > > 	tristate "Build Realtek HD-audio codec support"
> > > 	select SND_HDA_GENERIC
> > > 	select SND_HDA_GENERIC_LEDS
> > > 
> > > it seems that LED support is not always wanted (please see above).
> > > I.e., user(s) would like to build a kernel without LED support at all.
> > > 
> > > Can you make it a build option?
> > 
> > Something like this?
> 
> This one is more suitable for the merge :)

That will still break the build if SND_HDA_CODEC_REALTEK=y and
SND_HDA_GENERIC_LEDS=m, no?

Lets keep things as they are.

Contrary to his claims, Udo very probably has LEDs in his systems...


							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 09:58:53 +0200,
Pavel Machek wrote:
> 
> Hi!
> 
> > > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > > >>> SND_HDA_CODEC_REALTEK.
> > > > >>
> > > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > > >> with no LEDS. That driver apparently wants LEDS.
> > > > > 
> > > > > Thanks but why have I gone for years without LEDS?
> > > > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > > > visible, usable, etc).
> > > > > 
> > > > > Please make this selectable instead of forcing more bulk into my kernel.
> > > > 
> > > > Hi Takashi,
> > > > 
> > > > Regarding
> > > > commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> > > > Author: Takashi Iwai <tiwai@suse.de>
> > > > Date:   Thu Jun 18 13:08:31 2020 +0200
> > > >     ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev
> > > > 
> > > > and this Kconfig entry:
> > > > 
> > > > config SND_HDA_CODEC_REALTEK
> > > > 	tristate "Build Realtek HD-audio codec support"
> > > > 	select SND_HDA_GENERIC
> > > > 	select SND_HDA_GENERIC_LEDS
> > > > 
> > > > it seems that LED support is not always wanted (please see above).
> > > > I.e., user(s) would like to build a kernel without LED support at all.
> > > > 
> > > > Can you make it a build option?
> > > 
> > > Something like this?
> > 
> > This one is more suitable for the merge :)
> 
> That will still break the build if SND_HDA_CODEC_REALTEK=y and
> SND_HDA_GENERIC_LEDS=m, no?

SND_HDA_GENERIC_LEDS is a bool, and this selects the actual LEDS_*
stuff from SND_HDA_GENERIC, so the builtin vs module problem shouldn't
happen.  So I don't think the suggested patch would break builds.
It'll hit an error at probe if the hardware actually uses the LEDs.

> Lets keep things as they are.
> 
> Contrary to his claims, Udo very probably has LEDs in his systems...

Heh, a surprise :)


thanks,

Takashi

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 09:54:59 +0200,
Pavel Machek wrote:
> 
> Hi!
> 
> > >>> I.e.: it looks like I will lose some funcionality when I disable
> > >>> SND_HDA_CODEC_REALTEK.
> > >>
> > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > >> with no LEDS. That driver apparently wants LEDS.
> > > 
> > > Thanks but why have I gone for years without LEDS?
> > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > visible, usable, etc).
> > > 
> > > Please make this selectable instead of forcing more bulk into my
> >> kernel.
> 
> LED core is not that big, and this avoided some rather "interesting"
> hacks IIRC. If Udo wants more config complexity, lets first make him
> measure the benefits, second submit a patch.
> 
> But I'd suggest to just live with it.
> 
> And yes, we should probably get rid of "CONFIG_NEW_LEDS" symbol. That
> one is actually useless.

IIRC, this was needed for the reverse selection of CONFIG_LEDS_CLASS
and co.  But if it's really useless, I'll happily delete it.


thanks,

Takashi

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote:
> On 14-10-2020 09:58, Pavel Machek wrote:
> > Contrary to his claims, Udo very probably has LEDs in his systems...
> 
> We have a visible power LED.
> WE have a HDD LED.

> The board has LEDs, yes, but the SilverStone Fortress FT02 hides them
> fairly well.
> I did not ask for LEDs nor need them this way.
> It's a computer, not a disco-light or anything like that.

And you probably have numlock LED.

> Whether the code is big or not does not matter, it is a matter of being
> able to select what one needs without getting bothered with other code
> that will do nothing.

No.

Additional config options have costs, too, and we don't want to
support gazillion config options. LED core should be small enough that
it does not matter. Sound was inventing its own "tiny LED core"
before.

> So please consider.

I did. Answer is no. Please accept it.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Wed 2020-10-14 10:08:27, Takashi Iwai wrote:
> On Wed, 14 Oct 2020 09:54:59 +0200,
> Pavel Machek wrote:
> > 
> > Hi!
> > 
> > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > >>> SND_HDA_CODEC_REALTEK.
> > > >>
> > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > >> with no LEDS. That driver apparently wants LEDS.
> > > > 
> > > > Thanks but why have I gone for years without LEDS?
> > > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > > visible, usable, etc).
> > > > 
> > > > Please make this selectable instead of forcing more bulk into my
> > >> kernel.
> > 
> > LED core is not that big, and this avoided some rather "interesting"
> > hacks IIRC. If Udo wants more config complexity, lets first make him
> > measure the benefits, second submit a patch.
> > 
> > But I'd suggest to just live with it.
> > 
> > And yes, we should probably get rid of "CONFIG_NEW_LEDS" symbol. That
> > one is actually useless.
> 
> IIRC, this was needed for the reverse selection of CONFIG_LEDS_CLASS
> and co.  But if it's really useless, I'll happily delete it.

It is needed for now. It is just something we should remove in
future. CONFIG options are not that cheap...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 10:13:05 +0200,
Pavel Machek wrote:
> 
> On Wed 2020-10-14 10:08:27, Takashi Iwai wrote:
> > On Wed, 14 Oct 2020 09:54:59 +0200,
> > Pavel Machek wrote:
> > > 
> > > Hi!
> > > 
> > > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > > >>> SND_HDA_CODEC_REALTEK.
> > > > >>
> > > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > > >> with no LEDS. That driver apparently wants LEDS.
> > > > > 
> > > > > Thanks but why have I gone for years without LEDS?
> > > > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > > > visible, usable, etc).
> > > > > 
> > > > > Please make this selectable instead of forcing more bulk into my
> > > >> kernel.
> > > 
> > > LED core is not that big, and this avoided some rather "interesting"
> > > hacks IIRC. If Udo wants more config complexity, lets first make him
> > > measure the benefits, second submit a patch.
> > > 
> > > But I'd suggest to just live with it.
> > > 
> > > And yes, we should probably get rid of "CONFIG_NEW_LEDS" symbol. That
> > > one is actually useless.
> > 
> > IIRC, this was needed for the reverse selection of CONFIG_LEDS_CLASS
> > and co.  But if it's really useless, I'll happily delete it.
> 
> It is needed for now. It is just something we should remove in
> future. CONFIG options are not that cheap...

Ah I see.  Yes, the config itself is superfluous.


thanks,

Takashi

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote:
> On 14-10-2020 10:11, Pavel Machek wrote:
> >> It's a computer, not a disco-light or anything like that.
> > 
> > And you probably have numlock LED.
> 
> On the case? no way.
> It is on the keyboard, a separate device, and already has a function.
> We also have a caps lock LED and scroll lock LED there, with separate
> functions.
> I do not need 'extra' functionality for those.
> 
> > Additional config options have costs, too, and we don't want to
> > support gazillion config options. 
> 
> That is not the issue.
> One should have thought about stuff beforehand.

We did. And decided this is best solution.

> The non-selectability is not my fault.

It also does not affect you in any way.

Feel free to go to the mic LED discussion to see why we did it like
this. Then you can come up with better solution for problem at hand.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote:
> On 14-10-2020 10:27, Pavel Machek wrote:
> >> One should have thought about stuff beforehand.
> > 
> > We did. And decided this is best solution.
> 
> Then the thought process went awry.
> 
> >> The non-selectability is not my fault.
> > 
> > It also does not affect you in any way.
> 
> It does.
> /boot fills up even sooner thanks to this unused code.
> Compiles last longer because of this unused code.

Have you measured how much slower and how much bigger it is? Do you
understand that you propose to make source code bigger and slower to
compile for everyone else?

You are filling my inbox.

> > Feel free to go to the mic LED discussion to see why we did it like
> > this. Then you can come up with better solution for problem at hand.
> 
> I did not think of forcing code onto somebody. Someone else did.
> This is effectively the effect of the LEDs thing.

Without understanding what was decided and why, this discussion is not
useful.


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Udo van den Heuvel]

People,

At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can
read that the LEDS code supposedly optimizes away when certain
conditions are met.
Especially the Realtek HDA driver *unconditionally* (as found in 5.9.1)
*wants* to enable LED functionality.
I.e.: if this blockade is lifted in the source tree then I can live with
the 'is optimized out' predictions, assuming that gcc (from Fedora 32)
can do this.
So the request is clear; we're almost there.
Please make it so that the compiler can do the 'optimize away' work bij
changing a tad in the Realtek HDA driver, along the lines of the patch
sent to me earlier or something even more beautiful.

Thanks in advance and kind regards,
Udo



On 14-10-2020 10:37, Pavel Machek wrote:
> On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote:
>> On 14-10-2020 10:27, Pavel Machek wrote:
>>>> One should have thought about stuff beforehand.
>>>
>>> We did. And decided this is best solution.
>>
>> Then the thought process went awry.
>>
>>>> The non-selectability is not my fault.
>>>
>>> It also does not affect you in any way.
>>
>> It does.
>> /boot fills up even sooner thanks to this unused code.
>> Compiles last longer because of this unused code.
> 
> Have you measured how much slower and how much bigger it is? Do you
> understand that you propose to make source code bigger and slower to
> compile for everyone else?
> 
> You are filling my inbox.
> 
>>> Feel free to go to the mic LED discussion to see why we did it like
>>> this. Then you can come up with better solution for problem at hand.
>>
>> I did not think of forcing code onto somebody. Someone else did.
>> This is effectively the effect of the LEDs thing.
> 
> Without understanding what was decided and why, this discussion is not
> useful.
> 
> 
> 									Pavel
> 

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Marek Behún]

On Mon, 19 Oct 2020 10:35:12 +0200
Udo van den Heuvel <udovdh@xs4all.nl> wrote:

> People,
> 
> At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can
> read that the LEDS code supposedly optimizes away when certain
> conditions are met.
> Especially the Realtek HDA driver *unconditionally* (as found in
> 5.9.1) *wants* to enable LED functionality.
> I.e.: if this blockade is lifted in the source tree then I can live
> with the 'is optimized out' predictions, assuming that gcc (from
> Fedora 32) can do this.
> So the request is clear; we're almost there.
> Please make it so that the compiler can do the 'optimize away' work
> bij changing a tad in the Realtek HDA driver, along the lines of the
> patch sent to me earlier or something even more beautiful.
> 
> Thanks in advance and kind regards,
> Udo

Udo,

The documentation says that LED trigger code optimises away, not LED
core.

But yes, something similar could maybe be done for the whole LED
class... (maybe!)

BTW, you are welcome to propose a patch as well, since it seems that
nobody else is interested as much as you are in this :)

Marek