[16/17,NOT-FOR-MERGE] media: atomsip: pci: add DMI match for Microsoft Surface 3 with broken DMI (OEMB)
| Message ID | 20211017161958.44351-17-kitakar@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Hans de Goede |
| Headers |
Received: from vger.kernel.org ([23.128.96.18])
by www.linuxtv.org with esmtp (Exim 4.92)
(envelope-from <linux-media-owner@vger.kernel.org>)
id 1mc8vo-006WdH-5E; Sun, 17 Oct 2021 16:22:40 +0000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1344192AbhJQQYs (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other);
Sun, 17 Oct 2021 12:24:48 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35634 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S241666AbhJQQYr (ORCPT
<rfc822;linux-media@vger.kernel.org>);
Sun, 17 Oct 2021 12:24:47 -0400
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com
[IPv6:2607:f8b0:4864:20::431])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B53E4C06161C;
Sun, 17 Oct 2021 09:22:37 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id 187so12809088pfc.10;
Sun, 17 Oct 2021 09:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112;
h=from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=Ue2xdZLYD2ElvWKGNBKjsp5o3GL4BC9cJ58ddnGFYJk=;
b=DTBtZkcBC+FwodEBseqZkDv2IZ3sbKBFdm1Q7+Eos3ebPOnZPsHE/YRyw7ita0zXZJ
pHU6ODfeg43zL8+iI9oCVL4lvZrgwnSEyoZf3Px2umN9VeNn7FMYEdGIMjGSjCy4FVwU
S6F0De+a2X9ZR6XP0q0pe+9mJbZ89kYexXfAwIqUc/LL4y1ASMfiOweD4u/Vz37vRjY7
Oj277c75U5oOA7GKaPtaLV15up3tqdfEN4pZVbJHCgnNbH/8lujknEMSENwoU8Vc86Gk
c8iIHQo1EK9wfLM5ZzRI42LkyYKi6Lpcb+pkOJlgoLwK91dnRvQm/LPiWMvrUSNr02sG
EJ0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=Ue2xdZLYD2ElvWKGNBKjsp5o3GL4BC9cJ58ddnGFYJk=;
b=AIg6XTk3BigdewBPRU28FQgXce8hDOG7PXbuw+kLIe+zCUGGokaQXaHPybdKSTQi+R
EVZlbSkrhnFvHXaINh2lQri8A+6Jehg38f6+l+rzvVG/P0NaO3aqCRu58SYggfTgrz/B
ZtzA9iiQFzr6NQwJyekQTEK+lJhvCbvsOF3I68X0oPhezJmFYZ6qX0r5Thjogpd/5eaM
aHL++P3GNukESirIelpOqzVDmGKnxDOJhycu+08csCUkBnPGxi5vH1wJfHuX+P6Xpjnw
Z+C8O0Jswo7T4YeCoKhfJnKbuCqUlKKQZjNWTfdnJbMvWqGJuvhiLluuvUr1cdnjbfpb
eB7g==
X-Gm-Message-State: AOAM532rcco9Sm7umJMXN1A7DsLExauuzMp13IT8yBquE0l8vD2WLAAl
sw+blmlGInuTCoPiBB3e1tg=
X-Google-Smtp-Source:
ABdhPJzrx9izO18sTvA++aSDIJM8D8l1RUgokAgxf2l7bE461156/sxjT5kjbfRo0wYNe3jJusNaJA==
X-Received: by 2002:a63:9212:: with SMTP id o18mr6329980pgd.392.1634487757241;
Sun, 17 Oct 2021 09:22:37 -0700 (PDT)
Received: from sbwpb-arch.flets-east.jp
([2400:4052:6980:3800:dba7:2b1f:3f26:a5ec])
by smtp.gmail.com with ESMTPSA id
mu11sm5155444pjb.20.2021.10.17.09.22.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 17 Oct 2021 09:22:36 -0700 (PDT)
From: Tsuchiya Yuto <kitakar@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
Patrik Gfeller <patrik.gfeller@gmail.com>,
Tsuchiya Yuto <kitakar@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Aniket Bhattacharyea <aniketmail669@gmail.com>,
Aline Santana Cordeiro <alinesantanacordeiro@gmail.com>,
Yang Yingliang <yangyingliang@huawei.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Alan <alan@linux.intel.com>,
Dinghao Liu <dinghao.liu@zju.edu.cn>,
linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH 16/17] [NOT-FOR-MERGE] media: atomsip: pci: add DMI match for
Microsoft Surface 3 with broken DMI (OEMB)
Date: Mon, 18 Oct 2021 01:19:56 +0900
Message-Id: <20211017161958.44351-17-kitakar@gmail.com>
X-Mailer: git-send-email 2.33.1
In-Reply-To: <20211017161958.44351-1-kitakar@gmail.com>
References: <20211017161958.44351-1-kitakar@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
To: unlisted-recipients:; (no To-header on input)
Precedence: bulk
List-ID: <linux-media.vger.kernel.org>
X-Mailing-List: linux-media@vger.kernel.org
X-LSpam-Score: -4.6 (----)
X-LSpam-Report: No,
score=-4.6 required=5.0 tests=BAYES_00=-1.9,DKIM_ADSP_CUSTOM_MED=0.001,DKIM_SIGNED=0.1,FREEMAIL_FORGED_FROMDOMAIN=0.001,FREEMAIL_FROM=0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3,T_DKIM_INVALID=0.01
autolearn=ham autolearn_force=no
|
| Series |
various fixes for atomisp to make it work
|
|
Commit Message
Tsuchiya Yuto
Oct. 17, 2021, 4:19 p.m. UTC
This commit is added for Surface 3 with broken DMI table. HACK-ish. Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone knows a nicer way to address this, comments are welcome... >8-----------------------------------------------------------------8< On some Microsoft Surface 3, the DMI table gets corrupted for unknown reasons and breaks existing DMI matching used for device-specific quirks. This commit adds the (broken) DMI data into dmi_system_id tables used for quirks so that the driver can enable quirks even on the affected systems. On affected systems, the DMI data will look like this: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:OEMB /sys/devices/virtual/dmi/id/board_vendor:OEMB /sys/devices/virtual/dmi/id/chassis_vendor:OEMB /sys/devices/virtual/dmi/id/product_name:OEMB /sys/devices/virtual/dmi/id/sys_vendor:OEMB Expected: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:Surface 3 /sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/product_name:Surface 3 /sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> --- .../staging/media/atomisp/pci/atomisp_gmin_platform.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
Comments
Hi, On 10/17/21 18:19, Tsuchiya Yuto wrote: > This commit is added for Surface 3 with broken DMI table. HACK-ish. > Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone > knows a nicer way to address this, comments are welcome... > >> 8-----------------------------------------------------------------8< > > On some Microsoft Surface 3, the DMI table gets corrupted for unknown > reasons and breaks existing DMI matching used for device-specific quirks. > > This commit adds the (broken) DMI data into dmi_system_id tables used > for quirks so that the driver can enable quirks even on the affected > systems. > > On affected systems, the DMI data will look like this: > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > chassis_vendor,product_name,sys_vendor} > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > /sys/devices/virtual/dmi/id/board_name:OEMB > /sys/devices/virtual/dmi/id/board_vendor:OEMB > /sys/devices/virtual/dmi/id/chassis_vendor:OEMB > /sys/devices/virtual/dmi/id/product_name:OEMB > /sys/devices/virtual/dmi/id/sys_vendor:OEMB I wonder what the bios_date field contains ? Typically when the DMI strings are no good (e.g. often they contain "Default String" or "To be filled by OEM") we add a check on the bios-date, which together with the broken strings is considered unique enough to still allow a match with broken strings in the kernel. Also have you tried doing something like "load bios/setup defaults" in the BIOS setup ? Maybe that helps ? Regards, Hans > > Expected: > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > chassis_vendor,product_name,sys_vendor} > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > /sys/devices/virtual/dmi/id/board_name:Surface 3 > /sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation > /sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation > /sys/devices/virtual/dmi/id/product_name:Surface 3 > /sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation > > Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> > --- > .../staging/media/atomisp/pci/atomisp_gmin_platform.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > index 948eb6f809f5..3868d64cbc2b 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > @@ -377,6 +377,17 @@ static const struct dmi_system_id gmin_vars[] = { > }, > .driver_data = surface3_vars, > }, > + { > + .ident = "Surface 3", > + .matches = { > + /* DMI data for Surface 3 with broken DMI table */ > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > + DMI_MATCH(DMI_BOARD_NAME, "OEMB"), > + DMI_MATCH(DMI_PRODUCT_NAME, "OEMB"), > + DMI_MATCH(DMI_SYS_VENDOR, "OEMB"), > + }, > + .driver_data = surface3_vars, > + }, > {} > }; > >
Hi, On 10/17/21 18:19, Tsuchiya Yuto wrote: > This commit is added for Surface 3 with broken DMI table. HACK-ish. > Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone > knows a nicer way to address this, comments are welcome... > >> 8-----------------------------------------------------------------8< > > On some Microsoft Surface 3, the DMI table gets corrupted for unknown > reasons and breaks existing DMI matching used for device-specific quirks. > > This commit adds the (broken) DMI data into dmi_system_id tables used > for quirks so that the driver can enable quirks even on the affected > systems. > > On affected systems, the DMI data will look like this: > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > chassis_vendor,product_name,sys_vendor} > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > /sys/devices/virtual/dmi/id/board_name:OEMB > /sys/devices/virtual/dmi/id/board_vendor:OEMB > /sys/devices/virtual/dmi/id/chassis_vendor:OEMB > /sys/devices/virtual/dmi/id/product_name:OEMB > /sys/devices/virtual/dmi/id/sys_vendor:OEMB I wonder what the bios_date field contains ? Typically when the DMI strings are no good (e.g. often they contain "Default String" or "To be filled by OEM") we add a check on the bios-date, which together with the broken strings is considered unique enough to still allow a match with broken strings in the kernel. Also have you tried doing something like "load bios/setup defaults" in the BIOS setup ? Maybe that helps ? Regards, Hans > > Expected: > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > chassis_vendor,product_name,sys_vendor} > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > /sys/devices/virtual/dmi/id/board_name:Surface 3 > /sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation > /sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation > /sys/devices/virtual/dmi/id/product_name:Surface 3 > /sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation > > Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> > --- > .../staging/media/atomisp/pci/atomisp_gmin_platform.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > index 948eb6f809f5..3868d64cbc2b 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c > @@ -377,6 +377,17 @@ static const struct dmi_system_id gmin_vars[] = { > }, > .driver_data = surface3_vars, > }, > + { > + .ident = "Surface 3", > + .matches = { > + /* DMI data for Surface 3 with broken DMI table */ > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > + DMI_MATCH(DMI_BOARD_NAME, "OEMB"), > + DMI_MATCH(DMI_PRODUCT_NAME, "OEMB"), > + DMI_MATCH(DMI_SYS_VENDOR, "OEMB"), > + }, > + .driver_data = surface3_vars, > + }, > {} > }; > >
On Mon, 2021-10-18 at 09:56 +0200, Hans de Goede wrote: > Hi, > > On 10/17/21 18:19, Tsuchiya Yuto wrote: > > This commit is added for Surface 3 with broken DMI table. HACK-ish. > > Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone > > knows a nicer way to address this, comments are welcome... > > > > > 8-----------------------------------------------------------------8< > > > > On some Microsoft Surface 3, the DMI table gets corrupted for unknown > > reasons and breaks existing DMI matching used for device-specific quirks. > > > > This commit adds the (broken) DMI data into dmi_system_id tables used > > for quirks so that the driver can enable quirks even on the affected > > systems. > > > > On affected systems, the DMI data will look like this: > > > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > > chassis_vendor,product_name,sys_vendor} > > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > > /sys/devices/virtual/dmi/id/board_name:OEMB > > /sys/devices/virtual/dmi/id/board_vendor:OEMB > > /sys/devices/virtual/dmi/id/chassis_vendor:OEMB > > /sys/devices/virtual/dmi/id/product_name:OEMB > > /sys/devices/virtual/dmi/id/sys_vendor:OEMB > > I wonder what the bios_date field contains ? Typically when the DMI strings > are no good (e.g. often they contain "Default String" or "To be filled by OEM") > we add a check on the bios-date, which together with the broken strings is > considered unique enough to still allow a match with broken strings in the > kernel. Thank you so much for the comment :-) Here is the full output of "/sys/devices/virtual/dmi/id/*" (not showing files that need root permission to read): $ grep . /sys/devices/virtual/dmi/id/* /sys/devices/virtual/dmi/id/bios_date:03/09/2015 /sys/devices/virtual/dmi/id/bios_release:5.6 /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/bios_version:1.51116.238 /sys/devices/virtual/dmi/id/board_name:OEMB grep: /sys/devices/virtual/dmi/id/board_serial: Permission denied /sys/devices/virtual/dmi/id/board_vendor:OEMB /sys/devices/virtual/dmi/id/board_version:00 grep: /sys/devices/virtual/dmi/id/chassis_serial: Permission denied /sys/devices/virtual/dmi/id/chassis_type:9 /sys/devices/virtual/dmi/id/chassis_vendor:OEMB /sys/devices/virtual/dmi/id/modalias:dmi:bvnAmericanMegatrendsInc.:bvr1.51116.238:bd03/09/2015:br5.6:svnOEMB:pnOEMB:pvrB16D0SM1C4G1X1:rvnOEMB:rnOEMB:rvr00:cvnOEMB:ct9:cvr:sku: grep: /sys/devices/virtual/dmi/id/power: Is a directory /sys/devices/virtual/dmi/id/product_name:OEMB grep: /sys/devices/virtual/dmi/id/product_serial: Permission denied grep: /sys/devices/virtual/dmi/id/product_uuid: Permission denied /sys/devices/virtual/dmi/id/product_version:B16D0SM1C4G1X1 grep: /sys/devices/virtual/dmi/id/subsystem: Is a directory /sys/devices/virtual/dmi/id/sys_vendor:OEMB /sys/devices/virtual/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvr1.51116.238:bd03/09/2015:br5.6:svnOEMB:pnOEMB:pvrB16D0SM1C4G1X1:rvnOEMB:rnOEMB:rvr00:cvnOEMB:ct9:cvr:sku: The "bios_date" ("03/09/2015") looks not broken. I also noticed when writing this mail, regarding the ones that need root permission to read, "board_serial" and "chassis_serial" are now empty. "product_serial" now shows "OEM": $ sudo cat /sys/devices/virtual/dmi/id/product_serial OEM "product_uuid" looks not broken. > Also have you tried doing something like "load bios/setup defaults" in > the BIOS setup ? Maybe that helps ? Unfortunately, there is no option like this... Regards, Tsuchiya Yuto
Hi, On 10/21/21 11:46, Tsuchiya Yuto wrote: > On Mon, 2021-10-18 at 09:56 +0200, Hans de Goede wrote: >> Hi, >> >> On 10/17/21 18:19, Tsuchiya Yuto wrote: >>> This commit is added for Surface 3 with broken DMI table. HACK-ish. >>> Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone >>> knows a nicer way to address this, comments are welcome... >>> >>>> 8-----------------------------------------------------------------8< >>> >>> On some Microsoft Surface 3, the DMI table gets corrupted for unknown >>> reasons and breaks existing DMI matching used for device-specific quirks. >>> >>> This commit adds the (broken) DMI data into dmi_system_id tables used >>> for quirks so that the driver can enable quirks even on the affected >>> systems. >>> >>> On affected systems, the DMI data will look like this: >>> >>> $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ >>> chassis_vendor,product_name,sys_vendor} >>> /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. >>> /sys/devices/virtual/dmi/id/board_name:OEMB >>> /sys/devices/virtual/dmi/id/board_vendor:OEMB >>> /sys/devices/virtual/dmi/id/chassis_vendor:OEMB >>> /sys/devices/virtual/dmi/id/product_name:OEMB >>> /sys/devices/virtual/dmi/id/sys_vendor:OEMB >> >> I wonder what the bios_date field contains ? Typically when the DMI strings >> are no good (e.g. often they contain "Default String" or "To be filled by OEM") >> we add a check on the bios-date, which together with the broken strings is >> considered unique enough to still allow a match with broken strings in the >> kernel. > > Thank you so much for the comment :-) > > Here is the full output of "/sys/devices/virtual/dmi/id/*" (not showing > files that need root permission to read): > > $ grep . /sys/devices/virtual/dmi/id/* > /sys/devices/virtual/dmi/id/bios_date:03/09/2015 > /sys/devices/virtual/dmi/id/bios_release:5.6 > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > /sys/devices/virtual/dmi/id/bios_version:1.51116.238 Interesting, this is the latest BIOS from july 2019 according to: https://support.microsoft.com/en-us/surface/surface-3-update-history-5d86a7bc-03f7-2d27-d858-e90ce637fb52 yet the date is still set to 03/09/2015. I just checked and the BIOS with not corrupted DMI strings also keeps the date at 03/09/2015 in BIOS updates. So the date is correct, and together with matching a coupleof the OEMB-s (which I've never seen anywhere else either) this should be plenty unique. So this not only allows adding this mathc to atomisp, but also to fix sound + wmi on bad DMI data OEMB Surface 3-s, by updating this patch: https://github.com/linux-surface/linux-surface/blob/2fb7e9ae91350098db9a280277f424272816a9ab/patches/5.5/0003-surface3-oemb.patch To include the BIOS-date match and then submitting this upstream (as 2 separate patches please). Tsuchiya, I take it that your Surface 3 has the OEMB issue, so you can actually test this ? If you can prepare 2 patches for the sound + wmi then; and submit them upstream that would be great. Please Cc me on both patches. Regards, Hans > /sys/devices/virtual/dmi/id/board_name:OEMB > grep: /sys/devices/virtual/dmi/id/board_serial: Permission denied > /sys/devices/virtual/dmi/id/board_vendor:OEMB > /sys/devices/virtual/dmi/id/board_version:00 > grep: /sys/devices/virtual/dmi/id/chassis_serial: Permission denied > /sys/devices/virtual/dmi/id/chassis_type:9 > /sys/devices/virtual/dmi/id/chassis_vendor:OEMB > /sys/devices/virtual/dmi/id/modalias:dmi:bvnAmericanMegatrendsInc.:bvr1.51116.238:bd03/09/2015:br5.6:svnOEMB:pnOEMB:pvrB16D0SM1C4G1X1:rvnOEMB:rnOEMB:rvr00:cvnOEMB:ct9:cvr:sku: > grep: /sys/devices/virtual/dmi/id/power: Is a directory > /sys/devices/virtual/dmi/id/product_name:OEMB > grep: /sys/devices/virtual/dmi/id/product_serial: Permission denied > grep: /sys/devices/virtual/dmi/id/product_uuid: Permission denied > /sys/devices/virtual/dmi/id/product_version:B16D0SM1C4G1X1 > grep: /sys/devices/virtual/dmi/id/subsystem: Is a directory > /sys/devices/virtual/dmi/id/sys_vendor:OEMB > /sys/devices/virtual/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvr1.51116.238:bd03/09/2015:br5.6:svnOEMB:pnOEMB:pvrB16D0SM1C4G1X1:rvnOEMB:rnOEMB:rvr00:cvnOEMB:ct9:cvr:sku: > > The "bios_date" ("03/09/2015") looks not broken. > > I also noticed when writing this mail, regarding the ones that need root > permission to read, "board_serial" and "chassis_serial" are now empty. > "product_serial" now shows "OEM": > > $ sudo cat /sys/devices/virtual/dmi/id/product_serial > OEM > > "product_uuid" looks not broken. > >> Also have you tried doing something like "load bios/setup defaults" in >> the BIOS setup ? Maybe that helps ? > > Unfortunately, there is no option like this... > > Regards, > Tsuchiya Yuto >
On Thu, 2021-10-21 at 20:46 +0200, Hans de Goede wrote: > Hi, > > On 10/21/21 11:46, Tsuchiya Yuto wrote: > > On Mon, 2021-10-18 at 09:56 +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 10/17/21 18:19, Tsuchiya Yuto wrote: > > > > This commit is added for Surface 3 with broken DMI table. HACK-ish. > > > > Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone > > > > knows a nicer way to address this, comments are welcome... > > > > > > > > > 8-----------------------------------------------------------------8< > > > > > > > > On some Microsoft Surface 3, the DMI table gets corrupted for unknown > > > > reasons and breaks existing DMI matching used for device-specific quirks. > > > > > > > > This commit adds the (broken) DMI data into dmi_system_id tables used > > > > for quirks so that the driver can enable quirks even on the affected > > > > systems. > > > > > > > > On affected systems, the DMI data will look like this: > > > > > > > > $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ > > > > chassis_vendor,product_name,sys_vendor} > > > > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > > > > /sys/devices/virtual/dmi/id/board_name:OEMB > > > > /sys/devices/virtual/dmi/id/board_vendor:OEMB > > > > /sys/devices/virtual/dmi/id/chassis_vendor:OEMB > > > > /sys/devices/virtual/dmi/id/product_name:OEMB > > > > /sys/devices/virtual/dmi/id/sys_vendor:OEMB > > > > > > I wonder what the bios_date field contains ? Typically when the DMI strings > > > are no good (e.g. often they contain "Default String" or "To be filled by OEM") > > > we add a check on the bios-date, which together with the broken strings is > > > considered unique enough to still allow a match with broken strings in the > > > kernel. > > > > Thank you so much for the comment :-) > > > > Here is the full output of "/sys/devices/virtual/dmi/id/*" (not showing > > files that need root permission to read): > > > > $ grep . /sys/devices/virtual/dmi/id/* > > /sys/devices/virtual/dmi/id/bios_date:03/09/2015 > > /sys/devices/virtual/dmi/id/bios_release:5.6 > > /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. > > /sys/devices/virtual/dmi/id/bios_version:1.51116.238 > > Interesting, this is the latest BIOS from july 2019 according to: > https://support.microsoft.com/en-us/surface/surface-3-update-history-5d86a7bc-03f7-2d27-d858-e90ce637fb52 > yet the date is still set to 03/09/2015. Yeah, I'm a little bit confused about this. > I just checked and the BIOS with not corrupted DMI strings also keeps > the date at 03/09/2015 in BIOS updates. > > So the date is correct, and together with matching a coupleof the OEMB-s > (which I've never seen anywhere else either) this should be plenty > unique. > > So this not only allows adding this mathc to atomisp, but also to fix > sound + wmi on bad DMI data OEMB Surface 3-s, by updating this patch: > > https://github.com/linux-surface/linux-surface/blob/2fb7e9ae91350098db9a280277f424272816a9ab/patches/5.5/0003-surface3-oemb.patch > > To include the BIOS-date match and then submitting this upstream > (as 2 separate patches please). > > Tsuchiya, I take it that your Surface 3 has the OEMB issue, so you > can actually test this ? Yes, my surface3 is also affected and I can test this. > If you can prepare 2 patches for the sound + wmi then; and submit > them upstream that would be great. Please Cc me on both patches. Thank you for the suggestion, but I started having a mixed feeling about sending this kind of patches... This "OEMB" issue is not a design by manufacturers, but simply just it got broken after something (maybe a force power off?). On the other hand, I know there are also indeed some people affected by this issue other than me... If possible, I rather want to fix this broken DMI table, but I couldn't find the way until now though. But again, thank you for the suggestion. I'll consider sending the patches when I gave up fixing it... <Below is completely off topic from atomisp> I think some useful BIOS option might be just hidden. So, I'd like to try this way. I already find the string "Restore Defaults" using uefitool/ifrextract: 0x13429 Form: Save & Exit, FormId: 0x2719 {01 86 19 27 4C 00} [...] 0x134E0 Suppress If {0A 82} 0x134E2 QuestionId: 0x1C3 equals value 0x5 {12 06 C3 01 05 00} 0x134E8 Ref: Restore Defaults, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BC, FormId: 0x2719 {0F 0F 5B 00 5C 00 BC 01 00 00 FF FF 00 19 27} 0x134F7 End If {29 02} [...] I currently don't know how I can call this. I want to try this way when I have some time... Regards, Tsuchiya Yuto
Hi, On 10/27/21 16:47, Tsuchiya Yuto wrote: > On Thu, 2021-10-21 at 20:46 +0200, Hans de Goede wrote: >> Hi, >> >> On 10/21/21 11:46, Tsuchiya Yuto wrote: >>> On Mon, 2021-10-18 at 09:56 +0200, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 10/17/21 18:19, Tsuchiya Yuto wrote: >>>>> This commit is added for Surface 3 with broken DMI table. HACK-ish. >>>>> Not intended for upstreaming. Thus, NOT-FOR-MERGE. But, if someone >>>>> knows a nicer way to address this, comments are welcome... >>>>> >>>>>> 8-----------------------------------------------------------------8< >>>>> >>>>> On some Microsoft Surface 3, the DMI table gets corrupted for unknown >>>>> reasons and breaks existing DMI matching used for device-specific quirks. >>>>> >>>>> This commit adds the (broken) DMI data into dmi_system_id tables used >>>>> for quirks so that the driver can enable quirks even on the affected >>>>> systems. >>>>> >>>>> On affected systems, the DMI data will look like this: >>>>> >>>>> $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ >>>>> chassis_vendor,product_name,sys_vendor} >>>>> /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. >>>>> /sys/devices/virtual/dmi/id/board_name:OEMB >>>>> /sys/devices/virtual/dmi/id/board_vendor:OEMB >>>>> /sys/devices/virtual/dmi/id/chassis_vendor:OEMB >>>>> /sys/devices/virtual/dmi/id/product_name:OEMB >>>>> /sys/devices/virtual/dmi/id/sys_vendor:OEMB >>>> >>>> I wonder what the bios_date field contains ? Typically when the DMI strings >>>> are no good (e.g. often they contain "Default String" or "To be filled by OEM") >>>> we add a check on the bios-date, which together with the broken strings is >>>> considered unique enough to still allow a match with broken strings in the >>>> kernel. >>> >>> Thank you so much for the comment :-) >>> >>> Here is the full output of "/sys/devices/virtual/dmi/id/*" (not showing >>> files that need root permission to read): >>> >>> $ grep . /sys/devices/virtual/dmi/id/* >>> /sys/devices/virtual/dmi/id/bios_date:03/09/2015 >>> /sys/devices/virtual/dmi/id/bios_release:5.6 >>> /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. >>> /sys/devices/virtual/dmi/id/bios_version:1.51116.238 >> >> Interesting, this is the latest BIOS from july 2019 according to: >> https://support.microsoft.com/en-us/surface/surface-3-update-history-5d86a7bc-03f7-2d27-d858-e90ce637fb52 >> yet the date is still set to 03/09/2015. > > Yeah, I'm a little bit confused about this. Yes this is unusual, bit it just seems to be how Microsoft does things on the Surface 3. >> I just checked and the BIOS with not corrupted DMI strings also keeps >> the date at 03/09/2015 in BIOS updates. >> >> So the date is correct, and together with matching a coupleof the OEMB-s >> (which I've never seen anywhere else either) this should be plenty >> unique. >> >> So this not only allows adding this mathc to atomisp, but also to fix >> sound + wmi on bad DMI data OEMB Surface 3-s, by updating this patch: >> >> https://github.com/linux-surface/linux-surface/blob/2fb7e9ae91350098db9a280277f424272816a9ab/patches/5.5/0003-surface3-oemb.patch >> >> To include the BIOS-date match and then submitting this upstream >> (as 2 separate patches please). >> >> Tsuchiya, I take it that your Surface 3 has the OEMB issue, so you >> can actually test this ? > > Yes, my surface3 is also affected and I can test this. > >> If you can prepare 2 patches for the sound + wmi then; and submit >> them upstream that would be great. Please Cc me on both patches. > > Thank you for the suggestion, but I started having a mixed feeling about > sending this kind of patches... This "OEMB" issue is not a design by > manufacturers, but simply just it got broken after something (maybe a > force power off?). On the other hand, I know there are also indeed some > people affected by this issue other than me... > > If possible, I rather want to fix this broken DMI table, but I couldn't > find the way until now though. > > But again, thank you for the suggestion. I'll consider sending the > patches when I gave up fixing it... Since other people are affected too, fixing this is only really useful if the fix is doable by others too. OTOH I just checked: https://github.com/linuxhw/DMI Which is a database of all dmidecode-s uploaded to: https://linux-hardware.org/ And _zero_ of the 56358 dmidecode outputs available there contains OEMB, so this seems to be quite unique to the Surface 3. Which, esp. together with the BIOS date makes the DMI match definitely unique enough. Sometimes DMI strings change on a BIOS update (not break like this, but just change) so having 2 entries for a single device-model is not unheard of. So my cents is to just go with adding the extra entry to dmi_system_id tables and to not spend too much time on this. > <Below is completely off topic from atomisp> > > I think some useful BIOS option might be just hidden. So, I'd like to > try this way. I already find the string "Restore Defaults" using > uefitool/ifrextract: > > 0x13429 Form: Save & Exit, FormId: 0x2719 {01 86 19 27 4C 00} > [...] > 0x134E0 Suppress If {0A 82} > 0x134E2 QuestionId: 0x1C3 equals value 0x5 {12 06 C3 01 05 00} > 0x134E8 Ref: Restore Defaults, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BC, FormId: 0x2719 {0F 0F 5B 00 5C 00 BC 01 00 00 FF FF 00 19 27} > 0x134F7 End If {29 02} > [...] > > I currently don't know how I can call this. I want to try this way when > I have some time... So this is not a normal hidden item which just changes a setting (for which there are known ways to change the setting without flashing the BIOS). But this is some sorta action item which can only be enabled by flashing a custom BIOS, assuming we can somehow replace the Surface 3 custom setup menu with the standard IFR based menu, which in itself is a problem... Regards, Hans
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c index 948eb6f809f5..3868d64cbc2b 100644 --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c @@ -377,6 +377,17 @@ static const struct dmi_system_id gmin_vars[] = { }, .driver_data = surface3_vars, }, + { + .ident = "Surface 3", + .matches = { + /* DMI data for Surface 3 with broken DMI table */ + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), + DMI_MATCH(DMI_BOARD_NAME, "OEMB"), + DMI_MATCH(DMI_PRODUCT_NAME, "OEMB"), + DMI_MATCH(DMI_SYS_VENDOR, "OEMB"), + }, + .driver_data = surface3_vars, + }, {} };