On Fri, Aug 02, 2024 at 03:36:43PM +0000, Hoover, Erich (Orion) wrote: > I saw this old thread on array manipulation: > https://www.spinics.net/lists/devicetree-compiler/msg02575.html > and was wondering if anything got implemented to handle arrays and I'm just not finding it. > > For most cases I've encountered there are workarounds for dealing with the arrays, but I'd like to figure out a way to update GPIO line names from an overlay. Example: > > &gpio { > gpio-line-names = > "QSPI_CLK", /* GPIO0 (example, not always the same) */ > "QSPI_DQ1", /* GPIO1 (example, not always the same) */ > "QSPI_DQ2", /* GPIO2 (example, not always the same) */ > "QSPI_DQ3", /* GPIO3 (example, not always the same) */ > "QSPI_DQ0", /* GPIO4 (example, not always the same) */ > "QSPI_CS_B", /* GPIO5 (example, not always the same) */ > /* ... */ > "GPIO_MUX_SEL0", /* GPIO148 (thing to add) */ > "GPIO_MUX_SEL1", /* GPIO149 (thing to add) */ > /* ... */ > }; > }; > > What I'm looking at is that I have several layers of device tree information: > 1) shared-based-device.dtb > 2) fpga-overlay.dtbo (different for every device) > 3) config-specific-overlay.dtbo > > When all of this information is integrated into a single tree I can use #defines to set names for all the pins and then write out the pin information all at once (though this is a little painful, since it requires a #define for each pin). However, when this information is in an overlay I need to know what the current contents are to replace things properly. So, what I would _like_ to be able to do is something like this: > > &gpio { > gpio-line-names[148] = "GPIO_MUX_SEL0"; > gpio-line-names[149] = "GPIO_MUX_SEL1"; > }; > > Then when the overlay is applied what I would expect to happen would > be for libfdt to read the existing value, find and replace the > specified indices, and then set the full property with the new > value. Is this totally crazy? Is there already a better way to do > this? Well, it's not crazy to want, but it's basically infeasible to implement (within something resembling the current formats). The heart of the problem is that "arrays" aren't actually a thing in the dtb format: each property is simply a bytestring. You can structure things as lists in the dts for convenience, but it's all just flattened into a bytestring in the output - the user of the dtb has to know the expected format (specified in the binding) in order to decipher it again. For example: foo = "a", b"; foo = "a\0b"; foo = [61006200]; foo = <0x61006200>; Will all produce byte-for-byte identical output in the dtb. In the case of an "array" of strings it's even worse: all the strings (each with a terminating \0) are just appended together to form the property bytestring, so the "entries" aren't of consistent length, you have to scan the whole thing to find an entry of a given number. dtb overlays are kind of a hack layered on top of dtb, and don't have a way to represent things at a granularity less than a whole property (except for special handling of phandles). Introducing new syntax to dts always requires care to not break compatibility, but that's really the least of the problems here. To implement this you'd need to invent a way of encoding partial property updates into dtb, which would be an incompatible extension. It would need to cover ways of describing the part of the property to be replaced more complex than fixed byte offsets to handle the string list case here. Finally you'd need to update libfdt (and any other overlay implementation out there) to process this new fixup information. So, yeah, it's not going to happen. However. If you're able to have an actual program on the target processing things, rather than just applying an overlay, then there are more options. You can then do whatever logic you need in your program, using libfdt to read update the dtb. I'm open to adding additional helper functions if they're useful for things here. Aside: you could argue that using a huge list of strings like this is a poor design choice in the gpio binding, instead of, say, having each gpio line as a different subnode using 'reg' to index them explicitly. But, spec design tradeoffs are always tricky, and we're pretty much stuck with it now, anyway. -- 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
