From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Daniel Drake <drake@endlessm.com>, alsa-devel@alsa-project.org
Cc: liam.r.girdwood@linux.intel.com
Subject: Re: snd_soc_set_dmi_name - Shouldn't it use SYS_VENDOR?
Date: Thu, 27 Apr 2017 14:28:28 -0500 [thread overview]
Message-ID: <5aa36e3b-49f9-d7f6-df58-18dcfcda08e5@linux.intel.com> (raw)
In-Reply-To: <CAD8Lp454-BRKu7GZxpbO+4qgFfSTF0DviUcaUDtgNOVrzb2jLw@mail.gmail.com>
On 4/27/17 1:00 PM, Daniel Drake wrote:
> Hi,
>
> Nice to see DMI info being attached to SoC sound devices so that we
> can differentiate between differerent products in userspace, thanks
> for the effort there.
>
> However I just noticed that it using DMI_BOARD_VENDOR. Is this intentional?
>
> I have several examples of products here where DMI_BOARD_VENDOR is not
> set to a meaningful value, but DMI_SYS_VENDOR is just fine. DMI quirks
> in the kernel ordinarily tend to match products by combining
> DMI_SYS_VENDOR with DMI_PRODUCT_NAME.
>
> In the SMBIOS data format, Type 1 (System information) includes
> DMI_SYS_VENDOR and DMI_PRODUCT_NAME. Type 2 (Base board information)
> includes DMI_BOARD_VENDOR and DMI_BOARD_NAME. See dmi_decode() in
> drivers/firmware/dmi_scan.c
>
> It seems strange that ASoC is pulling the product name from Type 1 but
> the vendor from type 2. Can we make it instead just use Type 1 data,
> DMI_SYS_VENDOR and DMI_PRODUCT_NAME?
There is a bit of variability here, the quirks we use are based on:
DMI_BOARD_VENDOR
DMI_SYS_VENDOR
DMI_PRODUCT_NAME
DMI_PRODUCT_VERSION (typically for Lenovo programs)
DMI_BOARD_NAME (for reference designs)
Not sure if we can really limit the conventions to type1 or type2 if we
want the names to be somewhat meaningful.
I can't recall why we selected DMI_BOARD_VENDOR instead of
DMI_SYS_VENDOR though.
>
> Thanks
> Daniel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
next prev parent reply other threads:[~2017-04-27 19:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 18:00 snd_soc_set_dmi_name - Shouldn't it use SYS_VENDOR? Daniel Drake
2017-04-27 19:28 ` Pierre-Louis Bossart [this message]
2017-04-27 20:13 ` Daniel Drake
2017-04-27 20:32 ` Pierre-Louis Bossart
2017-04-27 21:02 ` Daniel Drake
2017-04-28 8:36 ` Takashi Iwai
2017-04-28 10:35 ` Liam Girdwood
2017-04-28 15:02 ` Lin, Mengdong
2017-04-28 16:21 ` Lin, Mengdong
2017-04-29 15:27 ` Daniel Drake
2017-05-02 10:19 ` Mengdong Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5aa36e3b-49f9-d7f6-df58-18dcfcda08e5@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=drake@endlessm.com \
--cc=liam.r.girdwood@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).