Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 19 Apr 2022 11:56:50 +0200
From:   Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To:     Paul Cercueil <paul@crapouillou.net>
Cc:     airlied@linux.ie, daniel@ffwll.ch, dri-devel@lists.freedesktop.org,
        jagan@amarulasolutions.com, linus.walleij@linaro.org,
        linux-kernel@vger.kernel.org, maarten.lankhorst@linux.intel.com,
        mripard@kernel.org, thomas.petazzoni@bootlin.com,
        tzimmermann@suse.de
Subject: Re: [PATCH v3] drm: of: Properly try all possible cases for
 bridge/panel detection
Message-ID: <Yl6HYke4dJsrq9jj@aptenodytes>
References: <20220329132732.628474-1-paul.kocialkowski@bootlin.com>
 <20220416222141.72321-1-paul@crapouillou.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="XgDB20WdwLjkKw76"
Content-Disposition: inline
In-Reply-To: <20220416222141.72321-1-paul@crapouillou.net>
Precedence: bulk


--XgDB20WdwLjkKw76
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Paul,

On Sat 16 Apr 22, 23:21, Paul Cercueil wrote:
> Hi Paul,
>=20
> This patch breaks the ingenic-drm driver.
>=20
> It calls drm_of_find_panel_or_bridge(np, 0, i, ...) starting for i=3D0, u=
ntil
> -ENODEV is returned, which does not happen anymore.
>=20
> The idea is to probe all the connected panels/bridges, should it be done
> differently now?

I've sent out a different patch which restores -ENODEV at:
https://patchwork.freedesktop.org/patch/481135/

Feel free to try it and reply with tested-by/reviewed-by there.
I've also made a proposal in the thread to skip the "child node" mechanism
as soon as an of graph is present, which would allow covering more legit
cases with -ENODEV (the patch linked above doesn't cover all cases that
need -ENODEV).

Ideally we'd like to remove the child node mechanism entirely, but it may
already be part of a device-tree binding spec.

Cheers,

Paul

--=20
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

--XgDB20WdwLjkKw76
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEJZpWjZeIetVBefti3cLmz3+fv9EFAmJeh2IACgkQ3cLmz3+f
v9GBKAf8DA/g/QCGdK6HmqooGT+X0CNX9NbaVBgCVkWL/wnG+MEsNTNY0g54m8h/
yQexs7+ZudJ19RzZAtJFgj3zcc9u/VXYxipI5Q+zFp9Q7UEuNDfZLS1yxSN+hfr9
fEK1YarFnb/uo/mCWiP2SAJiDtipJe+flEzyutHK6Jf1p2jyAbED4DlZTED8fN1X
uBkMw63pnPdzJcdx0+sm8xLnbY/bkaMjJasIjmfiimQsI09g+TCu5bBlEJIuMDG9
2XrTsUWWN7kex6f+cMakL4nhwL8EM1Hmysga6S4cODnhzJqEODXjMiKtCI+yB+hP
UEUj0lqOrQcgo/RpuKQiFQZxCSkhFA==
=RY5S
-----END PGP SIGNATURE-----

--XgDB20WdwLjkKw76--