On Wed, 17 Jun 2020 17:24:30 +0200, Kai-Heng Feng wrote: > > > > > On Jun 17, 2020, at 19:55, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > On Wed, 17 Jun 2020 12:29:01 +0200, > > Kai-Heng Feng wrote: > >> > >> Currently, HDA codec LED class can only be used by GPIO controlled LED. > >> However, there are some new systems that control LED via COEF instead of > >> GPIO. > >> > >> In order to support those systems, create a new helper that can be > >> facilitated by both COEF controlled and GPIO controlled LED. > >> > >> In addition to that, add LED_CORE_SUSPENDRESUME flag since some systems > >> don't restore the LED properly after suspend. > >> > >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> > > > > Thanks for the quick follow up, the issues I pointed were fixed. > > > > But, now looking at the code change again, I'm no longer sure whether > > it's the right move. > > > > Basically, the led cdev should serve only for turning on/off the LED > > as given. But your patch changes it to call the generic mixer > > updater, which is rather the one who would call the led cdev state > > update itself. That is, it's other way round. > > > > IMO, what we need is to make all places calling > > snd_hda_gen_add_micmute_led() to create led cdev, and change those > > calls with snd_hda_gen_fixup_micmute_led(). > > Ok, so it's the same as patch v1. > How should we handle vendors other than HP? > Only create led cdev if the ID matches to HP? It's fine to create a LED classdev for other vendors, too. But the problem is that it wasn't consistent. With the LED classdev, we should use only cdev, instead of mixing up different ways. I wrote a few patches to convert those mic-mute LED stuff to classdev, including some cleanups. The patches are found in topic/hda-micmute-led branch of sound git tree. Could you check it? Note that it's totally untested. Also it doesn't contain yet LED_CORE_SUSPENDRESUME, which should be done in another patch in anyway. > > It'll be a bit more changes and likely not fitting with 5.8, but the > > whole result will be more consistent. > > A bit off topic, but do you think it's reasonable to also create led cdev for mute LED, in addition to micmute LED? > I just found that the LEDs are still on during system suspend, and led cdev has the ability to turn off the LEDs on system suspend. Yes, it makes sense, too. But the playback mute handling is a bit more complicated than the mic-mute LED because it's implemented with a vmaster hook. I'll take a look later. thanks, Takashi
