linux-kernel - Re: [PATCH v3 1/2] ALSA: hda/realtek: Add COEF controlled micmute LED support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Jun 2020 17:50:30 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     tiwai@...e.com, Jaroslav Kysela <perex@...ex.cz>,
        Wenwen Wang <wenwen@...uga.edu>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Michał Mirosław 
        <mirq-linux@...e.qmqm.pl>, Hui Wang <hui.wang@...onical.com>,
        Kailang Yang <kailang@...ltek.com>,
        Jian-Hong Pan <jian-hong@...lessm.com>,
        Tomas Espeleta <tomas.espeleta@...il.com>,
        Thomas Hebb <tommyhebb@...il.com>,
        "moderated list:SOUND" <alsa-devel@...a-project.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] ALSA: hda/realtek: Add COEF controlled micmute LED support

On Wed, 17 Jun 2020 17:24:30 +0200,
Kai-Heng Feng wrote:
> 
> 
> 
> > On Jun 17, 2020, at 19:55, Takashi Iwai <tiwai@...e.de> 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@...onical.com>
> > 
> > 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