Huacai Chen <chenhuacai@xxxxxxxxxx> writes: Hello Huacai, > Hi, Javier, > > On Wed, Nov 8, 2023 at 4:24 PM Javier Martinez Canillas > <javierm@xxxxxxxxxx> wrote: >> >> Hello, >> >> On Wed, Nov 8, 2023 at 9:14 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: >> > >> > Hi, >> > >> >> [...] >> >> > >> > Relying on linking order is just as unreliable. The usual workaround is >> > to build native drivers as modules. But first, please investigate where >> > the current code fails. >> > >> >> I fully agree with Thomas here. This is just papering over the issue. >> >> I'll read the lengthy thread now to see if I can better understand >> what's going on here. > Have you understood enough now? I really don't want the original patch > to be reverted. > I discussed this with Thomas but we didn't fully understand what was going on. In theory, it should work since the native driver should disable sysfb and remove the registered platform device. But it seems that this does not happen for Jaak and others who reported the same issue. Something that we noticed is that PCI fixups happen in fs_initcall_sync() and since the sysfb_init() should happen after the PCI subsystem for EFI quirks, we think that at least should be moved after that initcall level. That means rootfs_initcall() onwards, and that takes it almost at the same before your patch. The safest would be to move sysfb_init() to initcall device_initcall_sync() and make sure that happens after all the native DRM drivers, since module_init() happens at device_initcall(). I think that Thomas meant to send a patch to do that change. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
