On Fri, Jan 16, 2026 at 2:58 AM Thomas Zimmermann <[email protected]> wrote: > > 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.
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. > > > 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
smime.p7s
Description: S/MIME Cryptographic Signature
