[PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU

[Krzysztof Kozlowski]

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