| Message ID | 1454304078-12322-1-git-send-email-bardliao@realtek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Feb 01, 2016 at 01:21:18PM +0800, Bard Liao wrote: > + { > + .ident = "Google Chrome", > + .matches = { > + DMI_MATCH(DMI_BIOS_VENDOR, "coreboot"), > + }, > + }, While coreboot is most commonly seen in ChromeOS systems it's not unique to them so this seems likely to generate false positives. Since the target for this change is internal-only development hardware it doesn't seem unreasonable to expect people to be able to keep changes like device ID updates internally. This is one of the many costs of BIOSes that require us to do such DMI hacks, it'd be much better to improve the firmware and the driver so they can specify required properties directly rather than relying on DMI.
Add some Intel folks. > -----Original Message----- > From: Mark Brown [mailto:broonie@kernel.org] > Sent: Wednesday, February 03, 2016 3:50 AM > To: Bard Liao > Cc: lgirdwood@gmail.com; alsa-devel@alsa-project.org; > lars@metafoo.de; Flove; Oder Chiou; John Lin > Subject: Re: [PATCH] ASoC: rt5645: add "coreboot" to dmi_system_id list > > On Mon, Feb 01, 2016 at 01:21:18PM +0800, Bard Liao wrote: > > > + { > > + .ident = "Google Chrome", > > + .matches = { > > + DMI_MATCH(DMI_BIOS_VENDOR, "coreboot"), > > + }, > > + }, > > While coreboot is most commonly seen in ChromeOS systems it's not > unique to them so this seems likely to generate false positives. Since So far, almost all ChromeOS system with rt5650 codec have the same properties. We think the settings can be a default setting for rt5650 codec. That's why we use DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE") and place it in the lowest priority currently. Adding "coreboot" is for those ChromeOS system other than with DMI_SYS_VENDOR "GOOGLE". > the target for this change is internal-only development hardware it > doesn't seem unreasonable to expect people to be able to keep changes > like device ID updates internally. This is one of the many costs of BIOSes > that require us to do such DMI hacks, it'd be much better to improve the > firmware and the driver so they can specify required properties directly > rather than relying on DMI. Agree. We will find a more reasonable way (maybe ACPI) to specify required properties directly. However, I can expect that will take time. If you think use "coreboot" is not a good idea, can we match the DMI_PRODUCT_NAME field just like before until we finish the implementation of specifying required properties directly? > > ------Please consider the environment before printing this e-mail.
On Wed, Feb 03, 2016 at 02:37:08AM +0000, Bard Liao wrote: > Add some Intel folks. > > the target for this change is internal-only development hardware it > > doesn't seem unreasonable to expect people to be able to keep changes > > like device ID updates internally. This is one of the many costs of BIOSes > > that require us to do such DMI hacks, it'd be much better to improve the > > firmware and the driver so they can specify required properties directly > > rather than relying on DMI. > Agree. We will find a more reasonable way (maybe ACPI) to specify > required properties directly. However, I can expect that will take time. > If you think use "coreboot" is not a good idea, can we match the > DMI_PRODUCT_NAME field just like before until we finish the > implementation of specifying required properties directly? Sure, new matches for specific products are fine - it's just that this is too big a wildcard.
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 93e8c90..8521b22 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -3552,6 +3552,12 @@ static const struct dmi_system_id dmi_platform_intel_braswell[] = { DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"), }, }, + { + .ident = "Google Chrome", + .matches = { + DMI_MATCH(DMI_BIOS_VENDOR, "coreboot"), + }, + }, { } };