Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a4d0bf2c-34a2-6c43-92fe-6db1d6c00a44@gmail.com>
Date:   Fri, 21 Jul 2023 20:11:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [PATCH] platform/chrome: cros_ec_lpc: Add DMI definition for
 post-Skylake machines running custom Coreboot builds
Content-Language: en-GB
To:     Brian Norris <briannorris@chromium.org>
Cc:     Tzung-Bi Shih <tzungbi@kernel.org>, linux-kernel@vger.kernel.org,
        robbarnes@google.com, lalithkraj@google.com, rrangel@chromium.org,
        bleung@chromium.org, groeck@chromium.org,
        chrome-platform@lists.linux.dev
References: <ZLm3G5G6/gmLZwkn@tora> <ZLooCXV11JCdWOdK@google.com>
 <b1370c4b-7bad-4aac-0fa7-32d6479aa255@gmail.com>
 <CA+ASDXOuJVG7bpXdKMf9nobjJ=qcTiBWVj+TQ3Kpwqct27HSag@mail.gmail.com>
From:   Alicja Michalska <ahplka19@gmail.com>
In-Reply-To: <CA+ASDXOuJVG7bpXdKMf9nobjJ=qcTiBWVj+TQ3Kpwqct27HSag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

That's understandable :)

I spoke with Matt (MrChromebox). It seems like he tried to upstream 
similar patch to what I suggested here few years ago, but it never got 
merged.
Reason for this is that pre-Skylake machines had different DMI vendor name.

For example, that's my DMI information from ELDRID (Google/Volteer 
baseboard) running MrChromebox's firmware and mainline kernel:

[...]
Vendor: coreboot
Manufacturer: Google
[...]

There's a match for coreboot/GOOGLE, but not for coreboot/Google - which 
is the case for all modern-ish machines made past 2018 (reef, octopus, 
hatch, volteer, brya and so on).

As for the concerns regarding removal of outdated DMIs - it's 
understandable, but mainline doesn't work correctly on stock firmware. 
In order to get mainline Linux running correctly on any ChromeOS device, 
user has to flash firmware that contains our patches.

We currently support over 100 machines, starting with first machines 
that used Coreboot (SandyBridge) up to AlderLake (at the moment). 
Flashing those machines (pre-CR50) is as simple as removing Write 
Protect screw and running MrChromebox's script from ChromeOS shell.

Once that's done, Chromebooks behave in the same exact way as UEFI 
systems (because we're using EDK2 as Coreboot payload in our builds) 
with correct ACPI tables and other numerous fixes that are missing from 
stock firmware.

https://chrultrabook.github.io/docs/docs/getting-started.html

On 21/07/2023 19:28, Brian Norris wrote:
> On Fri, Jul 21, 2023 at 10:16 AM Alicja Michalska <ahplka19@gmail.com> wrote:
>> I've explained the reason behind adding this patch, but we'll go with
>> different approach next time around.
> 
> FWIW, I'm also confused about your first sentence the same way
> Tzung-Bi is. If two people are confused by parts of your description,
> then maybe it needs improvement :)
> 
>> Since we're discussing this, I would like to suggest removal of DMI
>> matches for EOL machines from lines 503...535 (Link, Samus, Peppy, Glimmer).
>>
>> Those machines aren't supported by Google anymore. Patch I suggested
>> will match DMI while running custom firmware.
>>
>> If maintainers are okay with it, I will submit a patch removing DMI
>> matches for stock firmware running on those machines since it's not
>> needed anymore.
> 
> That seems actively harmful. These devices continue to work just fine
> with their stock BIOS, even if Google no longer supports updating the
> Google-built OS. That doesn't mean people can't boot other OS'es
> (e.g., their own ChromiumOS builds; or other Linux distros) on them.
> 
> Brian