From patchwork Sat Feb 25 17:23:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 9591817 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CA0EC6057F for ; Sat, 25 Feb 2017 17:24:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B945D2857C for ; Sat, 25 Feb 2017 17:24:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AE04028581; Sat, 25 Feb 2017 17:24:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A229028582 for ; Sat, 25 Feb 2017 17:24:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751916AbdBYRYP (ORCPT ); Sat, 25 Feb 2017 12:24:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbdBYRYD (ORCPT ); Sat, 25 Feb 2017 12:24:03 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 166E037EEB; Sat, 25 Feb 2017 17:24:04 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-94.ams2.redhat.com [10.36.116.94]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1PHNxAO031937; Sat, 25 Feb 2017 12:24:02 -0500 From: Hans de Goede To: Adrian Hunter , Ulf Hansson , Jean Delvare Cc: Hans de Goede , Takashi Iwai , "russianneuromancer @ ya . ru" , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] firmware: dmi_scan: Add dmi_product_name kernel cmdline option Date: Sat, 25 Feb 2017 18:23:55 +0100 Message-Id: <20170225172357.26294-2-hdegoede@redhat.com> In-Reply-To: <20170225172357.26294-1-hdegoede@redhat.com> References: <20170225172357.26294-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Sat, 25 Feb 2017 17:24:04 +0000 (UTC) Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Unfortunately some firmware has all the DMI strings filled with: "Default String" (or something equally useless). This makes it impossible to apply DMI based quirks to certain machines. This commit adds a dmi_product_name kernel cmdline option which can be used to override the DMI_PRODUCT_NAME string, so that DMI based quirks can still be used on such boards, there are 3 reasons for this: 1) Rather then add cmdline options for all things which can be DMI quirked and thus may need to be specified, this only requires adding code for a single extra cmdline option 2) Some devices can be quite quirky, e.g. the GPD win mini laptop / clamshell x86 machine, needing several quirks in both kernel and userspace (udev hwdb) in this case being able to fake a unique dmi product name allows making these devices usable with a single kernel cmdline option rather then requiring multiple kernel cmdline options + manual userspace tweaking 3) In some case we may be able to successfully get the manufacturer to fix the DMI strings with a firmware update, but not all users may want to update, this will allow users to use DMI based quirks without forcing them to update their firmware Signed-off-by: Hans de Goede --- Note the GPD win: http://www.gpd.hk/gpdwin.asp is the main reason I wrote this patch. I've requested the manufacturer to do a BIOS update fixing the DMI strings, but I cannot guarantee that that will happen. --- drivers/firmware/dmi_scan.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index 54be60e..c99e753 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -1047,3 +1047,17 @@ void dmi_memdev_name(u16 handle, const char **bank, const char **device) } } EXPORT_SYMBOL_GPL(dmi_memdev_name); + +static int __init dmi_parse_dmi_product_name(char *str) +{ + static char prod_name[32]; + + if (!str) + return -EINVAL; + + strlcpy(prod_name, str, sizeof(prod_name)); + dmi_ident[DMI_PRODUCT_NAME] = prod_name; + + return 0; +} +early_param("dmi_product_name", dmi_parse_dmi_product_name);