Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
       [not found]                   ` <1e6b1961-9e9b-5f82-86a1-bf838cb68f55@xs4all.nl>
@ 2020-10-14  5:54                     ` Randy Dunlap
  2020-10-14  7:49                       ` Takashi Iwai
  2020-10-14  7:54                       ` Pavel Machek
  0 siblings, 2 replies; 12+ messages in thread
From: Randy Dunlap @ 2020-10-14  5:54 UTC (permalink / raw)
  To: Udo van den Heuvel, linux-kernel, linux-leds, Dan Murphy,
	Pavel Machek, Takashi Iwai, moderated for non-subscribers

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  5:54                     ` disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) Randy Dunlap
@ 2020-10-14  7:49                       ` Takashi Iwai
  2020-10-14  7:51                         ` Takashi Iwai
  2020-10-14  7:54                       ` Pavel Machek
  1 sibling, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2020-10-14  7:49 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: moderated for non-subscribers, linux-kernel, Udo van den Heuvel,
	Dan Murphy, Pavel Machek, linux-leds

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 */

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  7:49                       ` Takashi Iwai
@ 2020-10-14  7:51                         ` Takashi Iwai
  2020-10-14  7:58                           ` Pavel Machek
  0 siblings, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2020-10-14  7:51 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: moderated for non-subscribers, linux-kernel, Udo van den Heuvel,
	Dan Murphy, Pavel Machek, linux-leds

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 */

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  5:54                     ` disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) Randy Dunlap
  2020-10-14  7:49                       ` Takashi Iwai
@ 2020-10-14  7:54                       ` Pavel Machek
  2020-10-14  8:08                         ` Takashi Iwai
  1 sibling, 1 reply; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  7:54 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: moderated for non-subscribers, Takashi Iwai, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  7:51                         ` Takashi Iwai
@ 2020-10-14  7:58                           ` Pavel Machek
  2020-10-14  8:06                             ` Takashi Iwai
       [not found]                             ` <056a8933-378f-30f2-c7af-5514d93d3c36@xs4all.nl>
  0 siblings, 2 replies; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  7:58 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: moderated for non-subscribers, Randy Dunlap, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  7:58                           ` Pavel Machek
@ 2020-10-14  8:06                             ` Takashi Iwai
       [not found]                             ` <056a8933-378f-30f2-c7af-5514d93d3c36@xs4all.nl>
  1 sibling, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2020-10-14  8:06 UTC (permalink / raw)
  To: Pavel Machek
  Cc: moderated for non-subscribers, Randy Dunlap, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  7:54                       ` Pavel Machek
@ 2020-10-14  8:08                         ` Takashi Iwai
  2020-10-14  8:13                           ` Pavel Machek
  0 siblings, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2020-10-14  8:08 UTC (permalink / raw)
  To: Pavel Machek
  Cc: moderated for non-subscribers, Randy Dunlap, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
       [not found]                             ` <056a8933-378f-30f2-c7af-5514d93d3c36@xs4all.nl>
@ 2020-10-14  8:11                               ` Pavel Machek
       [not found]                                 ` <2be6e184-97d4-a2b1-a500-6ea3528cff37@xs4all.nl>
  0 siblings, 1 reply; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  8:11 UTC (permalink / raw)
  To: Udo van den Heuvel
  Cc: moderated for non-subscribers, Takashi Iwai, Randy Dunlap,
	linux-kernel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  8:08                         ` Takashi Iwai
@ 2020-10-14  8:13                           ` Pavel Machek
  2020-10-14  8:17                             ` Takashi Iwai
  0 siblings, 1 reply; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  8:13 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: moderated for non-subscribers, Randy Dunlap, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
  2020-10-14  8:13                           ` Pavel Machek
@ 2020-10-14  8:17                             ` Takashi Iwai
  0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2020-10-14  8:17 UTC (permalink / raw)
  To: Pavel Machek
  Cc: moderated for non-subscribers, Randy Dunlap, linux-kernel,
	Udo van den Heuvel, Dan Murphy, linux-leds

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
       [not found]                                 ` <2be6e184-97d4-a2b1-a500-6ea3528cff37@xs4all.nl>
@ 2020-10-14  8:27                                   ` Pavel Machek
       [not found]                                     ` <9cf705b9-1fca-2445-43de-916b13b9103f@xs4all.nl>
  0 siblings, 1 reply; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  8:27 UTC (permalink / raw)
  To: Udo van den Heuvel
  Cc: moderated for non-subscribers, Takashi Iwai, Randy Dunlap,
	linux-kernel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
       [not found]                                     ` <9cf705b9-1fca-2445-43de-916b13b9103f@xs4all.nl>
@ 2020-10-14  8:37                                       ` Pavel Machek
  0 siblings, 0 replies; 12+ messages in thread
From: Pavel Machek @ 2020-10-14  8:37 UTC (permalink / raw)
  To: Udo van den Heuvel
  Cc: moderated for non-subscribers, Takashi Iwai, Randy Dunlap,
	linux-kernel, Dan Murphy, linux-leds


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <2835d02a-380b-6a3a-0e4d-abf07aee18bc@xs4all.nl>
     [not found] ` <53e698c1-86e4-8b1f-afb0-b8471349e701@xs4all.nl>
     [not found]   ` <43b79598-1592-683f-46df-9e5489110780@infradead.org>
     [not found]     ` <6fd1e91e-19d0-6682-dfc6-49f1cd60408b@infradead.org>
     [not found]       ` <3c6d174c-30db-3d03-3d16-42df405f38d9@xs4all.nl>
     [not found]         ` <58e774c5-fc80-2060-2091-9a6398582cc5@infradead.org>
     [not found]           ` <9fc679e9-e9a9-ad80-b24c-f04489b98aa7@xs4all.nl>
     [not found]             ` <27e159be-4376-e87b-5e60-803bc3749ec2@infradead.org>
     [not found]               ` <eadc23e7-b383-e2fc-6e20-ed22745d0bfc@xs4all.nl>
     [not found]                 ` <2739e1fd-75c6-4e43-cd79-9028479f91bf@infradead.org>
     [not found]                   ` <1e6b1961-9e9b-5f82-86a1-bf838cb68f55@xs4all.nl>
2020-10-14  5:54                     ` disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) Randy Dunlap
2020-10-14  7:49                       ` Takashi Iwai
2020-10-14  7:51                         ` Takashi Iwai
2020-10-14  7:58                           ` Pavel Machek
2020-10-14  8:06                             ` Takashi Iwai
     [not found]                             ` <056a8933-378f-30f2-c7af-5514d93d3c36@xs4all.nl>
2020-10-14  8:11                               ` Pavel Machek
     [not found]                                 ` <2be6e184-97d4-a2b1-a500-6ea3528cff37@xs4all.nl>
2020-10-14  8:27                                   ` Pavel Machek
     [not found]                                     ` <9cf705b9-1fca-2445-43de-916b13b9103f@xs4all.nl>
2020-10-14  8:37                                       ` Pavel Machek
2020-10-14  7:54                       ` Pavel Machek
2020-10-14  8:08                         ` Takashi Iwai
2020-10-14  8:13                           ` Pavel Machek
2020-10-14  8:17                             ` Takashi Iwai

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git