On Mon, Sep 16, 2024 at 03:10:52PM +0530, Ayush Singh wrote: > On 9/12/24 09:08, David Gibson wrote: > > > On Mon, Sep 09, 2024 at 12:54:34PM +0530, Ayush Singh wrote: > > > On 9/9/24 10:33, David Gibson wrote: > > > > > > > On Mon, Sep 02, 2024 at 05:47:55PM +0530, Ayush Singh wrote: > > > > > Add ability to resolve symbols pointing to phandles instead of strings. > > > > > > > > > > Combining this with existing fixups infrastructure allows creating > > > > > symbols in overlays that refer to undefined phandles. This is planned to > > > > > be used for addon board chaining [1]. > > > > I don't think this "autodetection" of whether the value is a phandle > > > > or path is a good idea. Yes, it's probably unlikely to get it wrong > > > > in practice, but sloppy cases like this have a habit of coming back to > > > > bite you later on. If you want this, I think you need to design a new > > > > way of encoding the new options. > > > Would something like `__symbols_phandle__` work? > > Preferable to the overloaded values in the original version, certainly. > > I can whip it up if that would be sufficient. But if we are talking about > any big rewrite, well, I would like to get the details for that sorted out > first. Fair enough. > > > It should be fairly > > > straightforward to do. I am not sure how old devicetree compilers will react > > > to it though? > > Well, the devicetree compiler itself never actually looks at the > > overlay encoding stuff. The relevant thing is libfdt's overlay > > application logic... and any other implementations of overlay handling > > that are out there. > > > > At which I should probably emphasize that changes to the overlay > > format aren't really mine to approve or not. It's more or less an > > open standard, although not one with a particularly formal definition. > > Of course, libfdt's implementation - and therefore I - do have a fair > > bit of influence on what's considered the standard. > > So do I need to start a discussion for this somewhere other than the > devicetree-compiler mailing list? Since ZephyrRTOS is also using devicetree, > maybe things need to be discussed with them as well? <devicetree-spec@xxxxxxxxxxxxxxx> and <devicetree@xxxxxxxxxxxxxxx> are the obvious candidate places. There will be substantial overlap with devicetree-compiler of course, but not total probably. > > > I really do not think having a different syntax for phandle symbols would be > > > good since that would mean we will have 2 ways to represent phandles: > > > > > > 1. For __symbols__ > > > > > > 2. For every other node. > > I'm really not sure what you're getting at here. > > I just meant that I would like to keep the syntax the same: > > sym = <&abc>; Ok, the syntax for creating them in dts, rather than the encoding within the dtb. Why are you manually creating symbols? So.. aside from all the rest, I don't really understand why you want to encode the symbols as phandles rather than paths. > > > I also am not in the favor of doing something bespoke that does not play > > > nice with the existing __fixups__ infra since that has already been > > > thoroughly tested, and already creates __fixups__ for symbols. > > Hmm. Honestly, the (runtime) overlay format was pretty a hack that's > > already trying to do rather more than it was really designed for. I'm > > a bit sceptical of any attempt to extend it further without > > redesigning the whole thing with a bit more care and forethought. I > > believe Rob Herring has some thoughts along these lines too. > > Well, if we are really redesigning stuff, does that mean something like > dts-v2, or everything should still be backward compatible? Well.. it depends. There are actually 3 or 4 different layers to consider: 1) The basic data model of the device tree as consumed by the kernel This is layer which "properties are just bytestrings" comes from. There is a case for redesigning this, since it comes from IEEE1275 and shows its age. A modern format would likely be self-describing, so type information would be preserved. A json-derivative would be the obvious choice here, except that json can't safely transport 64-bit integers, which is kind of a fatal flaw for this application. This would be a fundamentally incompatible change for all current consumers of the device tree, though. And when I say consumers, I don't just mean the kernel base platform code, I mean all the individual drivers which actually need the device tree information. I'm not suggesting this layer be changed. 2) The "dtb" format: The linearized encoding of the data model above Changing this is much more tractable. The dtb header includes version numbers, allowing some degree of backwards compatibility. There have been, IIRC, 5 versions in total (v1, v2, v3, v16 & v17), though we've been on v17 for a long time (10+ years) now. There's not a heap you that can be changed here - at least neatly - without requiring an incompatible version bump. However dealing with even an incompatible change at this layer is *much* easier. As long as the base data model remains the same you can mechanically convert between versions, at least as long as you're not actively using new features. In particular it's pretty feasible to have a whole set of tooling using a newer version that as a last step converts a final tree to an old version for consumption by the kernel or whatever. 3) The "dts" format: the human readable / writable format Being parsed text, it's relatively easy to extend this in backwards compatible ways. Note that this is more influenced by (1) than the details of (2). To this day, dtc can input and output the long-obsolete v1 dtb format, and that doesn't add a lot of complexity to it. Any change to the other layers would likely require extensions here as well, but I don't think there would be a need for backwards incompatible changes. Using certain features in the source might impose a minimum dtb output version though. Note that dts isn't in one to one correspondance with either (1) or (2): there are multiple ways of specifying identical output, as there would be in most languages. That is a recurring source of confusion, but I can't see a reasonable way of changing it short of a complete redesign of (1), in which case "dts" would likely simply be obsoleted. 4) The overlay specific encoding Overlays first existed purely as a dts construct: a different way of arranging things in the source that would compile to the same final tree. Runtime overlays (a.k.a. dtbo) came later. This is by far the most poorly designed layer, IMO. Basically when dtbos were invented, it was done as a quick and dirty encoding of the dts level overlay features into the data model of (1), which was then just encoded using (2), thereby blurring the layers a bit. No real thought was given to versioning or backwards compatibility. This is where I think a redesign would make most sense. However, the most sensible (IMO) ways of doing so would also require some redesign to (2). Basically rather than encoding the overlay specific information "in band" as specially named and encoded properties, it would be carried "out of band" as new special tags in the updated dtb format. You can think of this as a bit like relocation information that a C compiler emits alongside the actual instruction stream. > The problem with guessing type can probably be fixed with a tagged union for > the type (so an extra byte for every prop). Yeah, it's not so simple. As things stand this would imply a change to (1), which as noted probably isn't really feasible. Plus, just a one-byte type per property wouldn't cut it: some bindings have complex encoded values in properties that are a mixture of integers and strings and so forth. > > With more and more emphasis on runtime devicetree [0], it would be great to > have a design that allows tackling more complex use cases. > > [0]: https://lpc.events/event/18/contributions/1696/ Oof. I don't think overlays as currently designed are a great choice for hotplug: overlays essentially allow rewriting any part of the whole device tree, which isn't a great model for a hotplug bus. A long time ago some ideas were floated to define "connectors" in the device tree that more specifically described a way things could be plugged in that could cover several busses / interrupt controllers / etc. That would provide a more structured way of describing plug in devices that can actually validate what they can do. Of course, such a scheme is a lot more work to design and implement, which is why the simple hack of overlays have become dominant instead. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
