Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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
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
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
participants (3)
-
Marek Behún -
Pavel Machek -
Udo van den Heuvel