Hi Luca,
Thanks for your fast reply and all your work here.
On Tue, Oct 14, 2025 at 12:31:35PM +0200, Luca Ceresoli wrote:
> Let me have a look at the DRM_IMX driver, I'll try to send a series
> converting it to the new API within today.
I will gladly test, thanks!
> I recently sent a series proposing to make drm_bridge_add() mandatory
> before drm_bridge_attach() in the docs and warn if that is violated [1]. If
> you apply patch 4 of that series you should see the warning.
I gave it a quick try and did not see the warning. Some printk debugging
told me that `list_empty(&bridge->list)`, inside drm_bridge_attach, is
returning 0.
> > However, later on, another regression seems to be introduced by
> > commit 8fa5909400f3 ("drm/bridge: get the bridge returned by
> > drm_bridge_chain_get_first_bridge()")
> > so reverting 94d50c1a2ca3 on top of drm-misc-next does not solve
> > everything. This was tested by rebasing drm-misc-next onto (260f6f4fda93
> > plus the revert of 94d50c1a2ca3) and then bisecting.
> >
> > So in v6.18-rc1, both regressions are present.
> >
> > There, I get the following additional warnings:
> >
> > [ 9.732278] ------------[ cut here ]------------
> > [ 9.732336] WARNING: CPU: 0 PID: 38 at lib/refcount.c:22
> > drm_bridge_get+0x10/0x18
> > [ 9.744608] refcount_t: saturated; leaking memory.
>
> Not sure here, but it may well be another symptom of the same bug: the
> refcount was not initialized correctly, so it is found inconsistent later
> when trying to increase it. Let's fix the known issue and then we'll see.
Makes sense to me.
Kind regards,
Ernest
