On Thu, Jan 15, 2026 at 6:02 AM Thomas Zimmermann <[email protected]> wrote: > > That's really not going to work. For example, in the current series, you > invoke devm_aperture_remove_conflicting_pci_devices_done() after > drm_mode_reset(), drm_dev_register() and drm_client_setup().
That's perfectly fine, devm_aperture_remove_conflicting_pci_devices_done is removing the reload behavior not doing anything. This series, essentially, just adds a "defer" statement to aperture_remove_conflicting_pci_devices that says "reload sysfb if this driver unloads". devm_aperture_remove_conflicting_pci_devices_done just cancels that defer. You could ask why have devm_aperture_remove_conflicting_pci_devices_done at all then and it's because I didn't want to change the default behavior of anything. There are three cases: 1) Driver fails to load before aperture_remove_conflicting_pci_devices, in which case sysfb is still active and there's no problem, 2) Driver fails to load after aperture_remove_conflicting_pci_devices, in which case sysfb is gone and the screen is blank 3) Driver is unloaded after the probe succeeded. igt tests this too. Without devm_aperture_remove_conflicting_pci_devices_done we'd try to reload sysfb in #3, which, in general makes sense to me and I'd probably remove it in my drivers, but there might be people or tests (again, igt does it and we don't need to flip-flop between sysfb and the driver there) that depend on specifically that behavior of not having anything driving fb so I didn't want to change it. So with this series the worst case scenario is that the driver that failed after aperture_remove_conflicting_pci_devices changed the hardware state so much that sysfb can't recover and the fb is blank. So it was blank before and this series can't fix it because the driver in its cleanup routine will need to do more unwinding for sysfb to reload (i.e. we'd need an extra patch to unwind the driver state). There also might be the case of some crazy behavior, e.g. pci bar resize in the driver makes the vga hardware crash or something, in which case, yea, we should definitely skip this patch, at least until those drivers properly cleanup on exit. z
smime.p7s
Description: S/MIME Cryptographic Signature
