zephyr/scripts/dts/test-bindings/false-positive.yaml

# A file that mentions a 'compatible' string without actually implementing it.
# Used to check for issues with how we optimize binding loading.

# props
dts: edtlib: Improve how we get the compatible string from bindings Use Galak's idea from https://github.com/zephyrproject-rtos/zephyr/pull/18313 to read the 'properties: compatible: constraint: "foo"' string from bindings in a more robust way. First, check if any of the compatible strings are in the file (needed as an optimization). If any of them are, do a more careful check for the 'properties: compatible: constraint: ...' value matching a compatible, to filter out false positives from comments and the like. This commit a no-op in itself besides making things a bit more robust, but it'll make later work easier (supporting multiple compatibles for a binding, in a dt-schema-like way). Co-authored-by: Kumar Gala <kumar.gala@linaro.org> Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no> 2019-08-16 20:43:58 +08:00			`# A file that mentions a 'compatible' string without actually implementing it.`
			`# Used to check for issues with how we optimize binding loading.`

scripts: dts: Generalize handling of phandle-array types Generating generic information for 'type: phandle-array' properties in edtlib was difficult due to defining phandle-array as just a list of phandles and numbers. To make sense of a phandle-array property like 'pwms', you have to know that #pwm-cells is expected to appear on each referenced controller, and that the binding for the controller has a #cells. Because of this, handling of various 'type: phandle-array' properties was previously hardcoded in edtlib and exposed through properties like Node.pwms, instead of through the generic Node.props (though with a lot of shared code). In practice, it turns out that all 'type: phandle-array' properties in Zephyr work exactly the same way: They all have names that end in -s, the 's' is removed to derive the name of related properties, and they all look up #cells in the binding for the controller, which gives names to the data values. Strengthen the definition of 'type: phandle-array' to mean a property that works exactly like the existing phandle-array properties (which also means requiring that the name ends in -s). This removes a ton of hardcoding from edtlib and allows new 'type: phandle-array' properties to be added without making any code changes. If we ever need a property type that's a list of phandles and numbers but that doesn't follow this scheme, then we could add a separate type for it. We should check if the standard scheme is fine first though. The only property type for which no information is generated is now 'compound'. There's some inconsistency in how we generate identifiers for clocks compared to other 'type: phandle-array' properties, so keep special-casing them for now in gen_defines.py (see the comment in write_clocks()). This change also enabled a bunch of other simplifications, like reusing the ControllerAndData class for interrupts. Piggyback generalization of *-map properties so that they work for any phandle-array properties. It's now possible to have things like 'io-channel-map', if you need to. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no> 2019-09-23 15:10:22 +08:00			`# props`