devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Riesch <michael.riesch@wolfvision.net>
To: devicetree-compiler@vger.kernel.org
Cc: Heiko Stuebner <heiko@sntech.de>,
	David Gibson <david@gibson.dropbear.id.au>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH] checks: relax graph checks for overlays
Date: Tue, 4 Jun 2024 16:48:46 +0200	[thread overview]
Message-ID: <59a8ed6b-1410-40d1-8a32-69cc8741311a@wolfvision.net> (raw)
In-Reply-To: <20240522-bugfix-relax-checks-for-overlays-v1-1-130c8b85c06b@wolfvision.net>

Hi all,

This is a gentle ping with David and the DT maintainers in Cc: (I am not
sure what the protocol is here, so I'll simply give this a try).

On 5/22/24 16:32, Michael Riesch wrote:
> In device tree overlays, the following patterns occur frequently:
> 
> board.dts:
> /dts-v1/;
> 
> / {
> 	display-controller {
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			vp0: port@0 {
> 				reg = <0>;
> 
> 				vp0_out: endpoint {
> 				};
> 			};
> 
> 			vp1: port@1 {
> 				reg = <1>;
> 			};
> 		};
> 	};
> };
> 
> overlay-endpoint.dtso:
> /dts-v1/;
> /plugin/;
> 
> &{/} {
> 	hdmi-tx-connector {
> 		port {
> 			hdmi_tx_in: endpoint {
> 				remote-endpoint = <&vp0_out>;
> 			};
> 		};
> 	};
> };
> 
> &vp0_out {
> 	remote-endpoint = <&hdmi_tx_in>;
> };
> 
> In this case, dtc expects that the node referenced by &vp0_out is
> named "endpoint", but the name cannot be inferred. Also, dtc
> complains about the connections between the endpoints not being
> bidirectional.
> 
> Similarly, for a different overlay overlay-port.dtso:
> /dts-v1/;
> /plugin/;
> 
> &{/} {
> 	panel {
> 		port {
> 			panel_in: endpoint {
> 				remote-endpoint = <&vp1_out>;
> 			};
> 		};
> 	};
> };
> 
> &vp1 {
> 	vp1_out: endpoint {
> 		remote-endpoint = <&panel_in>;
> 	};
> };
> 
> dtc expects that the node referenced by &vp1 is named "port", but the
> name cannot be inferred.
> 
> Relax the corresponding checks and skip the parts that are not reasonable
> for device tree overlays.
> 
> Cc: Heiko Stuebner <heiko@sntech.de>
> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
> ---
> Habidere,
> 
> This patch fixes several warnings 
>  - Warning (graph_port): /fragment@3: graph port node name should be
>    'port'
>  - Warning (graph_endpoint): /fragment@3/__overlay__: graph endpoint
>    node name should be 'endpoint'
>  - Warning (graph_endpoint): /fragment@3/__overlay__: graph connection
>    to node '/fragment@2/__overlay__/.../port/endpoint' is not
>    bidirectional
> that appear when compiling device tree overlays.
> 
> This first warning popped up e.g., in the scope of [1], [2]. The latter
> two warnings appear regularly when compiling our downstream overlays. As
> we plan to submit them to mainline soon, we'll hit that blocker sooner or
> later.
> 
> Looking forward to your comments!
> 
> Link: https://lore.kernel.org/lkml/20240412-feature-wolfvision-pf5-display-v1-1-f032f32dba1a@wolfvision.net/ [1]
> Link: https://lore.kernel.org/lkml/20240423082941.2626102-1-heiko@sntech.de/T/ [2]

Feedback on this issue would be most welcome!

Thanks a lot and best regards,
Michael

> ---
>  checks.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/checks.c b/checks.c
> index 2fb7ee5..2ea5913 100644
> --- a/checks.c
> +++ b/checks.c
> @@ -1822,10 +1822,14 @@ static void check_graph_port(struct check *c, struct dt_info *dti,
>  	if (node->bus != &graph_port_bus)
>  		return;
>  
> +	check_graph_reg(c, dti, node);
> +
> +	/* skip checks below for overlays */
> +	if (dti->dtsflags & DTSF_PLUGIN)
> +		return;
> +
>  	if (!strprefixeq(node->name, node->basenamelen, "port"))
>  		FAIL(c, dti, node, "graph port node name should be 'port'");
> -
> -	check_graph_reg(c, dti, node);
>  }
>  WARNING(graph_port, check_graph_port, NULL, &graph_nodes);
>  
> @@ -1860,11 +1864,15 @@ static void check_graph_endpoint(struct check *c, struct dt_info *dti,
>  	if (!node->parent || node->parent->bus != &graph_port_bus)
>  		return;
>  
> +	check_graph_reg(c, dti, node);
> +
> +	/* skip checks below for overlays */
> +	if (dti->dtsflags & DTSF_PLUGIN)
> +		return;
> +
>  	if (!strprefixeq(node->name, node->basenamelen, "endpoint"))
>  		FAIL(c, dti, node, "graph endpoint node name should be 'endpoint'");
>  
> -	check_graph_reg(c, dti, node);
> -
>  	remote_node = get_remote_endpoint(c, dti, node);
>  	if (!remote_node)
>  		return;
> 
> ---
> base-commit: ae26223a056e040b2d812202283d47c6e034d063
> change-id: 20240522-bugfix-relax-checks-for-overlays-e72b11df44a1
> 
> Best regards,

  reply	other threads:[~2024-06-04 14:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 14:32 [PATCH] checks: relax graph checks for overlays Michael Riesch
2024-06-04 14:48 ` Michael Riesch [this message]
2024-06-18 20:04   ` Heiko Stübner
2024-06-25 20:15     ` Rob Herring
2024-07-09 11:01       ` Michael Riesch
2024-07-29 22:39 ` Javier Carrasco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59a8ed6b-1410-40d1-8a32-69cc8741311a@wolfvision.net \
    --to=michael.riesch@wolfvision.net \
    --cc=conor+dt@kernel.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).