[alsa-devel] [PATCH] ASoC: rt5645: add "coreboot" to dmi_system_id list
There are some Google projects with manufacturer name different from "GOOGLE". So we need to add DMI list for those projects. However some OEMs / vendors want to keep secret before product launch. So, we can't use DMI_SYS_VENDOR for them. Fortunately, the BIOS vendor field is the same for all chrome os projects. It allows us to match chrome projects by DMI_BIOS_VENDOR = "coreboot".
Signed-off-by: John Lin john.lin@realtek.com Signed-off-by: Bard Liao bardliao@realtek.com --- sound/soc/codecs/rt5645.c | 6 ++++++ 1 file changed, 6 insertions(+)
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"), + }, + }, { } };
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.
participants (2)
-
Bard Liao -
Mark Brown