Merge binding properties from all listed compat string with certain constraints.

[swift-tk]

Problem Description

Zephyr only process the first compat string to get the binding properties for a given node.
Given a DTS like below where two compat string is involved but their properties does not entirely overlap.
The common mspi-aps-z8 would have the device variant/part number property that would never make into ambiq,mspi-device that is platform specific. And ambiq,mspi-device would have ambiq,timing-config and ambiq,timing-config-mask properties that would never make into the common mspi-aps-z8; while both three properties are needed in the device tree.

	aps51216ba: aps_z8@0 {
		compatible = "ambiq,mspi-device", "mspi-aps-z8";
		size = <DT_SIZE_M(512)>;
		reg = <0>;
		status = "disabled";
		variant = "APS51216BA"
		mspi-max-frequency = <125000000>;
		mspi-io-mode = "MSPI_IO_MODE_HEX_8_8_16";
		mspi-data-rate = "MSPI_DATA_RATE_S_D_D";
		mspi-hardware-ce-num = <0>;
		mspi-dqs-enable;
		read-command = <0x20>;
		write-command = <0xA0>;
		command-length = "INSTR_1_BYTE";
		address-length = "ADDR_4_BYTE";
		rx-dummy = <7>;
		tx-dummy = <8>;
		xip-config = <1 0 DT_SIZE_M(64) 0>;
		ce-break-config = <1024 4>;
		ambiq,timing-config-mask = <0x62>;
		ambiq,timing-config = <8 7 1 0 0 3 10>;
		zephyr,pm-device-runtime-auto;
	};

Another example is when the common device(flash) binding have gpio reset related properties that are also inappropriate to appear in a platform specific binding.

Proposed Change (Summary)

Update edtlib.py to support pulling bind properties from all listed compat string given that they are on the same bus.
Or, introduce a base keyword, and merge bindings that have the same base.

Proposed Change (Detailed)

This seems pretty easy, I was able to modify the edtlib.py _init_binding to merge bindings across listed compats. Note that this would merge without constraints.

    def _init_binding(self) -> None:
        # Initializes Node._binding. It holds data from the node's binding file,
        # in the format returned by PyYAML (plain Python lists, dicts, etc.), or
        # None if the node has no binding.

        # This relies on the parent of the node having already been
        # initialized, which is guaranteed by going through the nodes in
        # node_iter() order.

        if self.path in self.edt._infer_binding_for_paths:
            self._binding_from_properties()
            return

        if self.compats:
            on_buses = self.on_buses
            merged_raw = {}
            found_binding = False

            for compat in self.compats:
                # When matching, respect the order of the 'compatible' entries,
                # and for each one first try to match against an explicitly
                # specified bus (if any) and then against any bus. This is so
                # that matching against bindings which do not specify a bus
                # works the same way in Zephyr as it does elsewhere.
                binding = None

                for bus in on_buses:
                    if (compat, bus) in self.edt._compat2binding:
                        binding = self.edt._compat2binding[compat, bus]
                        break

                if not binding and (compat, None) in self.edt._compat2binding:
                    binding = self.edt._compat2binding[compat, None]

                if binding:
                    found_binding = True
                    _merge_props(merged_raw, binding.raw, None, binding.path, False)

            if found_binding:
                self._binding = Binding(None, self.edt._binding_fname2path, raw=merged_raw)
                return
        else:
            # No 'compatible' property. See if the parent binding has
            # a compatible. This can come from one or more levels of
            # nesting with 'child-binding:'.

            binding_from_parent = self._binding_from_parent()
            if binding_from_parent:
                self._binding = binding_from_parent
                return

        # No binding found
        self._binding = None

The constraints may need further discussion. Some I come up:

1. Merge only compat on the same bus
2. When conflict, use binding in the most specific compat.
3. ...

Dependencies

No response

Concerns and Unresolved Questions

No response

Alternatives Considered

alternative is to have DT support addtionalProperties feature seen in Linux/dt-schema.

[decsny]

-1 ❌

DT compatible is supposed to describe what device programming model a device has, from most specific to least specific. Utility bindings are antithesis to the DT paradigm of matching compatible drivers to devices. This also would make DT even more unclear and confusing to people than it already is. Not to mention the extra maintenance effort for DT in order to handle all the new edge cases and complication caused by these abilities to "merge" bindings and getting fingers pointed about who is supposed to be handling conflicts in the definitions of the bindings between one another. Utility bindings also seem like they are just a way to encourage more SW configuration in DT, when, for example with what your case is, there's no reason why you can't code that behavior into your source code at the board level, so I don't see why this is even needed.

