> On 25 Jul 2024, at 6:12 PM, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > 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. I guess you are talking about 'pci=realloc'. Adding this doesn't fix the issue.
