On Wed, 24 Jul 2024 at 18:31, Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Wed, Jul 24, 2024 at 04:26:58PM +0000, Aditya Garg wrote: > > > On 24 Jul 2024, at 9:31 PM, Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > I note that on x86, the efistub walks over all PCI devices in the system > > > (see setup_efi_pci() in drivers/firmware/efi/libstub/x86-stub.c) and > > > retrieves the Device ID and Vendor ID. We could additionally retrieve > > > the Class Code and count the number of GPUs in the system by checking > > > whether the Class Code matches PCI_BASE_CLASS_DISPLAY. If there's > > > at least 2 GPUs in the system, invoke apple_set_os. > > > > This also looks like a good idea, but I'm not well aware of the pci > > quirks in the Linux kernel. So, would consider it a bug report for > > the maintainers to fix. > > This is not a PCI quirk in the kernel. The efistub is a separate > program. I'm saying that the efistub already walks over all PCI devices, > it would be trivial to hook into this to count GPUs, recognize the T2 > device or do something else entirely. > Thanks for the analysis, and for the suggestions. I wouldn't object to changes to the EFI stub that implement something along these lines, although I'd like to understand a bit better what the actual issue is. If PCI resource allocation is the culprit here, wouldn't it be better to force Linux to reallocate those from scratch? IIRC there is already a command line option for this.
