From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754193AbdDDKVt (ORCPT ); Tue, 4 Apr 2017 06:21:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45112 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754093AbdDDKVp (ORCPT ); Tue, 4 Apr 2017 06:21:45 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7290C787E6 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7290C787E6 Subject: Re: [PATCH 1/3] firmware: dmi_scan: Add dmi_product_name kernel cmdline option To: Jean Delvare References: <20170225172357.26294-1-hdegoede@redhat.com> <20170225172357.26294-2-hdegoede@redhat.com> <20170303102412.52d4b692@endymion> <43efc13a-d2f9-3fde-c7c0-0471bb6bfc2d@redhat.com> <1489053541.3806.44.camel@suse.de> <5dd43c51-789b-2e73-4e6c-9527a6806c33@redhat.com> Cc: Adrian Hunter , Ulf Hansson , Takashi Iwai , russianneuromancer@ya.ru, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Takashi Iwai From: Hans de Goede Message-ID: Date: Tue, 4 Apr 2017 12:21:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5dd43c51-789b-2e73-4e6c-9527a6806c33@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 04 Apr 2017 10:21:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 09-03-17 11:43, Hans de Goede wrote: > Hi, > > On 09-03-17 10:59, Jean Delvare wrote: >>> So I would really like to see support for this kernel cmdline option merged. >>> Takashi Iwai has been working on some quirks for headphone detection for >>> the GPDwin machine, which also rely on being able to use a fake dmi_id to >>> identify the machine. >> >> I'll discuss that with Takashi when he returns from vacation. > > Ok, lets wait for that then. So Takashi is back (and has responded) but in the mean time I've been thinking about this and tried to find a better solution as I really want the kernel to do the right thing automatically. So I've been dumping all the /sys/class/dmi/id strings on all Bay Trail and Cherry Trail devices I've (7 different models) and seeing if anything stands out. The GPDwin for which I mainly wrote this patch is the only one to set board_vendor to "AMI Corporation", which is a string one would usually expect in bios_vendor. So I decided that we can use normal DMI matching for this after all, to play things safe I've also added a check for the bios_date (which should be reasonable unique) + 2 other strings, resulting in: +static const struct dmi_system_id fix_up_power_blacklist[] = { + { + /* + * Match for the GPDwin which unfortunately uses somewhat + * generic dmi strings, which is why the bios-date match is + * included and we need multiple entries :| These strings have + * been checked against 6 other byt/cht boards and board_vendor + * and board_name are unique to the GPDwin (in the test set) + * where as only one other board has the same board_version. + */ + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_VERSION, "Default string"), + DMI_MATCH(DMI_BIOS_DATE, "10/25/2016"), + }, + }, + { + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_VERSION, "Default string"), + DMI_MATCH(DMI_BIOS_DATE, "11/18/2016"), + }, + }, + { + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_VERSION, "Default string"), + DMI_MATCH(DMI_BIOS_DATE, "02/21/2017"), + }, + }, + { } +}; Which is not the prettiest but gets the job done and has the big advantage over my dmi_product_name kernel cmdline option proposal that it will just work. So you can consider this patch dropped from my pov. Regards, Hans