linux-kernel - Re: [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8

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]

Message-ID: <20220113183141.kla37mbqmo4x6wxp@localhost.localdomain>
Date:   Thu, 13 Jan 2022 21:31:41 +0300
From:   Alexander Sergeyev <sergeev917@...il.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Jeremy Szu <jeremy.szu@...onical.com>, tiwai@...e.com,
        "moderated list:SOUND" <alsa-devel@...a-project.org>,
        Kailang Yang <kailang@...ltek.com>,
        open list <linux-kernel@...r.kernel.org>,
        Huacai Chen <chenhuacai@...nel.org>,
        Jian-Hong Pan <jhp@...lessos.org>,
        Hui Wang <hui.wang@...onical.com>,
        PeiSen Hou <pshou@...ltek.com>
Subject: Re: [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855
 G8

On Thu, Jan 13, 2022 at 08:14:29AM +0100, Takashi Iwai wrote:
>> First, about unbind and bind via sysfs -- attempts to unbind the
>> HD-audio controller immediately trigger BUGs:
>> Is it normal/expected?
>
>A sort of. The sysfs unbind is little tested and may be still buggy
>if done during the stream operation.
>
>To be sure, could you check with my latest sound.git tree for-linus
>branch?  There are a few fixes that harden the dynamic unbind.

I assume that the referred repository is the one at [1]. I've tried 
081c73701ef0 "ALSA: hda: intel-dsp-config: reorder the config table". It 
crashed with nearly identical logs.

>> 1) Coeff 0x0b is flapping between 0x8003 and 0x7770 and does not seem
>> to have any effect in both non-working and working versions. Not sure
>> about this, maybe microphone is not operational since I haven't
>> checked it yet.

I got some time to poke the internal microphone. It works, but oddities are 
there as well. Initially I get "Mic Boost", "Capture" and "Internal Mic Boost" 
controls in alsamixer. When I run arecord, "Digital" control appears, but it 
cannot be changed until arecord is stopped. Subsequent arecord calls do not 
lock "Digital" control. This control affects sensitivity of the microphone and 
seems useful.

/proc/asound/card1/codec#0:
  Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In
    Control: name="Capture Volume", index=0, device=0
      ControlAmp: chs=3, dir=In, idx=0, ofs=0
    Control: name="Capture Switch", index=0, device=0
      ControlAmp: chs=3, dir=In, idx=0, ofs=0
    Device: name="ALC285 Analog", type="Audio", device=0
    Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1
    Amp-In vals:  [0x27 0x27]
-  Converter: stream=0, channel=0
+  Converter: stream=1, channel=0

This is the only change in /proc/asound after the first arecord run. Overall, 
seems like a small annoyance, but I'm curious -- is it how it's supposed to 
work?

[1]https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/?h=for-linus