Received-SPF: pass (google.com: domain of linux-kernel+bounces-150426-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <848bcc94-3a31-4fb4-81bc-bd3f138e12f6@linux.intel.com>
Date: Thu, 18 Apr 2024 08:24:10 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14
 NBLB-WAX9N quirk detection
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-kernel@vger.kernel.org,
 =?UTF-8?Q?Amadeusz_S=C5=82awi=C5=84ski?=
 <amadeuszx.slawinski@linux.intel.com>,
 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
 Bard Liao <yung-chuan.liao@linux.intel.com>,
 Brady Norander <bradynorander@gmail.com>, Jaroslav Kysela <perex@perex.cz>,
 Mark Brown <broonie@kernel.org>, Mark Hasemeyer <markhas@chromium.org>,
 Takashi Iwai <tiwai@suse.com>, linux-sound@vger.kernel.org,
 stable@vger.kernel.org
References: <5e6ba980c0738199589749b68b83f2d730512107.1713430105.git.mchehab@kernel.org>
 <20240418110453.10efcb60@sal.lan>
Content-Language: en-US
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <20240418110453.10efcb60@sal.lan>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> Em Thu, 18 Apr 2024 09:48:27 +0100
> Mauro Carvalho Chehab <mchehab@kernel.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@vger.kernel.org
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.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)
>>  	{