On 5/4/23 17:19, Rob Herring wrote:
On Thu, May 4, 2023 at 9:01 AM Jassi Brar jaswinder.singh@linaro.org wrote:
On Thu, 4 May 2023 at 07:08, Ilias Apalodimas ilias.apalodimas@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/optio...
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