scripts: edt: Add support for include property filtering

[galak]

Add the ability to filter which properties get imported when we do an
include. We add a new YAML form for this:

include:

• name: other.yaml
  property-blocklist:
  • prop-to-block

or

include:

• name: other.yaml
  property-allowlist:
  • prop-to-allow

Signed-off-by: Kumar Gala [email protected]

TODO:

• implement more tests
• update dts/binding-template.yaml

[galak]

This implements the ideas from PR #29306

[mbolivar-nordic]

Looks good, just a couple minor questions.

[erwango]

I'm fine with this approach

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[gmarull]

LGTM, should allow using enums on stm32 pinctrl slew-rate property.

[mbolivar-nordic]

I've finished the TODO list on this PR. I reworked the tests since I think we can make sure this works at the edtlib.Binding level without having to touch DTS at all.

I also changed this slightly so that you can intermix strings and maps in a single include: list, as I think that's a bit nicer.

Please take another look. I'm going to +1 this even though that's kind of cheating.

[pabigot]

I don't think the description is sufficiently clear on whether map elements can have both or neither of the lists.

Also "allowlist" vs "blocklist" doesn't seem a natural pairing. The coding guidelines sanction "allowlist/denylist" or "blocklist/passlist" or "rejectlist/acceptlist". Pick one.

[mbolivar-nordic]

Also "allowlist" vs "blocklist" doesn't seem a natural pairing. The coding guidelines sanction "allowlist/denylist" or "blocklist/passlist" or "rejectlist/acceptlist". Pick one.

Then the coding guidelines should be fixed. West uses these already and so does Chrome: https://9to5google.com/2020/06/12/google-android-chrome-blacklist-blocklist-more-inclusive/

They're in widespread use; just google them.

I'm not going to change these names.

wording fixed, still don't like the naming deviation. Zephyr doesn't use blocklist.

[mbolivar-nordic]

Zephyr doesn't use blocklist.

I was present at all of the inclusive language meetings and I do not recall this ever being discussed at any of them, despite the fact that I mentioned that west was changing from whitelist/blacklist and had already chosen terms.

I don't recall having my input requested in the coding guidelines PR you're referring to either. (I'm actually not sure what you're referring to.)

You're saying "Zephyr" but I disagree with whoever in the community ruled this out, and the fact that west is already using these terms de facto means they're going to be used by Zephyr users. So I stand firm on keeping them.

[mbolivar-nordic]

Then the coding guidelines should be fixed.

Done here: #33228

[mbolivar-nordic]

@galak this can be merged now that the coding guidelines have been fixed to allow this terminology.

[galak]

Hmm, do we need some means to block/allow child binding properties?

Was trying to do:

diff --git a/dts/bindings/pinctrl/st,stm32-pinctrl.yaml b/dts/bindings/pinctrl/st,stm32-pinctrl.yaml
index 2178cc80a0..874a3a3ad3 100644
--- a/dts/bindings/pinctrl/st,stm32-pinctrl.yaml
+++ b/dts/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -5,7 +5,11 @@ description: STM32 Pin controller Node
 
 compatible: "st,stm32-pinctrl"
 
-include: [base.yaml]
+include:
+  - name: base.yaml
+  - name: pincfg-node.yaml
+    property-blocklist:
+      - slew-rate

and get:

-- Found BOARD.dts: /home/galak/git/zephyr/boards/arm/disco_l475_iot1/disco_l475_iot1.dts
devicetree error: /home/galak/git/zephyr/dts/bindings/pinctrl/st,stm32-pinctrl.yaml (in 'slew-rate'): 'type' from included file overwritten ('int' replaced with 'string')

[gmarull]

@galak good catch, it's actually one of the usecases...

[mbolivar-nordic]

Hmm, do we need some means to block/allow child binding properties?

We will need some way to say what level of child binding you are doing the filtering in.

I suggest this syntax:

include:
  - name: pincfg-node.yaml
    child-binding:
      property-allowlist: [foo]

With the ability to nest it like this to get at the grandchild, etc:

include:
  - name: foo.yaml
    child-binding:
      child-binding:
        property-allowlist: [foo]

And similarly for property-blocklist.

Thoughts? I can see if that's feasible if it looks OK.

[galak]

looks reasonable to me.

[galak]

Marked DNM til we implement the child-binding support.

[mbolivar-nordic]

Marked DNM til we implement the child-binding support.

now implemented