[swift-tk]

-1 ❌

DT compatible is supposed to describe what device programming model a device has, from most specific to least specific. Utility bindings are antithesis to the DT paradigm of matching compatible drivers to devices. This also would make DT even more unclear and confusing to people than it already is. Not to mention the extra maintenance effort for DT in order to handle all the new edge cases and complication caused by these abilities to "merge" bindings and getting fingers pointed about who is supposed to be handling conflicts in the definitions of the bindings between one another. Utility bindings also seem like they are just a way to encourage more SW configuration in DT, when, for example with what your case is, there's no reason why you can't code that behavior into your source code at the board level, so I don't see why this is even needed.

First of all, it is not a utility compatiable, the timing setting is a hardware setting and is required for MSPI to run at high speed. I think this is also true for other platforms and the timing parameters are all somewhat different.
I'm not saying we should merge all the compat without constraints. For complications you mentioned, please elaborate.
IOM, if we set the constriants carefully, there would not be any problem at all.

[decsny]

-1 ❌
DT compatible is supposed to describe what device programming model a device has, from most specific to least specific. Utility bindings are antithesis to the DT paradigm of matching compatible drivers to devices. This also would make DT even more unclear and confusing to people than it already is. Not to mention the extra maintenance effort for DT in order to handle all the new edge cases and complication caused by these abilities to "merge" bindings and getting fingers pointed about who is supposed to be handling conflicts in the definitions of the bindings between one another. Utility bindings also seem like they are just a way to encourage more SW configuration in DT, when, for example with what your case is, there's no reason why you can't code that behavior into your source code at the board level, so I don't see why this is even needed.

First of all, it is not a utility compatiable, the timing setting is a hardware setting and is required for MSPI to run at high speed. I think this is also true for other platforms and the timing parameters are all somewhat different. I'm not saying we should merge all the compat without constraints. For complications you mentioned, please elaborate. IOM, if we set the constriants carefully, there would not be any problem at all.

When I say utility compatible, I'm referring to the fact that the compatible string does not match to a driver which can appreciate a full and valid programming model for the device. This compatible in the example you're giving not only doesn't represent a full programming model for the device being described by the node, but it doesn't even describe part of one at all. It describes a piece of a specific usage (not a programming model) of a different device (the spi controller), so it doesn't make sense to exist as a compatible, it's not valid DT usage.

As for complications and unexpected situations, they always happen in programming. I think pretending like I would be able to explain to you all of the possible issues that will arise is either naive or dishonest. Any time you add a feature you expose yourself to the possibility of more bugs and edge cases and wrong or missing assumptions. So since this feature you're proposing to add is against one of the core design philosophies of DT, I don't want to add it to take on this maintenance burden and the inevitable new set of ongoing issues popping up around it.

[57300]

To be fair, there is a precedent for allowing devicetree properties to be mixed in from multiple bindings in dt-schema; see additionalProperties: true.

I had considered implementing something like this years ago, because as different kinds of bindings co-mingle - generic, vendor-specific, OS-specific - they can't always be arranged in a linear pattern of inclusion (most to least specific description of the device). My own motivating example was zephyr,memory-region, which is not really hardware description, but it's often used together with mmio-sram and could be paired with other memory compatibles.

I'm not too invested in this at the moment, but wanted to give my two cents.

[decsny]

To be fair, there is a precedent for allowing devicetree properties to be mixed in from multiple bindings in dt-schema; see additionalProperties: true.

I had considered implementing something like this years ago, because as different kinds of bindings co-mingle - generic, vendor-specific, OS-specific - they can't always be arranged in a linear pattern of inclusion (most to least specific description of the device). My own motivating example was zephyr,memory-region, which is not really hardware description, but it's often used together with mmio-sram and could be paired with other memory compatibles.

I'm not too invested in this at the moment, but wanted to give my two cents.

AFAIK @mbolivar was already taking on some work to just straight up introduce dt-schema to zephyr, not sure what's the status of that anymore though.

I actually would be fine with having some analogue to additionalProperties, but I'm still a bit leery/concerned might introduce problems with all the weird inheritance based bindings rules that we have for zephyr, which have already been a headache as it is. @dottspina and @rruuaanng have been much more involved on the script maintenance than me lately, so maybe they have an opinion about that.