From: Lukas Wunner <lukas@wunner.de>
To: Aditya Garg <gargaditya08@live.com>
Cc: Lleyton Gray <lleyton@fyralabs.com>,
Ard Biesheuvel <ardb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>
Subject: Re: [PATCH] x86/efistub: Add options for forcing Apple set_os protocol
Date: Thu, 13 Feb 2025 05:56:09 +0100 [thread overview]
Message-ID: <Z617aePOV7Vj_ffv@wunner.de> (raw)
In-Reply-To: <52B0B784-2FB5-4B7D-8FB6-A7B694EDDFC3@live.com>
On Tue, Feb 11, 2025 at 04:05:12PM +0000, Aditya Garg wrote:
> > On 11 Feb 2025, at 1:28AM, Lukas Wunner <lukas@wunner.de> wrote:
> > FWIW, below would be my suggestion for replacing the DMI-based quirk
> > with one that is based on the number of GPUs.
> >
> > It should invoke the apple_set_os protocol both on dual GPU laptops
> > as well as ones with an eGPU, hence my expectation is that it should
> > fix the issue reported by Lleyton.
>
> This patch does not enable the os set protocol on my MacBook Pro 16 inch 2019
>
> journalctl -k: https://pastebin.com/7etWy0D5
Hm, perhaps Apple's EFI disables the iGPU by default and re-enables it
upon the set_os protocol call. Or I've botched the patch, but I just
double-checked the logic and it seems fine to me.
Could somebody with an eGPU test whether the patch results in the
expected invocation of set_os (and thus a working eGPU)?
If it does, we'd just have to keep apple_match_product_name() as an
alternative condition under which set_os is called.
Thanks,
Lukas
next prev parent reply other threads:[~2025-02-13 4:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-28 20:21 [PATCH] x86/efistub: Add options for forcing Apple set_os protocol Lleyton Gray
2024-12-29 9:59 ` Lukas Wunner
2024-12-29 10:08 ` Ard Biesheuvel
2024-12-29 10:38 ` Lukas Wunner
2024-12-29 18:22 ` Ard Biesheuvel
2024-12-30 3:09 ` Lleyton Gray
2025-02-10 19:25 ` Lukas Wunner
[not found] ` <PN3PR01MB7728B4C94846673A5FFACE29B80B2@PN3PR01MB7728.INDPRD01.PROD.OUTLOOK.COM>
2025-02-10 19:58 ` Lukas Wunner
2025-02-11 16:05 ` Aditya Garg
2025-02-13 4:56 ` Lukas Wunner [this message]
2025-02-10 20:09 ` Lukas Wunner
2025-02-11 5:45 ` Aditya Garg
2025-02-09 16:13 ` Aditya Garg
2025-02-10 10:40 ` Ard Biesheuvel
-- strict thread matches above, loose matches on Subject: below --
2025-02-10 10:51 Aditya Garg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z617aePOV7Vj_ffv@wunner.de \
--to=lukas@wunner.de \
--cc=ardb@kernel.org \
--cc=gargaditya08@live.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lleyton@fyralabs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.