Hi
Am 16.01.26 um 04:59 schrieb Zack Rusin:
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.
Exactly. And if that reload happens after the hardware state has been
changed, the result is undefined.
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).
The current recovery/reload is not reliable in any case. A number of
high-profile devs have also said that it doesn't work with their driver.
The same is true for ast. So the current approach is not going to happen.
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.
There's nothing crazy here. It's standard probing code.
If you want to to move forward, my suggestion is to look at the proposal
with the aperture_funcs callbacks that control sysfb device access. And
from there, build a full prototype with one or two drivers.
Best regards
Thomas
z
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
