Closed ulfalizer closed 5 years ago
CC @pabigot @galak
I have always maintained that Zephyr misuses the label
property, but I was told by @galak this was to be fixed when tooling was complete. Are we there yet?
All we really need is some handle that can be used in device_get_binding(DT_HANDLE_PATH)
to get the device associated with PATH
in the devicetree. Nobody should ever need to see the value of that handle outside of debugging.
Ideally it wouldn't be a string (a unique integer assigned when the binding set was generated would be adequate), but I don't expect that to change. Whatever it is, there's no reason the devicetree scripting can't synthesize a unique label when one is required but missing.
The scripting should be checking that label
is unique across all nodes for which there are devices anyway, so it could synthesize a short unique string, or simply represent the path to the node (wasting ROM).
In any case, requiring that device tree nodes provide a user-supplied label
property because we have no other way to identify the node is, in my opinion, bad design.
I've recently been making properties optional
when I can have the driver implementation provide a reasonable default, and required
when the driver must be given a value. For jedec,spi-nor
the size
, erase-block-size
, and write-block-size
properties are required, but cannot be defaulted in the driver.
I think the devicetree tooling interferes in the case of flash-type devices because it synthesizes size-related properties from partition table data even if they don't appear explicitly. (I'm not sure about this.)
It is unclear to me whether category presence checks are before or after this synthesis.
Extending this existing practice to label
, SPI (and other) devices must have a label
so we can get their driver, but the tooling can synthesize one. So a proposal:
<compatible>#<instance>
. E.g. jedec,spi-nor#0
.If category presence is checked before synthesis, then just change spi-base.yaml
to make label
optional.
If that isn't viable then:
label = "jedec,spi-nor#0";
to all the nodes that require it.@pabigot Which quickfix do you prefer, and could you submit a PR for it?
Doesn't need to be high art at this point. Could add a comment explaining what's going on maybe. Trying to batch-fix all of those required-but-missing properties to be able to plug it for good.
Could improve the design later.
dts/bindings/mtd/jedec,spi-nor.yaml
includesdts/bindings/spi/spi-device.yaml
, which says that any node with that binding must have alabel
property, but none of the nodes withcompatible = "jedec,spi-nor"
has alabel
property.List for reference:
This leads to failures in https://github.com/zephyrproject-rtos/zephyr/pull/17660, which turns missing
category: required
properties into an error.I wonder if some dummy label string could be put in, even if it isn't used.