Clarifications on non-indirect-bus reference nodes in address-map

[mbolivar-nordic]

I could use some general clarification on what happens if a device
node is directly mapped into an address-map property, but it's the
child of one or more nodes which are not visible to the
corresponding CPU cluster.

Abstractly, the idea that "the node is visible but its parents aren't"
doesn't quite make sense to me from the perspective of how to generate
an equivalent standard devicetree.

For example:

/ {
	cpu0: cpu0-cluster {
		compatible = "cpus,cluster";
		#address-cells = <1>;
		#size-cells = <0>;
		#ranges-address-cells = <1>;
		#ranges-size-cells = <1>;

		/* Non-secure address map. */
		address-map = <0 &peripheral 0 0x1000>;

		/* ... */
	};

	bus {
		compatible = "indirect-bus";
		intermediate-node@... {
			peripheral: peripheral@... {
				reg = <... 0x1000>;
			};
		};
	}
};

It's not clear to me how to generate a standard devicetree for this
that both preserves the structure of the original system devicetree
and respects visibility within an address map.

Can we introduce some sensible restrictions on non-bus nodes in
address-map properties to avoid ambiguity here?

For example, one rule which would clear it up for me would be "such
nodes must be children of the root node". Then there's no problem with
intermediate nodes, and address translation through the root node's
#address-cells and #size-cells properties seems trivial, since the
peripheral is already directly underneath the root.

I was thinking perhaps we need some sort of rule along these lines:

• you have to have explicit address translation via ranges
  properties as needed all the way from the root to the node you are
  mapping in via address-map

• all the nodes along the path from root to the peripheral
  have to be mapped into the address-map too

But that seems to break other simple cases, like mapping in a SPI or
I2C slave:

/ {
	bus {
		compatible = "indirect-bus";
		spi@deadbeef {
			cs-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
			sensor@0 { /* ... */ };
		};
	}
};

Here it seems clear that we want sensor@0 mapped into the CPU
cluster if we map in bus, so there must be some sort of transitive
inclusion of child nodes when you map in parent nodes, at least for
indirect-bus nodes.

[sstabellini]

The underlying issue is that today in device tree it is often the case that the bus node doesn't really represent faithfully the connections in the SoC. So it is possible and valid in system device tree:

/ {
cpu0: cpu0-cluster {
compatible = "cpus,cluster";
#address-cells = <1>;
#size-cells = <0>;
#ranges-address-cells = <1>;
#ranges-size-cells = <1>;

	/* Non-secure address map. */
	address-map = <0 &peripheral 0 0x1000>;

	/* ... */
};

bus {
	compatible = "indirect-bus";
	intermediate-node@... {
		peripheral: peripheral@... {
			reg = <... 0x1000>;
		};
	};
}

};

One could say that it doesn't make sense for peripheral to be visible when bus is not. The reality is that there are multiple different buses on an SoC and they are not described in Device Tree. We probably don't want them to be described in Device Tree either because it would add too much complexity and too many unneeded details.

In this example what really happens is that there are multiple connections from clusters to peripherals and one of them is available while others are not. Would we want all the possible hardware connections to be described? Because that would solve the problem but it would make the DT 2x or 3x bigger and more complex and less readable.

I would keep the specification as is.

[mbolivar-nordic]

I would keep the specification as is.

I'm still having trouble with this part of the issue description:

doesn't quite make sense to me from the perspective of how to generate an equivalent standard devicetree.

What would you propose as the "equivalent" standard devicetree for this example?

[sstabellini]

This is the equivalent standard device tree:

bus {
	compatible = "simple-bus";
	intermediate-node@... {
		peripheral: peripheral@... {
			reg = <... 0x1000>;
		};
	};
            [all other nodes originally under "bus" removed]
}

[mbolivar-nordic]

This is the equivalent standard device tree:

I'm trying to generalize this into a rule that I can add to the specification. It seems like the rule is that if you map in a node via address-map, then that node and all of its parents are visible to the CPU cluster. But how to specify the desired address translation of the parents? Do the parent nodes of peripheral "inherit" the same address-map entry values from here?

	address-map = <0 &peripheral 0 0x1000>;

I couldn't think of any other possibilities that made sense.

[sstabellini]

Device Tree already specifies how a parent translates the address of a child node for the benefit of a grandfather node. So if we say that a peripheral is mapped, it means that the hierarchy is visible with the translation as it is.

To make it more concrete:

bus {
    /* ranges performs address translation */
    ranges = <>;
    child@address {
         reg = <>;
    };
};

When address-map maps a child node elsewhere, bus is also visible because "ranges" is required for the child node address to make sense. It doesn't mean that the other nodes under bus are visible, but "bus" and its "ranges" property at a minimum must be visible.

There is no need to specify the address translation of the parent because the purpose of the parent node is just to translate the child address for the grandfather node.