On 03/05/2023 18:26, Tom Rini wrote:
I think we do not review U-Boot bindings usually, except these put in the Linux kernel. There were few targeting U-Boot specifically (e.g. Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want our blessing, the bindings should be done in Linux kernel repo.
I am pretty sure that reviewing other project bindings would be too much of work for me.
Sure that makes sense. But an answer here of whether the bindings make sense to the DT maintainers or not would help to move forward.
I am not a DT maintainer of other systems, components etc. Answering anything for these other systems and components means nothing. I will take no responsibility of whatever I say because I will bear no costs of it. :) IOW, to me you can make any invalid binding inside U-Boot and it will not matter for the Linux kernel. It will of course matter to U-Boot in many aspects.
These bindings are trying to define a standardized interface for A/B *firmware* updates [0] which is not what traditionally goes into a device tree. OTOH we already have some U-Boot specific bindings as you already mentioned. As we move forward we need to be very precise on what is allowed or not on the DT since it's now tested and verified on SystemReady certifications. IOW if we add those binding in U-Boot only, we would need to strip them before handing the DT to linux, otherwise certification would fail.
Which you can.
Or propose to add the bindings to the Linux kernel and to the Linux kernel DTS, which then will get our review.
If you do think that having them in the kernel repo makes sense, it would help standardizing other boot loaders (at least it would standardize where that metadata lives) if they want to implement something similar.
I cannot speak for Rob, but that's the only way I can make a review. I cannot review or try to maintain all possible projects in the world and their bindings. How would this even work in practice?
Just keep in mind we would need a schema per storage medium. IOW this tries to standardize devices which keep the firmware binary in an mtd. There's also another biding which describes firmware files on a GPT [1].
[0] https://developer.arm.com/documentation/den0118/a [1] https://source.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/...
This is one of the bindings that we need to upstream to https://github.com/devicetree-org/dt-schema/
Sure, this works as well.
Best regards, Krzysztof