Messages in this thread | | | From | Javier Martinez Canillas <> | Subject | Re: [PATCH 4/8] drm/ssd130x: Add support for DRM_FORMAT_R1 | Date | Fri, 14 Jul 2023 15:08:33 +0200 |
| |
Geert Uytterhoeven <geert@linux-m68k.org> 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
| |