Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes: Hello Geert, > Hi Javier, [...] >> > >> > The display should not be updated after .remove(), so I think plain >> > devm_kcalloc() should be fine. >> >> That was precisely my point, that there could be atomic commits even after >> the driver has been removed (e.g: if using DRM fbdev emulation, user-space >> can keep the /dev/fb0 opened and continue updating the framebuffer. That's >> not released until the fd is closed and struct fb_ops .fb_destroy called. >> >> But that's a general rule in DRM, any user-visible resource must not be >> allocated using device managed resources and instead use the drm_device >> managed resources helpers. To make sure that are not released until the >> last call to drm_dev_put(): > > These buffers are not user-visible, so they should not be accessed > after .remove(). When these are accessed, the next step would be > to write the buffer data to the device, which would also fail miserably, > as the regmap, GPIO, and regulator are hardware resources managed > through devm_*(). > Right, given that we do the shadow buffer -> native buffer copy, I thought of it as if as a user-visible (well, user-accessible I guess) but you are correct that's not and trying to write to the device will fail anyways. So devm_* should be enough indeed and if there are problems with that, it would be a different bug in the driver to fix. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
