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(). 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.
cheers.