linux-kernel - Re: [PATCH] SKU: Set to turn off EAPD control for Internal SPK.

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] [day] [month] [year] [list]

Message-ID: <87ilb9fcjd.wl-tiwai@suse.de>
Date:   Tue, 27 Jun 2023 12:02:46 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     dengxiang <dengxiang@...china.com>
Cc:     tiwai@...e.com, yangyingliang@...wei.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] SKU: Set to turn off EAPD control for Internal SPK.

On Tue, 27 Jun 2023 07:58:36 +0200,
dengxiang wrote:
> 
> Due to unknown reason that could not support DSP function on Raptor Lake
> platform using v2.5 sof-bin firmware and snd_hda_intel would disable codec
> wakeup twice during snd_hda_intel initialization, Internal SPK is forbidden
> to put sound outside with snd_hda_intel driver on Unis B760 sku machine.
> Now find out that PIN47 EAPD status is always low for ALC897 chip on
> Unis B760 sku.
> Solution: set to turn off EAPD control again in avoid to mute internal SPK.
> 
> Signed-off-by: dengxiang <dengxiang@...china.com>
> ---
>  sound/pci/hda/patch_realtek.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 36c4adfb11e7..bb0ee265eb7f 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -534,6 +534,16 @@ static void set_eapd(struct hda_codec *codec, hda_nid_t nid, int on)
>  {
>  	if (get_wcaps_type(get_wcaps(codec, nid)) != AC_WID_PIN)
>  		return;
> +
> +	switch (codec->core.vendor_id) {
> +	case 0x10ec0897:
> +	case 0x80867a50:
> +		on = 0;
> +		break;
> +	default:
> +		break;
> +	}

Sorry, this is definitely no-go.  It matches generically to all
devices that have this codec chip, so you'll break all those devices.


Takashi