devicetree: add binding support for variant compatibles

[pabigot]

This is a step towards #19904. The motivation is removing redundant bindings from dts/ that aren't associated with their own driver implementation, and eliminating the annoying checkpatch warnings when an unspecified compatible is added in a commit.

Knowledge of the variants may also assist in addressing #20287.

[zephyrbot]

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[ulfalizer]

Should check the format of variant-compatible too. Search for all(isinstance in edtlib.py for examples of how it's done for other keys.

[ulfalizer]

If we go with this, this ought to explain that variant-compatible isn't used by the code, and is just a "syntaxified comment" in a sense. Otherwise, I'd wonder how it's used.

Think I'm fine with it as long as that's clear. Might help bring some structure.

[ulfalizer]

(Could update the comment later if/when it gets used for other stuff. As long as it's unused, it's nice to document it, to avoid confusion.)

[ulfalizer]

Could reflow all of ok_top, or put on separate lines if you're worried about history (though I wonder if the vertical spam is worthwhile).

[ulfalizer]

Should verify that it's a list as well, or it'll pass for variant-compatible: "foo" by iterating over "f", "o", "o".

[ulfalizer]

Could maybe put it outside the loop. Think some other stuff was:

if "variant-compatible" in binding:
    var_comp = binding["variant_compatible"]
    if not (isinstance(var_comp, list) and
            all(isinstance(elm, str) for elm in var_comp)):
        _err("... should be a list of strings")

[ulfalizer]

Could put it next to the

if "child-binding" in binding:
    ....

if "sub-node" in binding:
    ...

if "#cells" in binding:
    ...

stuff below.

[avisconti]

What is the reason to invert the devices in the compatible list?

[pabigot]

Because standard practice is to order them from most-specific to least-specific, selecting the first one that is supported. There is no lsm303agr-magn driver right now, but there is a lis2mdl that works with that device.

Historically Zephyr only paid attention to the first entry, but that was fixed some months ago so we can now be consistent with other devicetree usage.

binding-template specifies the order, but does not explain why it's that way.

[pabigot]

@avisconti please revisit this; note @galak's non-verbal support for this change.

[avisconti]

and here

[avisconti]

also here

[ulfalizer]

Fine with me.

[ulfalizer]

Nit: Accidental two spaces between "expected" and "list".

[ulfalizer]

Fine with me.

[ulfalizer]

Fine with me.

[ulfalizer]

Fine with me.

[ulfalizer]

Fine with me.

[ulfalizer]

Heh... GitHub bugged out for a moment there.

[ulfalizer]

Heh... GitHub bugged out for a moment there.

[ulfalizer]

Heh... GitHub bugged out for a moment there.

[pabigot]

This PR is too out of data and there seems to be little interest in the cleanup it provides.