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

Michal Simek michal.simek at amd.com
Fri May 5 10:38:16 CEST 2023



On 5/4/23 17:19, Rob Herring wrote:
> On Thu, May 4, 2023 at 9:01 AM Jassi Brar <jaswinder.singh at linaro.org> wrote:
>>
>> On Thu, 4 May 2023 at 07:08, Ilias Apalodimas
>> <ilias.apalodimas at linaro.org> wrote:
>>> [...]
>>>
>>>>>> I'm assuming it's per partition type rather than storage medium (e.g.
>>>>>> SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT
>>>>>> partition bindings, etc. If so, then I'm really wondering why it's a
>>>>>> standalone tree rather than integrated into those existing partition
>>>>>> bindings.
>>>>>
>>>>> I think it's per medium, unless I misunderstood something.  Sughosh?
>>>>
>>>> The bindings would be required as per the metadata access mechanism.
>>>> So for example, the MTD bindings would suffice for all the storage
>>>> mediums which would have MTD based partitioning schemes. Same for all
>>>> GPT partitioned devices. Again, as for the need for a separate node
>>>> with the compatible property, it is as per the driver model design.
>>>> For the other properties, we can indeed have them integrated with the
>>>> corresponding partition bindings.
>>>
>>> Ok, Rob is correct then it really is per partition type.
>>>
>> Originally the fwu related properties were embedded into existing nodes.
>>
>> As Sughosh already explained, we need a compatible string, and hence a
>> node, for the u-boot driver core to call probe().
> 
> DT's purpose is not OS driver instantiation. DT cannot cater to a
> client's evolving driver structure.
> 
>>   I may be wrong, but I see having fwu properties contained within the
>> fwu node is cleaner than having them embedded into existing bindings
>> (potentially different classes in future). So I moved to the current
>> design.
> 
> Having all the information related to a device/node in one place is cleaner IMO.
> 
> As I said, if u-boot wants private interfaces between the DT and
> itself, then fine, but that should remain private and be stripped by
> u-boot. A separate node would certainly be easier for doing that.

In dt-schema
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml#L14

description: |
   The u-boot,config node provides basic configuration information to U-Boot,
   for use during its execution. It can be used to control U-Boot's behaviour
   in various ways.

We are preparing patch to add some more properties for u-boot itself.
I thought that Simon already solved what should be location for U-Boot only 
binding by creating this file.

Thanks,
Michal


More information about the U-Boot mailing list