Message-ID: <096e953682fed458d438d1cde57371d7358b5d7b.camel@gmail.com>
Date:   Wed, 27 Oct 2021 23:47:24 +0900
From:   Tsuchiya Yuto <kitakar@...il.com>
To:     Hans de Goede <hdegoede@...hat.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)

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

Powered by blists - more mailing lists