04.10.2021 23:56, Thierry Reding пишет:

quoted

From: David Heidelberg <david@ixit.cz>

Name clocks and regulators according to DT-schema to fix warnings such as:

arch/arm/boot/dts/tegra20-acer-a500-picasso.dt.yaml: /: clock@0: 'anyOf' conditional failed, one must be fixed:
 	'reg' is a required property
 	'ranges' is a required property
 	From schema: /home/runner/.local/lib/python3.8/site-packages/dtschema/schemas/root-node.yaml

Signed-off-by: David Heidelberg <david@ixit.cz>
---
 arch/arm/boot/dts/tegra114-dalmore.dts        | 16 +++++------
 arch/arm/boot/dts/tegra114-roth.dts           | 14 +++++-----
 arch/arm/boot/dts/tegra114-tn7.dts            |  8 +++---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts     | 26 ++++++++---------
 arch/arm/boot/dts/tegra124-nyan.dtsi          | 28 +++++++++----------
 arch/arm/boot/dts/tegra124-venice2.dts        | 28 +++++++++----------
 .../boot/dts/tegra20-acer-a500-picasso.dts    | 12 ++++----
 arch/arm/boot/dts/tegra20-harmony.dts         | 16 +++++------
 arch/arm/boot/dts/tegra20-medcom-wide.dts     |  8 +++---
 arch/arm/boot/dts/tegra20-paz00.dts           |  6 ++--
 arch/arm/boot/dts/tegra20-plutux.dts          |  8 +++---
 arch/arm/boot/dts/tegra20-seaboard.dts        | 16 +++++------
 arch/arm/boot/dts/tegra20-tamonten.dtsi       |  4 +--
 arch/arm/boot/dts/tegra20-tec.dts             |  8 +++---
 arch/arm/boot/dts/tegra20-trimslice.dts       | 12 ++++----
 arch/arm/boot/dts/tegra20-ventana.dts         | 12 ++++----
 .../tegra30-asus-nexus7-grouper-common.dtsi   | 10 +++----
 ...egra30-asus-nexus7-grouper-maxim-pmic.dtsi |  4 +--
 .../tegra30-asus-nexus7-grouper-ti-pmic.dtsi  |  2 +-
 arch/arm/boot/dts/tegra30-beaver.dts          | 20 ++++++-------
 arch/arm/boot/dts/tegra30-cardhu-a02.dts      | 12 ++++----
 arch/arm/boot/dts/tegra30-cardhu-a04.dts      | 14 +++++-----
 arch/arm/boot/dts/tegra30-cardhu.dtsi         | 28 +++++++++----------
 23 files changed, 156 insertions(+), 156 deletions(-)

I'm not sure about this one. Last time I talked to Rob about this, he
seemed to suggest that reintroducing the top-level clocks and regulators
nodes was preferable to doing these renamed.

Rob, which way do we want to decide this? If we do want to reintroduce
the clocks and regulators top-level "bus" nodes, we probably need the
tooling to learn to accept that, because I /think/ the reason why they
were originally dropped a while ago was because the tooling complained
about the "bus" nodes not being named "bus" (I think that was because
they traditionally have had "simple-bus" in their compatible and hence
the "simple-bus" schema was applied along with the schema for the node
name.

So I think we have a couple of options here:

  * Make it so that these nodes no longer need the "simple-bus"
    compatible string: this would need new code to parse these nodes
    and instantiate platform device for them like "simple-bus" would
    do.

  * Relax the rules for the "simple-bus" compatible string. It looks
    like this would be the simplest, because we could just extend the
    pattern in the "simple-bus" schema. There's a slight catch, though,
    because we'd also need to allow "#size-cells = <0>" for these. And
    maybe also make "ranges" not required because it doesn't make sense
    for #size-cells = <0>.

  * Create a new compatible string specifically for these. That would be
    similar to the first option, except that it's perhaps a bit more
    formal. We could basically create a separate schema for this type of
    bus, so that simple-bus could remain as-is.

Perhaps there's also yet another option that I haven't thought of that's
better than the above.

Quoting in full below for you to get a better picture of what kinds of
changes we're talking about here.

Could you please explain what's the point in having a top-level node?

It's also not clear how it will help fixing the warning messages since
reg property still should be required.

If there is no good point, then let's rename nodes and move on.