linux-kernel - Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

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: <20240418212235.6548447d@sal.lan>
Date: Thu, 18 Apr 2024 21:22:35 +0100
From: Mauro Carvalho Chehab <mchehab@...nel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, Amadeusz Sławiński
 <amadeuszx.slawinski@...ux.intel.com>, Andy Shevchenko
 <andriy.shevchenko@...ux.intel.com>, Bard Liao
 <yung-chuan.liao@...ux.intel.com>, Brady Norander
 <bradynorander@...il.com>, Jaroslav Kysela <perex@...ex.cz>, Mark Brown
 <broonie@...nel.org>, Mark Hasemeyer <markhas@...omium.org>, Takashi Iwai
 <tiwai@...e.com>, linux-sound@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14
 NBLB-WAX9N quirk detection

Em Thu, 18 Apr 2024 08:24:10 -0500
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> escreveu:

> On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> > Em Thu, 18 Apr 2024 09:48:27 +0100
> > Mauro Carvalho Chehab <mchehab@...nel.org> escreveu:
> >   
> >> Newer Matebook D14 model comes with essx8336 and supports SOF,
> >> but the initial models use the legacy driver, with a Realtek ALC 256
> >> AC97 chip on it.
> >>
> >> The BIOS seems to be prepared to be used by both models, so
> >> it contains an entry for ESSX8336 on its DSDT table.
> >>
> >> Add a quirk, as otherwise dspconfig driver will try to load
> >> SOF, causing audio probe to fail.
> >>
> >> Cc: stable@...r.kernel.org
> >> Signed-off-by: Mauro Carvalho Chehab <mchehab@...nel.org>  
> > 
> > Worth to mention that I opened an issue on Github about that:
> > 
> > https://github.com/thesofproject/linux/issues/4934
> > 
> > I added there the ACPI DSDT table as a reference.  
> 
> This sounds like an 'easy enough' fix, but I don't have a burning desire
> to start adding quirks of this nature. To be clear, the entire support
> of the ES8336 is an absolute nightmare that I've stopped looking at
> completely given the lack of support of vendor/OEMs.

Heh, I know the pain, having working myself to have some support for audio
on two different notebooks with my siblings, both with es8336. On both 
cases, the BIOS info was not really useful, requiring quirks to make device
to work properly.

This is btw a common issue I'm aware for a long time: BIOS data is
not reliable, as vendors tend to re-use BIOS from one device on others,
without actually reflecting what it is on each device.

The EDAC subsystem never relies on DMI data for memory banks - as even
server BIOS from top tear manufacturers usually report wrong data for
motherboard's DIMM labels. Instead, an userspace application reads
DMI data and propose changes, but patches for rasdaemon are required
to add such labels to a database.

-

In any case, this specific device doesn't have es8336 ;-)

Also, I don't think this problem will remain confined to es8336: any
other SOF driver may have the same problem: a BIOS (or a BIOS update)
may add non-existent _HID devices to DSDT, causing the driver to
disable AC97 support, enabling SOF instead and causing regressions.

As I wrote at the Github issue, one solution would be to do an I2C
scan to detect if the SOF device(s) reported by BIOS are really
present. This would require that, before calling 
snd_intel_acpi_dsp_driver_probe():

	- the I2C bus to be created;
	- Runtime PM for the audio device needs to put resume the
	  device and I2C bus controller, if suspended;
	- the I2C address of the audio device needs to be known
	  by sound/hda/intel-dsp-config.c

With that, a zero-byte (or one-byte if zero-byte not support)
read or write could detect if the device is there, before
initializing it - or calling the device-specific driver.

Another solution would be to probe the SOF driver, falling back
to AC97 if SOF init fails.

> 
> In this case, the ACPI table is completely wrong, we should try to
> 'mark' the ES8336 device as 'not present' or detect the presence of HDaudio.
> 
> Andy, what do you think and what would be your recommendation?
> 
> >> ---
> >>  sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> >>
> >> diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
> >> index 6a384b922e4f..8e728f0585dd 100644
> >> --- a/sound/hda/intel-dsp-config.c
> >> +++ b/sound/hda/intel-dsp-config.c
> >> @@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
> >>   * - the first successful match will win
> >>   */
> >>  static const struct config_entry config_table[] = {
> >> +	/* Quirks */
> >> +	{
> >> +		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
> >> +		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
> >> +		.dmi_table = (const struct dmi_system_id []) {
> >> +			{
> >> +				.ident = "Huawei NBLB-WAX9N",
> >> +				.matches = {
> >> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
> >> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
> >> +				}
> >> +			},
> >> +			{}
> >> +		}
> >> +	},
> >> +
> >>  /* Merrifield */
> >>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
> >>  	{