Hi Rob
Cc Geert
> > > Sorry to bother you but I wonder if you could help me understand why the
> > > dtc checker warns for the issues I tried to work around in this patch,
> > > and if possible how I can improve my solution to get rid of the
> > > warnings.
> > >
> > > This patch addresses the same problem for a few different devices. I
> > > will focus on the last one (/soc/isp@fed00000/ports/port@0) for my
> > > question, but all warnings here have the same issue.
> > >
> > > I have a port node the represents a sink for a video input. This sink
> > > can either be connected to source A or source B, but not both at the
> > > same time. So each possible source is represented by an endpoint in the
> > > port node. Each endpoint have specific register address on the port bus
> > > that is described in the bindings as they map to different physical pins
> > > on the hardware.
> > >
> > > The issue I have is that not all hardware configurations have both
> > > source A and B populated. All combinations of A, B and C are possible
> > > depending on the platform.
> > >
> > > A)
> > > ports {
> > > ...
> > > port@0 {
> > > ...
> > > sourceA: endpoint@0 {
> > > reg = <0>
> > > };
> > > sourceB: endpoint@1 {
> > > reg = <1>
> > > };
> > > };
> > > };
> > >
> > > B)
> > > ports {
> > > ...
> > > port@0 {
> > > ...
> > > sourceA: endpoint@0 {
> > > reg = <0>
> > > };
> > > };
> > > };
> > >
> > > C)
> > > ports {
> > > ...
> > > port@0 {
> > > ...
> > > sourceB: endpoint@1 {
> > > reg = <1>
> > > };
> > > };
> > > };
> > >
> > > For option A and C the checker is happy, but for option B the warnings
> > > this patch tries to address are triggered. While reading the
> > > dtc/checks.c I find check_graph_child_address() is the one that is
> > > triggering the warning. And this function explicitly checks for port
> > > buses with a single endpoint with a register value of 0.
> > >
> > > This check was added way back in 2018 in commit df536831d02c ("checks:
> > > add graph binding checks"). But I can't find any information on the
> > > specifics. Is this design a bad idea for port buses for some reason I
> > > don't understand? AFIU this design is possible on other type of buses?
> > > And do you have any guidance on how I can dig myself out of this hole?
> >
> > Don't.
> >
> > The check is only with W=1. It is for cases where there is never more
> > than 1 endpoint. dtc can't distinguish when that is the case, so there's
> > going to be cases to ignore. Perhaps we could demote it W=2, but I'd
> > prefer not to. Making W=1 warning free may be a platform goal, but
> > that's not an overall go. If we fix something everywhere, then the check
> > is promoted.
>
> I get this warning, but I'm not using W=1 option.
> I'm using v6.13-rcX, but which kernel version hide it in normal compile
> (= without W=1) ?
>
> ${linux}/arch/arm64/boot/dts/renesas/r8a779a0.dtsi:1189.12-1199.7:
> Warning (graph_child_address): /soc/video@e6ef0000/ports/port@2:
> graph node has single child node 'endpoint@0', #address-cells/#size-cells
> are not necessary
I got same warning (without W=1), on isp too.
How to solve it ?
linux/arch/arm64/boot/dts/renesas/r8a779g0.dtsi:2291.12-2301.7: Warning (graph_child_address): /soc/isp@fed00000/
ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary
Traceback (most recent call last):
File "/home/morimoto/my_python/lib/python3.12/site-packages/jsonschema/validators.py", line 966, in resolve_fragment
document = document[part]
~~~~~~~~^^^^^^
TypeError: 'bool' object is not subscriptable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/morimoto/my_python/bin/dt-validate", line 8, in <module>
Thank you for your help !!
Best regards
---
Kuninori Morimoto
