aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorDaniel Vetter <[email protected]>2020-04-15 09:40:07 +0200
committerDaniel Vetter <[email protected]>2020-04-28 16:04:00 +0200
commit843ef624a491fabc3f0829c341a33fc4cc008000 (patch)
tree56fb6d9ed94038d086ee26512afecdb392b321fa /tools/perf/scripts/python/stackcollapse.py
parentb8d91c0a770e2c6608a3cacc82f3674d9745c90e (diff)
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 <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: "James (Qian) Wang" <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Mihail Atanassov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions