On 5/4/23 17:19, Rob Herring wrote:
On Thu, May 4, 2023 at 9:01 AM Jassi Brar <[email protected]> wrote:
On Thu, 4 May 2023 at 07:08, Ilias Apalodimas
<[email protected]> 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
