[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71b5b886-2ca1-27a9-6776-b3bcc430e5ed@redhat.com>
Date: Mon, 18 Oct 2021 09:56:45 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Tsuchiya Yuto <kitakar@...il.com>
Cc: Patrik Gfeller <patrik.gfeller@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Aniket Bhattacharyea <aniketmail669@...il.com>,
Aline Santana Cordeiro <alinesantanacordeiro@...il.com>,
Yang Yingliang <yangyingliang@...wei.com>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Alan <alan@...ux.intel.com>,
Dinghao Liu <dinghao.liu@....edu.cn>,
linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/17] [NOT-FOR-MERGE] media: atomsip: pci: add DMI match
for Microsoft Surface 3 with broken DMI (OEMB)
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@...il.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,
> + },
> {}
> };
>
>
Powered by blists - more mailing lists