Re: [PATCH v2 1/3] ASoC: Intel: soc-acpi-cht: Unify device quirks
From: Péter Ujfalusi
Date: Tue Mar 03 2026 - 02:10:24 EST
On 03/03/2026 00:33, Yauhen Kharuzhy wrote:
> On Mon, Mar 02, 2026 at 05:54:05PM +0200, Péter Ujfalusi wrote:
>>
>>
>> On 01/03/2026 23:33, Yauhen Kharuzhy wrote:
>>> This file contains two types of quirks, both checking DMI for
>>> machine-specific strings and returning machine data for a matching entry.
>>>
>>> The first one, `cht_quirk`, is used to override the default entry for an
>>> existing ACPI codec node if the node's info is invalid. It returns either
>>> the matched machine data or the default entry if no match is found.
>>>
>>> The second one, `cht_yt3_quirk_cb`, is used for devices (originally the
>>> Lenovo Yoga Tab 3 Pro) without a valid codec DSDT entry. It is bound to
>>> the SST ACPI node and returns either the matched machine data or NULL if
>>> no match is found.
>>>
>>> To allow adding new machine entries to the second case and to use a single
>>> DMI match entry for both cases (for example, if two variants of one device
>>> exist: one with a valid ACPI entry and one without, like the Lenovo Yoga
>>> Book YB1-X91 and YB1-X90 - Windows and Android versions), reorganize
>>> these quirks functions to use the same approach: machine data is set in
>>> the matched dmi_system_id entry as driver_data field.
>>>
>>> Signed-off-by: Yauhen Kharuzhy <jekhor@xxxxxxxxx>
>>> ---
>>> sound/soc/intel/common/soc-acpi-intel-cht-match.c | 100 +++++++++-------------
>>> 1 file changed, 42 insertions(+), 58 deletions(-)
>>>
>>> diff --git a/sound/soc/intel/common/soc-acpi-intel-cht-match.c b/sound/soc/intel/common/soc-acpi-intel-cht-match.c
>>> index e4c3492a0c28..57097c1d011e 100644
>>> --- a/sound/soc/intel/common/soc-acpi-intel-cht-match.c
>>> +++ b/sound/soc/intel/common/soc-acpi-intel-cht-match.c
>>
>>>
>>> +static struct snd_soc_acpi_mach *cht_quirk_nocodec(void *arg)
>>
>> This is confusing, why it is _nocodec?
>> cht_quirk_strict() or something might be better?
>
> Something like "a quirk for machines without of codec definition in the
> ACPI DSDT". But yes, it is confusing because we have separated "nocodec" entry
> in the table. I just couldn't think of anything better. 'strict' doesn't
> seem to reflect the meaning for my opinion also.
I see, the strict came to mind to imply that it will only return with a
match if there is a match, otherwise it will return NULL.
No fallback to default (or self match), only a strict match is allowed.
cht_match_only_quirk(), cht_no_fallback_quirk() ?
I'm extremely bad at naming..
>
>
>>
>> --
>> Péter
>>
>
--
Péter