devicetree bindings path misinterpreted

[pabigot]

The Cmake/environment variable DTS_ROOT_BINDINGS provides a list of places that are searched for bindings files, which defaults to include dts/bindings found in APPLICATION_SOURCE_DIR,
BOARD_DIR, and ZEPHYR_BASE in that order. The expectation is that a binding for a specific compatible will be selected from the first location where it is found.

It appears that the current tooling picks the binding in the last directory searched. This is contrary to expected behavior.

[ulfalizer]

I thought having multiple bindings provide the same compatible was an error, until I remembered that that check is only done for filenames in include:.

Is this something you'd use, or just something you noticed?

[pabigot]

It is something that I have thought I might use: for example to change defaults, or add new properties for a custom driver that needs them.

It becomes more clearly useful if we start following Linux and specifying multiple compatibles in the binding because a driver supports multiple compatibles. There I may want to substitute a driver for one, but not all, of the listed compatibles, and provide additional functionality in that driver that requires more information about the device.

So I think multiple bindings with the same compatible might be useful., but I admit the cases above are theoretical at this time.

There are two acceptable solutions in my view:

• Do the "expected" and associate the compatible with the first binding file found, ignoring associations in any subsequently found file. (Because compatibles are not associated with file names, reproducibility requires that files in a directory be processed in a well-defined order.)
• Do the "helpful" and error out if a second binding is later found to have the same compatible

What's really not acceptable is discarding the locally provided binding in favor of a generic one and not saying anything about it. So "something must be done".

It should probably be the same for include (which might be used to inject a change to multiple bindings, in which case include_next would be nice to have alongside it). Based on existing behavior "make it an error" is probably the simplest path at this time.

[ulfalizer]

PR to turn it into an error: #19806