On Tue, Feb 11, 2020 at 03:19:56PM +0100, Daniel Vetter wrote: > On Tue, Feb 11, 2020 at 02:52:18PM +0100, Gerd Hoffmann wrote: > > Call bochs_unload via drm_driver.release to make sure we release stuff > > when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid > > touching hardware after device removal. Tidy up here and there. > > > > v4: add changelog. > > v3: use drm_dev_*(). > > v2: move hardware deinit to pci_remove(). > > > > Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Btw I checked around whether there's anything else that obviously needs a > drm_dev_enter/exit, and I spotted the !bochs->mmio check in > bochs_hw_load_edid. That one looks like cargo-cult, there's a single > caller in the init path, so either mmio works at that point or this is > dead code ... slightly confusing. FYI: bochs->mmio actually can be NULL when running on very old qemu versions, the mmio bar was added in qemu release 1.3. All the register access functions in bochs_hw.c have a fallback going to ioports because of that. So there is a reason for the check, even though it is highly unlikely that mmio actually is NULL these days. qemu 1.3 was released in 2013 ... cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel