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/firmware/fwu-mdata-gpt.yaml > > 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
