From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
To: Daniel Drake <drake@endlessm.com>
Cc: "Lin, Mengdong" <mengdong.lin@intel.com>,
alsa-devel@alsa-project.org,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: snd_soc_set_dmi_name - Shouldn't it use SYS_VENDOR?
Date: Fri, 28 Apr 2017 11:35:01 +0100 [thread overview]
Message-ID: <1493375701.2540.53.camel@loki> (raw)
In-Reply-To: <CAD8Lp47u3ERC_pn4ScJ6DQZ9HOuDcUZ0zM4fEQ99c3EVzP_YXA@mail.gmail.com>
On Thu, 2017-04-27 at 15:02 -0600, Daniel Drake wrote:
> On Thu, Apr 27, 2017 at 2:32 PM, Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com> wrote:
> > While in general DMI_SYS_VENDOR is commonly used, there are exceptions to
> > the rule, such as the very machine I am working on at the moment which does
> > have any useful DMI_SYS_VENDOR information (see below)
> > Mengdong may be able to comment on why we took this direction.
>
I think it was probably due to our limited number of test machines all
reporting better info via DMI_BOARD_VENDOR.
> In a DMI database of 113 PC models that we have worked with here:
>
> 112 have correct/meaningful sys_vendor, 1 is useless (To be filled by OEM)
> 106 have correct board_vendor, 7 have incorrect or useless values
>
> And awkwardly the one system that I'd like to match in UCM rules here
> has correct sys_vendor but bad board_vendor.
>
So given your larger database is showing better results for
DMI_SYS_VENDOR it may be best to try this first and if that's NULL then
use DMI_BOARD_VENDOR.
Would you care to submit a patch ? or Mengdong ? Sorry, I wont be able
to get to this for a week due to some travel.
Thanks
Liam
next prev parent reply other threads:[~2017-04-28 10:35 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
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 [this message]
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=1493375701.2540.53.camel@loki \
--to=liam.r.girdwood@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=drake@endlessm.com \
--cc=mengdong.lin@intel.com \
--cc=pierre-louis.bossart@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.