04.10.2021 23:56, Thierry Reding пишет: >> From: David Heidelberg <david@xxxxxxx> >> >> 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@xxxxxxx> >> --- >> 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.
