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: <848bcc94-3a31-4fb4-81bc-bd3f138e12f6@linux.intel.com>
Date: Thu, 18 Apr 2024 08:24:10 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Mauro Carvalho Chehab <mchehab@...nel.org>
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



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.

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)
>>  	{