Re: [PATCH v2 1/3] ASoC: Intel: soc-acpi-cht: Unify device quirks

[Yauhen Kharuzhy]

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.


> 
> -- 
> Péter
> 

-- 
Yauhen Kharuzhy