[PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
Biju Das
biju.das.jz at bp.renesas.com
Tue Apr 28 06:31:34 PDT 2026
Hi Luca,
> -----Original Message-----
> From: Luca Ceresoli <luca.ceresoli at bootlin.com>
> Sent: 28 April 2026 14:20
> Subject: Re: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
>
> On Tue Apr 28, 2026 at 1:58 PM CEST, Biju Das wrote:
> > Hi all,
> >
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces at lists.freedesktop.org> On Behalf
> >> Of Biju Das
> >> Sent: 28 April 2026 12:50
> >> Subject: RE: [PATCH v2 08/11] drm/bridge: adv7511: switch to
> >> of_drm_get_bridge_by_endpoint()
> >>
> >>
> >> Hi,
> >>
> >> Thanks for the patch.
> >>
> >> > -----Original Message-----
> >> > From: dri-devel <dri-devel-bounces at lists.freedesktop.org> On Behalf
> >> > Of Luca Ceresoli
> >> > Sent: 28 April 2026 10:16
> >> > Subject: [PATCH v2 08/11] drm/bridge: adv7511: switch to
> >> > of_drm_get_bridge_by_endpoint()
> >> >
> >> > This driver calls drm_of_find_panel_or_bridge() with a NULL pointer
> >> > in the @panel parameter, thus using a reduced feature set of that function.
> >> > Replace this call with the simpler of_drm_get_bridge_by_endpoint().
> >> >
> >> > Since of_drm_get_bridge_by_endpoint() increases the refcount of the
> >> > returned bridge, ensure it is put on removal. To achieve this,
> >> > instead of adding an explicit drm_bridge_put(), migrate to the
> >> > bridge::next_bridge pointer which is
> >> automatically put when the bridge is eventually freed.
> >> >
> >> > Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>
> >> > ---
> >> > drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
> >> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +++++------
> >> > 2 files changed, 5 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > index 8be7266fd4f4..12c95198d9a4 100644
> >> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > @@ -354,7 +354,6 @@ struct adv7511 {
> >> > enum drm_connector_status status;
> >> > bool powered;
> >> >
> >> > - struct drm_bridge *next_bridge;
> >> > struct drm_display_mode curr_mode;
> >> >
> >> > unsigned int f_tmds;
> >> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > index 6bd76c1fb007..498e38579a0f 100644
> >> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > @@ -851,8 +851,8 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
> >> > struct adv7511 *adv = bridge_to_adv7511(bridge);
> >> > int ret = 0;
> >> >
> >> > - if (adv->next_bridge) {
> >> > - ret = drm_bridge_attach(encoder, adv->next_bridge, bridge,
> >> > + if (adv->bridge.next_bridge) {
> >> > + ret = drm_bridge_attach(encoder, adv->bridge.next_bridge,
> >> > +bridge,
> >> > flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >> > if (ret)
> >> > return ret;
> >> > @@ -1251,10 +1251,9 @@ static int adv7511_probe(struct i2c_client
> >> > *i2c)
> >> >
> >> > memset(&link_config, 0, sizeof(link_config));
> >> >
> >> > - ret = drm_of_find_panel_or_bridge(dev->of_node, 1, -1, NULL,
> >> > - &adv7511->next_bridge);
> >> > - if (ret && ret != -ENODEV)
> >> > - return ret;
> >> > + adv7511->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node, 1, -1);
> >> > + if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -ENODEV)
> >> > + return PTR_ERR(adv7511->bridge.next_bridge);
> >>
> >> Does it crash, if the error is -EPROBE_DEFER?
> >
> > I see a crash with patch [1], which is fixed by avoiding the direct assignment.
>
> Ah, dammit! Good catch, thanks for the quick testing and follow-up!
>
> Indeed this driver assumes next_bridge is either NULL or a valid pointer, but due to the 'if(IS_ERR()
> && some_other_condition)' now it can also be -ENODEV (not -EPROBE_DEFER, but that's irrelevant).
>
> This affects the msm and zynqmp_dp patches equally.
>
> I'm sending a v3 soon with these fixed. I'm just not sure which approach to use to fix (same for all
> the 3 patches). Alternatives are:
>
> 1. -ENODEV is accepted, set next_bridge to NULL when it happens:
>
> - if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -
> ENODEV)
> - return PTR_ERR(adv7511->bridge.next_bridge);
> + if (IS_ERR(adv7511->bridge.next_bridge)) {
> + if (PTR_ERR(adv7511->bridge.next_bridge) == -ENODEV)
> + adv7511->bridge.next_bridge = NULL;
> + else
> + return PTR_ERR(adv7511->bridge.next_bridge);
The point is you cannot return PTR_ERR as it will lead to crash, if it is
direct assignment.
if (IS_ERR(adv7511->bridge.next_bridge)) {
int err = PTR_ERR(adv7511->bridge.next_bridge);
adv7511->bridge.next_bridge = NULL;
return err;
}
Cheers,
Biju
> 2. let nexxt_bridge hold -ENODEV but ignore it when it is used (only in
> the attach op, for all 3 drivers):
>
> - if (adv->bridge.next_bridge) {
> + if (!IS_ERR_OR_NULL(adv->bridge.next_bridge)) {
>
> While the latter approach involves less code, it might let errors sneak in in case new usages of
> next_bridge are added with just a NULL check.
>
> Opinions about the two?
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
More information about the linux-arm-kernel
mailing list