drm/komeda: use devm_drm_dev_alloc
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 15 Apr 2020 07:40:07 +0000 (09:40 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 28 Apr 2020 14:04:00 +0000 (16:04 +0200)
commit843ef624a491fabc3f0829c341a33fc4cc008000
tree56fb6d9ed94038d086ee26512afecdb392b321fa
parentb8d91c0a770e2c6608a3cacc82f3674d9745c90e
drm/komeda: use devm_drm_dev_alloc

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
drivers/gpu/drm/arm/display/komeda/komeda_kms.c