linux-kernel - Re: [PATCH] x86/efistub: Add options for forcing Apple set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <abe2274b-4341-4212-85a8-113273ce1b18@fyralabs.com>
Date: Sun, 29 Dec 2024 19:09:15 -0800
From: Lleyton Gray <lleyton@...alabs.com>
To: Ard Biesheuvel <ardb@...nel.org>, Lukas Wunner <lukas@...ner.de>
Cc: gargaditya08@...e.com, linux-kernel@...r.kernel.org,
 linux-efi@...r.kernel.org
Subject: Re: [PATCH] x86/efistub: Add options for forcing Apple set_os
 protocol

I believe this is another issue that requires the same set_os quirk. In 
specific, amdgpu fails to initialize when using an AMD eGPU in a T2 
system, unless the set_os protocol is used. Because it's currently 
quirked for the product names of dual-gpu T2 Macs, if you're on a system 
that doesn't match those names (ex. 2018 Mac Mini), there's no way to 
enable the protocol to get an eGPU working.

On 12/29/24 10:22, Ard Biesheuvel wrote:
> On Sun, 29 Dec 2024 at 11:38, Lukas Wunner <lukas@...ner.de> wrote:
>> On Sun, Dec 29, 2024 at 11:08:55AM +0100, Ard Biesheuvel wrote:
>>> IIRC, the original issue is about not being able to use the discrete
>>> GPU with the built-in panel, and the issue about an external GPU did
>>> come up in the discussion - however, this does not affect the built-in
>>> panel at all.
>> The original issue was that the integrated GPU is hidden (powered off)
>> unless the set_os protocol is used.  So only the discrete GPU is
>> available, which results in terrible battery life.  Using set_os
>> keeps the iGPU exposed so the OS can switch to it and power off
>> the dGPU.
>>
> OK, thanks for clearing that up.
>
> But this is distinctly different from the eGPU case we are dealing with here.
>
>> We could have solved this by checking whether there are two PCI devices
>> with VGA class in the system.  But that would have triggered in the
>> iGPU + eGPU case.  We wanted to avoid that and thus quirked for the
>> DMI product names instead.
>>
> Yeah, so it would be good to know what issue are trying to fix with this patch.