From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA5421A6817 for ; Mon, 2 Mar 2026 22:33:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772490830; cv=none; b=sQ/2IQKYlRdIJzAfLPfli8pUeDhvEMr5SpSCTn7ACeBM7xsBPfvyCiGZlSQp8TeCjVhPOtcm/EzmjbX8iWplsCStW9xsFuuZFI/rzPRMAeqhurQUO31QfziOZSYNCyyS4+q+oVMfwAI5G0PfUuiPive1LytJJaDjVytJZ3lXNck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772490830; c=relaxed/simple; bh=DbxDysGBDAfn7jxE/xCmO94kBp/DjnKbpJy4ybg3nYg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eION3U4mxeSGfyaOOdHXYJuEQ35S51KaC3Evla2m+PoZg+tNpLAhjY8oc2k4VDosVtNCsRVgcwk5SxW43+AqbMRdYSXf7tbcFNMIK3Gu9gg3rLNwWsGcamxUBNEjFlUzzOWlQhZlDWpfdkHgQMFI/lteC20w/UZgN6io/5HRvDs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QQmEmM7D; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QQmEmM7D" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b934f8ec6acso594711866b.2 for ; Mon, 02 Mar 2026 14:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772490827; x=1773095627; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=unrd9v9Hp/E9pxUEuAksZtMa8wpXSjo2kYKtQs7qCV8=; b=QQmEmM7D9w2y28m123qYFSba1I/qxCoOF4KcSa/l76OQQylBzOYFgQeiRQgS3hq3oU CbLrglBpaoVu0fmC3DmYtdxwiHm2MylJGJCjLK0WJKesQylaB8Nfaifyffwb4TvruKtw b9FZUVOFiW8jcrvBJxIP0rSBasMIydYCEr+ij6XMbcZklCucF7XSv9tbx9y/gC6fARoS 6H+y7iRXdJMeTobSFJLSzPsp4+xaMitehC/mNlP22OImozOE6gv7KC6b82d7yA6zA6xJ /Uw2FSNi+WXuYoMuDDjdy30M5TTRU+6KfubEiMn/n8qHoUAQTkSVJjmwUC0THtF4SHxz NDag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772490827; x=1773095627; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=unrd9v9Hp/E9pxUEuAksZtMa8wpXSjo2kYKtQs7qCV8=; b=E1mz3vwOYXDBlDMb7hMdhD8vZZ39dxjYiFOTM3x3ZXWl3YO4WVrCu8BtwSdq/huO/4 kA4VtsxifujHVEV4k0RWndFDFpDmtW+qNZe6V3et7xjcSVJ7XYXMEkT26fcbyUAHCKcF JYdwb0LGwp5RCA9d3INWT04w1hG71WaxZF4j458SRVowjdy/xmcazUmklGIGmDHV1Sar geUo0wItA3pWS57SrZyTJrEyp5z6Cm7wLKWfdx/bcfybIbO5+ibuY1RK2VyO5gJcV8j5 1CXJLQzVYEeZcXADRRNJMvsRAzi0iHpIYjk7PfAVt2LuOs25t0EBPYU8a7Af9oUaOAU3 Krlg== X-Forwarded-Encrypted: i=1; AJvYcCVBukMgmuW9ZxD4iBpi3mchxmLmZQeBkktBbgjg2lC8MvVEHIQ7B+OnSml2NkcB0WWygqWn/zFyuDuTVbw=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5nKJvfqUVZBR90wjlNrZg60/NkVIcXcq+DuZaaKBjJXnSPfPP MTmHmQHguIstgO1sqMwDFmcmCkDNuhNXlYP1Q29sf74yVDmjwcNrp0Ve X-Gm-Gg: ATEYQzwSMKfXU7S5xPzZ282jhq4K+ryaKLc8Rtz4CoITOx2PedqIRtS/fQdNDfof9+2 kHb18zCw3Sq6KdiEkp21NWRPs30VTtpgCP4j203ZrL7XBp6LYD+dvYV+TMTaD+wVjQJtGokiOZZ DpK5KwqW7Wddoprkjv5m0FSCt06h9wb/uEdJLqj5vLHuSayj0U5YLKBGgOxEFtotZnonWqWNWB9 dnxFmWDd9fvbSP5UKlfbVm523Zx+j/jJlu1Ir8cvjHxh/C3saKNpPUG8B/r1pgC1TnUyOgAhpgy reiW05W2vArobMEaAb+VLcafqCHPasibJEILkGF8kgYuJJyvRwdcPXY2+NzyErtmB8eiO23N400 DoZd0/rgZNAe6tgbNO/R8A8QPNPdMVj+ZY8ZqIleKOOFfsHIAUNuGv84iHNxWU910C3bBdggaJB 9nv1/Ed2tEfQku8Q== X-Received: by 2002:a17:907:94c3:b0:b89:9631:2425 with SMTP id a640c23a62f3a-b93763af2d2mr951582566b.19.1772490826860; Mon, 02 Mar 2026 14:33:46 -0800 (PST) Received: from jekhomev ([46.251.53.180]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ae6560asm534337966b.43.2026.03.02.14.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 14:33:46 -0800 (PST) Date: Tue, 3 Mar 2026 00:33:45 +0200 From: Yauhen Kharuzhy To: =?utf-8?B?UMOpdGVy?= Ujfalusi Cc: Cezary Rojewski , Liam Girdwood , Bard Liao , Ranjani Sridharan , Kai Vehmanen , Pierre-Louis Bossart , Mark Brown , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, Hans de Goede Subject: Re: [PATCH v2 1/3] ASoC: Intel: soc-acpi-cht: Unify device quirks Message-ID: References: <20260301-asoc-yogabook-v2-v2-0-adcc7ed40985@gmail.com> <20260301-asoc-yogabook-v2-v2-1-adcc7ed40985@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > > --- > > 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