* 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ messages in thread
[parent not found: <056a8933-378f-30f2-c7af-5514d93d3c36@xs4all.nl>]
* 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; 14+ 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] 14+ messages in thread
[parent not found: <2be6e184-97d4-a2b1-a500-6ea3528cff37@xs4all.nl>]
* 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; 14+ 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] 14+ messages in thread
[parent not found: <9cf705b9-1fca-2445-43de-916b13b9103f@xs4all.nl>]
* 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 2020-10-19 8:35 ` Udo van den Heuvel 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) 2020-10-14 8:37 ` Pavel Machek @ 2020-10-19 8:35 ` Udo van den Heuvel 2020-10-19 10:58 ` Marek Behún 0 siblings, 1 reply; 14+ messages in thread From: Udo van den Heuvel @ 2020-10-19 8:35 UTC (permalink / raw) To: Takashi Iwai, Randy Dunlap, linux-kernel, linux-leds, Dan Murphy, moderated for non-subscribers Cc: Pavel Machek 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 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) 2020-10-19 8:35 ` Udo van den Heuvel @ 2020-10-19 10:58 ` Marek Behún 0 siblings, 0 replies; 14+ messages in thread From: Marek Behún @ 2020-10-19 10:58 UTC (permalink / raw) To: Udo van den Heuvel Cc: moderated for non-subscribers, Takashi Iwai, Randy Dunlap, linux-kernel, Dan Murphy, Pavel Machek, linux-leds 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 ^ permalink raw reply [flat|nested] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ messages in thread
end of thread, other threads:[~2020-10-21 13:46 UTC | newest] Thread overview: 14+ 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-19 8:35 ` Udo van den Heuvel 2020-10-19 10:58 ` Marek Behún 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).