On Thu, May 4, 2023 at 9:01 AM Jassi Brar <jaswinder.si...@linaro.org> wrote: > > On Thu, 4 May 2023 at 07:08, Ilias Apalodimas > <ilias.apalodi...@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. Rob
