[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YmAl78qAMAe4bTfk@orome>
Date: Wed, 20 Apr 2022 17:25:35 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Jagan Teki <jagan@...rulasolutions.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] drm: of: Improve error handling in bridge/panel detection
On Thu, Apr 07, 2022 at 11:34:08AM +0200, Paul Kocialkowski wrote:
> With the previous rework of drm_of_find_panel_or_bridge only
> -EPROBE_DEFER is returned while previous behavior allowed -ENODEV
> to be returned when the port/endpoint is either missing or unavailable.
>
> Make the default return code of the function -ENODEV to handle this and
> only return -EPROBE_DEFER in find_panel_or_bridge when the of device is
> available but not yet registered. Also return the error code whenever
> the remote node exists to avoid checking for child nodes.
>
> Checking child nodes could result in -EPROBE_DEFER returned by
> find_panel_or_bridge with an unrelated child node that would overwrite
> a legitimate -ENODEV from find_panel_or_bridge if the remote node from
> the of graph is unavailable. This happens because find_panel_or_bridge
> has no way to distinguish between a legitimate panel/bridge node that
> isn't yet registered and an unrelated node.
>
> Add comments around to clarify this behavior.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
> Fixes: 67bae5f28c89 ("drm: of: Properly try all possible cases for bridge/panel detection")
> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> Cc: Thierry Reding <thierry.reding@...il.com>
> Cc: Linus Walleij <linus.walleij@...aro.org>
>
> ---
> drivers/gpu/drm/drm_of.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
This also fixes the regression that I was seeing on Tegra.
Tested-by: Thierry Reding <treding@...dia.com>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists