Hi Maxime, other DRM maintainers, On Thu, 24 Apr 2025 20:59:07 +0200 Luca Ceresoli <luca.ceres...@bootlin.com> wrote:
> devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM > bridge, and the only one supported from now on. It is also necessary for > implementing reference counting and thus needed to support removal of > bridges from a still existing DRM pipeline without use-after-free. > > This series converts all DRM bridges to the new API. > > Patch 1 uses a coccinelle semantic patch to mass-convert some of those > drivers -- thanks Maxime for having suggested the patch that served as a > starting point for me. I was unable to come up with a better patch > converting more drivers though, so I converted all others manually. Most of > them were trivial. I left the non-trivial ones at the end of the series to > help reviewers know where to look at more carefully. > > Due to the large number of touched files, the list of recipients generated > by get_maintainers (b4 actually) was huge, 60~70 people (not counting > mailing lists), so I took the liberty of trimming the list as reasonably as > I could to DRM maintainers and frequent contributors, and added all other > recipients individually per-patch. I hope this is fine. Don't hesitate to > suggest more people which should be Cc-ed in a future series, or a better > Cc policy. > > Current plan and status of the DRM bridge refcounting work: > > A. ✔ add new alloc API and refcounting -> (now in drm-misc-next) > B. ➜ convert all bridge drivers to new API (this series) > C. … documentation, kunit tests, debugfs improvements (v1 under discussion) > D. after (B), add get/put to drm_bridge_add/remove() + attach/detech() > E. after (B), convert accessors; this is a large work and can be done > in chunks > > Luca > > [0] > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0cc6aadd7fc1e629b715ea3d1ba537ef2da95eec > > Signed-off-by: Luca Ceresoli <luca.ceres...@bootlin.com> Maintaining this long series is quite painful. Do you think at least patches with a R-by or T-by tag could be merged before I send v3, so we can relieve the maintenance effort, mail servers, and everybody's inboxes? Otherwise I could split this series in parts somewhat arbitrarily, but that is an additional work on its own and is not a perfect solution as it would not provide the big picture. Best regards, Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
