843ef624a4
Komeda uses the component framework, which does open/close a new devres group around all the bind callbacks. Which means we can use devm_ functions for managing the drm_device cleanup, with leaking stuff in case of deferred probes or other reasons to unbind components, or the component_master. Also note that this fixes a double-free in the probe unroll code, bot drm_dev_put and kfree(kms) result in the kms allocation getting freed. Aside: komeda_bind could be cleaned up a lot, devm_kfree is a bit redundant. Plus I'm not clear on why there's suballocations for mdrv->mdev and mdrv->kms. Plus I'm not sure the lifetimes are correct with all that devm_kzalloc usage ... That structure layout is also the reason why komeda still uses drm_device->dev_private and can't easily be replaced with a proper container_of upcasting. I'm pretty sure that there's endless amounts of hotunplug/hotremove bugs in there with all the unprotected dereferencing of drm_device->dev_private. Reviewed-by: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-33-daniel.vetter@ffwll.ch |
||
|---|---|---|
| .. | ||
| display | ||
| Kconfig | ||
| Makefile | ||
| hdlcd_crtc.c | ||
| hdlcd_drv.c | ||
| hdlcd_drv.h | ||
| hdlcd_regs.h | ||
| malidp_crtc.c | ||
| malidp_drv.c | ||
| malidp_drv.h | ||
| malidp_hw.c | ||
| malidp_hw.h | ||
| malidp_mw.c | ||
| malidp_mw.h | ||
| malidp_planes.c | ||
| malidp_regs.h | ||