[alsa-devel] snd_soc_set_dmi_name - Shouldn't it use SYS_VENDOR?
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?
Thanks Daniel
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
On Thu, Apr 27, 2017 at 1:28 PM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
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.
Is it too late to change to DMI_SYS_VENDOR? Or to have both present in the string?
Thanks Daniel
On 04/27/2017 03:13 PM, Daniel Drake wrote:
On Thu, Apr 27, 2017 at 1:28 PM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
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.
Is it too late to change to DMI_SYS_VENDOR? Or to have both present in the string?
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.
Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Product Name: Version: Serial Number: UUID: 6DD3E1A2-7A70-41FC-917A-231C2C4E2E4E Wake-up Type: Power Switch SKU Number: Family:
Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Intel Corporation Product Name: NUC6i7KYB Version: H90766-405
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.
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.
Daniel
On Thu, 27 Apr 2017 23:02:31 +0200, 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.
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.
We may be a bit smarter and try another field if such a string ("To be filled by OEM", "Default String") is found, too. Not sure whether it's the right move, though.
The function hasn't been applied widely until now, so changing it would be still OK until 4.12-final release. If we really need to change this, let's fix now.
thanks,
Takashi
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
-----Original Message----- From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com] Sent: Friday, April 28, 2017 6:35 PM To: Daniel Drake drake@endlessm.com Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; alsa- devel@alsa-project.org; Lin, Mengdong mengdong.lin@intel.com Subject: Re: [alsa-devel] snd_soc_set_dmi_name - Shouldn't it use SYS_VENDOR?
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.
Yes, it’s better to only use one name. Otherwise, it's possible to exceed 80 characters limit for the card long name since sometimes DMI fields can be long.
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.
I will fix this early next week after double checking my machines on hand. Daniel's database is much larger than my test set and so we need to support :-)
Thanks Mengdong
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- bounces@alsa-project.org] On Behalf Of Lin, Mengdong Sent: Friday, April 28, 2017 11:03 PM
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.
Yes, it’s better to only use one name. Otherwise, it's possible to exceed 80 characters limit for the card long name since sometimes DMI fields can be long.
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.
I will fix this early next week after double checking my machines on hand. Daniel's database is much larger than my test set and so we need to support :-)
I just submitted a patch to fix this http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/120271.html It passed building and I will test it next Tuesday. 3 Intel machines may have null DMI_SYS_VENDOR.
Thanks Mengdong
Hi,
On Fri, Apr 28, 2017 at 10:21 AM, Lin, Mengdong mengdong.lin@intel.com wrote:
I just submitted a patch to fix this http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/120271.html It passed building and I will test it next Tuesday. 3 Intel machines may have null DMI_SYS_VENDOR.
Thanks! I tested the patch on my platform here, and it is working correctly, I now get the expected vendor name appearing in the string.
Daniel
On 04/29/2017 11:27 PM, Daniel Drake wrote:
Hi,
On Fri, Apr 28, 2017 at 10:21 AM, Lin, Mengdong mengdong.lin@intel.com wrote:
I just submitted a patch to fix this http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/120271.html It passed building and I will test it next Tuesday. 3 Intel machines may have null DMI_SYS_VENDOR.
Thanks! I tested the patch on my platform here, and it is working correctly, I now get the expected vendor name appearing in the string.
Daniel _______________________________________________
Many thanks for testing on your platforms! It also works on my platforms today.
Regards Mengdong
participants (6)
-
Daniel Drake -
Liam Girdwood -
Lin, Mengdong -
Mengdong Lin -
Pierre-Louis Bossart -
Takashi Iwai