On Fri, Jan 16, 2026 at 2:58 AM Thomas Zimmermann [off-list ref] wrote:

Hi

Am 16.01.26 um 04:59 schrieb Zack Rusin:

quoted

On Thu, Jan 15, 2026 at 6:02 AM Thomas Zimmermann [off-list ref] wrote:

quoted

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.

This is all predicated on drivers actually cleaning up after
themselves. I don't think any amount of good will or api design is
going to fix device specific state mismatches.

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.

quoted

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.

I don't think that approach is going to work. I don't think there's
anything that can be done if drivers didn't cleanup everything they've
done that might have broken sysfb on unload. I'm going to drop it
then, it's obviously a shame because it works fine with virtualized
drivers and they're ones that would likely profit from this the most
but I'm sceptical that I could do full system state set reset in a
generalized fashion for hw drivers or that the work required would be
worth the payoff.

z