linux-kernel - Re: [PATCH v1] ALSA: hda: intel-dsp-config: Fix JSL Chromebook 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80f8a742-4a60-4c75-9093-dcd63de70b66@linux.intel.com>
Date:   Fri, 20 Oct 2023 11:59:55 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Mark Hasemeyer <markhas@...omium.org>
Cc:     Amadeusz Sławiński 
        <amadeuszx.slawinski@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Guenter Roeck <linux@...ck-us.net>, stable@...r.kernel.org,
        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>, Takashi Iwai <tiwai@...e.com>,
        alsa-devel@...a-project.org,
        Curtis Malainey <cujomalainey@...omium.org>
Subject: Re: [PATCH v1] ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk
 detection



On 10/20/23 10:36, Mark Hasemeyer wrote:
>> FWIW we use this other quirk:
>> DMI_MATCH(DMI_PRODUCT_FAMILY, "Google"),
> 
> Unfortunately DMI_PRODUCT_FAMILY is empty on these particular devices.
> The coreboot version field is the only entry that has "Google" in it.

well then you have additional issues with the DMI quirk for the firmware
selection in sound/soc/sof/sof-pci-dev.c,

      {
		.ident = "Google Chromebooks",
		.callback = chromebook_use_community_key,
		.matches = {
			DMI_MATCH(DMI_PRODUCT_FAMILY, "Google"),
		}
	},

which means you need additional kernel parameters to provide the
location of the firmware....

>> How many engineers does it take to identify a Chromebook, eh?
> 
> Ha! There has been some discussion about this: to come up with a
> canonical way for Chromebook identification throughout the kernel. But
> nothing has been settled on AFAIK.

There's been multiple rounds of discussions with Curtis, we introduced
DMI_OEM_STRING but it's still not good enough, and now the previous
conventions are not being followed on what is a relatively old platform
already...