[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201019125856.02cebbee@dellmb.labs.office.nic.cz>
Date: Mon, 19 Oct 2020 12:58:56 +0200
From: Marek BehĂșn <marek.behun@....cz>
To: Udo van den Heuvel <udovdh@...all.nl>
Cc: Takashi Iwai <tiwai@...e.de>, Randy Dunlap <rdunlap@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-leds@...r.kernel.org, Dan Murphy <dmurphy@...com>,
moderated for non-subscribers <alsa-devel@...a-project.org>,
Pavel Machek <pavel@....cz>
Subject: Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Mon, 19 Oct 2020 10:35:12 +0200
Udo van den Heuvel <udovdh@...all.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
Powered by blists - more mailing lists