Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1814685pxp; Thu, 10 Mar 2022 12:43:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyhyM17pNL2+jL3WLJPMNhfd/z8aix1rmIVNsW0ooIb+dejO2SzyowIcNY8vcPbuNNiQ2y X-Received: by 2002:a05:6a00:1950:b0:4f7:8a93:e813 with SMTP id s16-20020a056a00195000b004f78a93e813mr446460pfk.44.1646945006218; Thu, 10 Mar 2022 12:43:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646945006; cv=none; d=google.com; s=arc-20160816; b=o/oShp1avGTfEB60nGVc2vS436RN/Vd4yHqflDfI8gi0UOkuJt27Vp80Vh8X9rnHc9 iBjNT43wqdNz2M0Bqh2AK0qK06oSZrmN8j+REWK7HgjxfaboG2YTRcFLAI3s0J8qzAy4 J8N6WBEaGvTSuXV05p8VtlKN2YzE19SDFOK0aZk3JWQjF2iRYEqaLSMQJ3mcg83nGzc8 gsUDIGWkKtwDNFvB6cAMMor37LAAOpyDjFQk6AcnD1IzESCkZhljrkoeNO7Cqiu6UR6n Lj6y6d5KfYcLONom2Zt/n9MiVvmMnFouktBp7+95Zh+RZ6iGF8oTCCTMT/ExoaqgS8iT CPrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=XU39pyNSH2eq0dpZIXSxiHRUSiX+T3Vk8Q3C8rt+Bns=; b=XseD3iHD5E7kpW7aOYprRcUTxXkbI+TfGrrGgK7vi4l7+bdD/q6323gZGuj3I46ysB zbm93NtPJXi+w44QJHaSIfhj+iN6Cg8HUw8+CvxuIkz2oxqjT4RK3u3Po9ggIIPmt5um OqKHzgeXvo1XHj5NcgkSuTXW4K0nmu29+Vgum4g+vmmochU59rweLIjNJBsfvFtcMxdF w0c5rKCZWlBl2lgJoBO9zVQQ2aigSmnnGNbhSpP7JVfXQ6fq19wpEK6jTqzGb53z93db C+U06TWpamCAoPvBYYVEzrFiaQz7bTnq/dypWp3fHCDZ0Sp0YjEnaSYdj7hdE3JPOeP6 0KXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm2 header.b=CdIft1aM; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="Z3Uw/cWI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u37-20020a056a0009a500b004f7374ac1b9si6021977pfg.207.2022.03.10.12.43.07; Thu, 10 Mar 2022 12:43:25 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm2 header.b=CdIft1aM; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="Z3Uw/cWI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244394AbiCJPBm (ORCPT + 99 others); Thu, 10 Mar 2022 10:01:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345658AbiCJPBJ (ORCPT ); Thu, 10 Mar 2022 10:01:09 -0500 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 925F6195300 for ; Thu, 10 Mar 2022 06:54:29 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 822B2320152C; Thu, 10 Mar 2022 09:54:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 10 Mar 2022 09:54:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; bh=XU39pyNSH2eq0dpZIXSxiHRUSiX+T3Vk8Q3C8r t+Bns=; b=CdIft1aMeCbNbv0TO9CvaUp7I/vx6dR/lleAnxB64oXWo9lTwWoDm6 9kITFan62pf5xs28GR3xKlM70GR1LzW7TZh54EtZGw2oWTJnpbBnG2fwtGGsGvA8 xJs4QEFUtr8uGIRWjhdkN2qHg5syw7WeOGvOjUGT+oF8TBvxY2d4vQNGl28R7mfb Dj4v+m9dx0sYjPCHK3ATIouVWr3mDUYL4X8eLQDEJStXqfHOSTSsHp8Xa+77VyLc VntM05EyJv9Swq95xCMsd76uwhGnyr2nKPE2x/HNhdEN2gntgqQlK5M0gi/XKEOp QtNXkMAhCIFv24nkHE3ar00otwBJEtkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XU39pyNSH2eq0dpZI XSxiHRUSiX+T3Vk8Q3C8rt+Bns=; b=Z3Uw/cWIDpaTLYnYF3mDsBTqDh9zytv6V 8TQVAtCYvRn9+HjBWI4hdeu64risYhJoPL2Pl9sQ1qRHl1erXO7YHbH/8rX8stl5 j618SgsPnkGslSchsAf5PESDsmFtSz79k2y1ktIjroVEaU9/g4awyKaQVzQRtg+I 7qk38DWtYw/soWgnWZJvYFxys96oel1gL7mGjl7hTEj0mZ5rLz46klHAGgDF5sEZ hblc17lnZbTiZ/ffLLpe0sEwHBm9ST5s9mbmQkniZh/M4DcgAI9crz4t11G4jlXv DBX4S3Da75b76tulpk+Ty0DFh8RpmM2i3QN8SPJXEDpvMJ5Gc9m3g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvtddgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucdnkfhovfculdeitddmnecujfgurhepfffhvffukf hfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhmvgcutfhiphgrrhguuceo mhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrthhtvghrnhepleekgeehhf dutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieehgedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnh hordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 09:54:25 -0500 (EST) Date: Thu, 10 Mar 2022 15:54:23 +0100 From: Maxime Ripard To: Paul Kocialkowski Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Linus Walleij , Jagan Teki Subject: Re: [PATCH] drm: of: Properly try all possible cases for bridge/panel detection Message-ID: <20220310145423.but7r7ul4j7h3wxw@houat> References: <20220309143200.111292-1-paul.kocialkowski@bootlin.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lgbhzcypjjo7srta" Content-Disposition: inline In-Reply-To: <20220309143200.111292-1-paul.kocialkowski@bootlin.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --lgbhzcypjjo7srta Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Paul, On Wed, Mar 09, 2022 at 03:32:00PM +0100, Paul Kocialkowski wrote: > While bridge/panel detection was initially relying on the usual > port/ports-based of graph detection, it was recently changed to > perform the lookup on any child node that is not port/ports > instead when such a node is available, with no fallback on the > usual way. >=20 > This results in breaking detection when a child node is present > but does not contain any panel or bridge node, even when the > usual port/ports-based of graph is there. >=20 > In order to support both situations properly, this commit reworks > the logic to try both options and not just one of the two: it will > only return -EPROBE_DEFER when both have failed. >=20 > Signed-off-by: Paul Kocialkowski > Fixes: 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") Thanks, it's in pretty good shape now, but I have a few bike sheds to paint= :) > --- > drivers/gpu/drm/drm_of.c | 93 +++++++++++++++++++++------------------- > 1 file changed, 49 insertions(+), 44 deletions(-) >=20 > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > index 9d90cd75c457..67f1b7dfc892 100644 > --- a/drivers/gpu/drm/drm_of.c > +++ b/drivers/gpu/drm/drm_of.c > @@ -219,6 +219,35 @@ int drm_of_encoder_active_endpoint(struct device_nod= e *node, > } > EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint); > =20 > +static int drm_of_find_remote_panel_or_bridge(struct device_node *remote, > + struct drm_panel **panel, > + struct drm_bridge **bridge) This function performs its look up directly on the struct device_node passed as argument, so I don't think the "remote" in the name is great. Since it's static, we can just call it find_panel_or_bridge, what do you think? > +{ > + int ret =3D -EPROBE_DEFER; > + > + if (panel) { > + *panel =3D of_drm_find_panel(remote); > + if (!IS_ERR(*panel)) > + ret =3D 0; return 0? > + else > + *panel =3D NULL; > + > + } > + > + /* No panel found yet, check for a bridge next. */ > + if (bridge) { > + if (ret) { And the return above allows to remove that test > + *bridge =3D of_drm_find_bridge(remote); > + if (*bridge) > + ret =3D 0; return 0? > + } else { > + *bridge =3D NULL; > + } > + > + } > + > + return ret; And here we can just return -EPROBE_DEFER > +} > + > /** > * drm_of_find_panel_or_bridge - return connected panel or bridge device > * @np: device tree node containing encoder output ports > @@ -249,57 +278,33 @@ int drm_of_find_panel_or_bridge(const struct device= _node *np, > if (panel) > *panel =3D NULL; > =20 > - /** > - * Devices can also be child nodes when we also control that device > - * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > - * > - * Lookup for a child node of the given parent that isn't either port > - * or ports. > - */ > - for_each_available_child_of_node(np, remote) { > - if (of_node_name_eq(remote, "port") || > - of_node_name_eq(remote, "ports")) > - continue; > - > - goto of_find_panel_or_bridge; > + /* Check for a graph on the device node first. */ > + if (of_graph_is_present(np)) { > + remote =3D of_graph_get_remote_node(np, port, endpoint); > + if (remote) { > + ret =3D drm_of_find_remote_panel_or_bridge(remote, panel, > + bridge); > + of_node_put(remote); > + } > } > =20 > - /* > - * of_graph_get_remote_node() produces a noisy error message if port > - * node isn't found and the absence of the port is a legit case here, > - * so at first we silently check whether graph presents in the > - * device-tree node. > - */ > - if (!of_graph_is_present(np)) > - return -ENODEV; > - > - remote =3D of_graph_get_remote_node(np, port, endpoint); > - > -of_find_panel_or_bridge: > - if (!remote) > - return -ENODEV; > + /* Otherwise check for any child node other than port/ports. */ > + if (ret) { > + for_each_available_child_of_node(np, remote) { > + if (of_node_name_eq(remote, "port") || > + of_node_name_eq(remote, "ports")) > + continue; > =20 > - if (panel) { > - *panel =3D of_drm_find_panel(remote); > - if (!IS_ERR(*panel)) > - ret =3D 0; > - else > - *panel =3D NULL; > - } > + ret =3D drm_of_find_remote_panel_or_bridge(remote, panel, > + bridge); > + of_node_put(remote); > =20 > - /* No panel found yet, check for a bridge next. */ > - if (bridge) { > - if (ret) { > - *bridge =3D of_drm_find_bridge(remote); > - if (*bridge) > - ret =3D 0; > - } else { > - *bridge =3D NULL; > + /* Stop at the first found occurrence. */ > + if (!ret) > + break; > } > - > } > =20 > - of_node_put(remote); > return ret; > } So the diff is fairly hard to read, but it ends up as: > int ret =3D -EPROBE_DEFER; > struct device_node *remote; > > if (!panel && !bridge) > return -EINVAL; > if (panel) > *panel =3D NULL; > > /* Check for a graph on the device node first. */ > if (of_graph_is_present(np)) { > remote =3D of_graph_get_remote_node(np, port, endpoint); > if (remote) { > ret =3D drm_of_find_remote_panel_or_bridge(remote,= panel, > bridge); > of_node_put(remote); I think we can simplify this by doing if (!ret) return ret; > } > } > > /* Otherwise check for any child node other than port/ports. */ > if (ret) { And thus we won't have to check for ret here > for_each_available_child_of_node(np, remote) { I'm a bit reluctant with variables that we reuse from one loop to another, especially since it's a bit misleading here. What about using a (loop local) remote variable in the of_graph path, and a loop-local variable node or child here? > if (of_node_name_eq(remote, "port") || > of_node_name_eq(remote, "ports")) > continue; > > ret =3D drm_of_find_remote_panel_or_bridge(remote,= panel, > bridge); > of_node_put(remote); > > /* Stop at the first found occurrence. */ > if (!ret) > break; Ditto, let's just return here > } > } > > return ret; And then we can just return EPROBE_DEFER here (and get rid of ret entirely) Maxime --lgbhzcypjjo7srta Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYioRHwAKCRDj7w1vZxhR xRlZAP98YkMuA9DQnqs5EI61id1YvE2ZQ+/gLGD36nrQVxFZwgD/aq9ge2+PLPGL TJgiShNyXnzB5UY6045THZf+j0+wqgE= =IMzz -----END PGP SIGNATURE----- --lgbhzcypjjo7srta--