scripts: dts: Use DT_ prefix in generated labels

[anangl]

As agreed at ELCE, these are the changes required to proceed further with #10377.

I wasn't sure how to treat some FLASH related labels (like FLASH_WRITE_BLOCK_SIZE) since they are directly referenced from existing code. I decided to leave them in the current form, see the commit message.

[galak]

Going to merge it, and we'll deal with any fixup, etc after.

[mnkp]

This PR has been merged however I would like to add one comment.

What is the rational for adding compat in alias prefix? Won't we loose genericity?

To indicate the purpose of the value that the label defines and this way help preventing misuses of the label (see #10377, we want to use labels generated through aliases in drivers, to avoid creating fixups). [...]
We won't loose genericity. For generic nodes we'll still get generic prefixes, for instance DT_GPIO_LEDS_ for "gpio-leds" compatibles. The only disadvantage I see is that the label name lengthens, but I guess it is an acceptable price.
-- @anangl

According to the Devicetree Specification "The alias node shall be at the root of the devicetree". Which implies that properties defined by the node belong to the global namespace. We probably shouldn't prefix defines generated from the aliases node with 'compatible' property.

[anangl]

According to the Devicetree Specification "The alias node shall be at the root of the devicetree". Which implies that properties defined by the node belong to the global namespace. We probably shouldn't prefix defines generated from the aliases node with 'compatible' property.

But please note that we don't generate labels for the properties of the "aliases" node themselves. These properties (i.e. actual definitions of aliases) provide only alternative (usually shorter) paths to other nodes defined in the Devicetree, and they are used here exactly for this purpose. Therefore, for every node for which an alias is also defined, we generate an extra set of labels with the middle part (normally derived from the path to the node) replaced with the alias name.

If I am not precise enough in my explanation, I hope @galak can correct me or elaborate on this. In one of the comments above he already stated:

We should have the alias replace a very specific part of symbol name we create.

[pabigot]

@anangl If add_prop_aliases in extract/globals.py is modified to prefix DT_ to what's emitted under --old-alias-names I think we'd get something pretty close to what is being requested. Though there might be some multiple-definition issues to catch.

[mnkp]

Therefore, for every node for which an alias is also defined, we generate an extra set of labels with the middle part (normally derived from the path to the node) replaced with the alias name.

From the Devicetree Specification: "Each property of the /aliases node defines an alias. The property name specifies the alias name. The property value specifies the full path to a node in the devicetree". It implies that an alias can replace the full path to the node name.

If we remove 'compatible' from the defines generated for aliases it doesn't stop us from using them in the device drivers and getting rid of the dts_fixup.h files. Every alias refers to a single, distinct hardware module.

Also, the current approach of prefixing defines generated for aliases with 'compatible' property doesn't solve any problem, instead it creates some:

So indeed, I was wondering on non generic nodes, like for instance, if we have:

	aliases {
		zi2c = &i2c1;
	};

So generated #define will use i2c1 compatible field.
Which means we won't be able to use a ZI2C_NAME for testing for instance. And we'll always need fixup to establish generic #define's like
#define CONFIG_I2C_1_NAME ST_STM32_I2C_V2_40005400_LABEL
Or we'll need other approach than alias to establish generic devices bindings
-- @erwango

Yes. It won't be possible to use aliases for this.
how can we solve this? Using chosen maybe?
-- @anangl

[mnkp]

Just one more comment. If, for some reason, we would prefer to use a 'qualified' names in the defines there is a different approach which does not involve misusing aliases node.

According to the specification a DTS node is defined as

[label:] node-name[@unit-address] {
	[properties definitions]
	[child nodes]
}

e.g.

usart0: usart@40010000 { /* USART0 */
		[...]
};

where usart0 is a node label. We could modify the script to generate DT_ defines that use label name rather than a unit address. E.g.

DT_SILABS_GECKO_USART_40010000_BASE_ADDRESS=0x40010000

would become

DT_SILABS_GECKO_USART_USART0_BASE_ADDRESS=0x40010000

As such the resulting defines would rely on logical names and not on part number dependent, fixed addresses. Such defines could be used directly by the device drivers without the need for dts_fixup entries.

[pfalcon]

would become
DT_SILABS_GECKO_USART_USART0_BASE_ADDRESS=0x40010000

@mnkp: You're touching on very important issue, which drills back of my mind for a long time. Suppose I wrote driver_foo.c, how to make it work for board1 with foo@10000000 and board2 with foo@20000000?

So, please continue! I'm happy to give +0.9 for any suitable proposal which addresses that sanely (+0.9 because I don't think U know DT enough to be 100% sure that some solution is the best one).

[mnkp]

Let's continue discussion related to use of aliases, node labels and other issues which goal is to eliminate dts_fixup files to #11737 since this PR has already been merged and lists many participants who are likely not interested in the topic.