On Tue, Jun 01, 2021 at 07:12:27PM +0200, Greg KH wrote: > On Tue, Jun 01, 2021 at 05:56:40PM +0200, Daniel Vetter wrote: > > On Fri, May 28, 2021 at 04:26:07PM +0800, Huacai Chen wrote: > > > We should call vga_arb_device_init() after PCI enumeration, otherwise it > > > may fail to select the default VGA device. Since vga_arb_device_init() > > > and PCI enumeration function (i.e., pcibios_init() or acpi_init()) are > > > both wrapped by subsys_initcall(), their sequence is not assured. So, we > > > use subsys_initcall_sync() instead of subsys_initcall() to wrap vga_arb_ > > > device_init(). > > Trying to juggle levels like this always fails if you build the code as > a module. > > Why not fix it properly and handle the out-of-order loading by returning > a "deferred" error if you do not have your resources yet? It's not a driver, it's kinda a bolted-on-the-side subsytem of pci. So not something you can -EPROBE_DEFER I think, without potentially upsetting the drivers that need this. Which might mean we should move this into pci subsystem proper perhaps? Then adding the init call at the right time becomes trivial since we just plug it in at the end of pci init. Also maybe that's how distros avoid this pain, pci is built-in, vgaarb is generally a module, problem solved. Bjorn, would you take this entire vgaarb.c thing? From a quick look I don't think it has a drm-ism in it (unlike vga_switcheroo, but that works a bit differently and doesn't have this init order issue). Thoughts on this? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
