On Thu, Jan 10, 2019 at 12:15:05PM +0000, Grant Likely wrote: > > > > On 9 Jan 2019, at 18:37, Kumar Gala <kumar.gala@xxxxxxxxxx> wrote: > > > > There are a number of cases I’ve come across when we want to manipulate an array property in DTS. Most cases I’ve see today end up replacing the whole property because we don’t have any means/syntax to manipulate the array. > > > > I was hoping to see if, one there is interest in adding support to manipulate array’s to dtc, and defining what features and syntax would be. Duh, sorry. I realized by earlier reply missed the point. I thought you were talking about manipulating properties from libfdt, rather than during compile with dtc. > Off the top of my head, the syntax should stay away from arithmetic > style operators (Ie. prop += <new data>; prop = <new> + $oldval;) > since we do arithmetic calculations for prop values, and the > existing syntax already is a concatenation of multiple datum. Yes. So, for some time I've had in mind the idea of string expressions and bytestring expressions to augment the integer expressions we already have in dtc. That seem to line up with what you're suggesting below. "," obviously would be the bytestring append operator. One major thing I got stuck on was what to make the string append operator (which would discard the \0 from the first argument, unlike bytestring append). "Be like C" says use nothing at all, but I suspect that'll cause parser confusion. "+" potentially conflicts with integers, and "." matches Perl but precious little else. > I think we first need a representation for existing data that is > distinct from <>, “”, [], and &. Maybe using a ‘@‘ and using some > python array syntax? Fwiw, I'm a little nervous about introducing Python-y syntax into dtc. "Be like C where possible" has steered us well for syntax that doesn't confuse in the past, and Python has a *very* different syntax feel. > @@ current prop val So a special expression for previous property value is certainly necessary. It's a bit awkward to implement though - at the point we're parsing the value expression we won't actually know what property it's going to end up in, which means we'll need some intermediate representation. Suggestions on how to do that welcome. Oh.. '@' won't work, though, because it's an allowed character in property names. > @prop another prop val > @/path/prop prop in another node Please don't use /path/to/prop syntax - it's not used anywhere in OF and technically nodes and properties occupy different namespaces. There are even (old Apple) device trees in the wild which have a property and subnode of the same name. > @@[0] Element 0 of current prop. (Need to define if element is a > byte or a tuple/string. The later makes more logical sense, but we > don’t have that info in dtb) I think trying to define "element" in reference to properties is going to be unavoidably confusing. Properties are bytestrings - they can and do include array data mixed with strings or other data, so even if we did annotate the data size of <> used to generate it, there might not be a clear meaning. > @prop[2] element 2 of another prop > @@[3][6] byte 6 of element 3? > @@[4:7] elements 4 though 7 > @@[:3] elements 0 through 3 > @@[5:] elements 5 to the end I do reasonably like the idea of using Python slice syntax to reference sub(byte)strings though. Using the notion of slice allows a fairly natural way of doing a "splice" - that is replacing a chunk of the original bytestring with a new bytestring (possibly of different length). "Splice" lets us do pretty much anything, although we probably want syntactic sugar to make common cases less verbose. > The @ might be unnecessary except for current prop values. Merely > using a word may be enough to indicate that it is a prop > reference. I’ll try this out with the below examples: > > > > > Figured I’d start with some use examples I know of: > > > > - Updating compatible when we have a base SoC .dtsi file shared across a family of SoC’s. Than a more specific SoC .dtsi file wanting to append a more specific compatible. > > * Add an entry at tail of array > > prop = @@, <newdata>; > > > * Add an entry at head of array > > prop = <newdata>, @@; Yes, I think that's good, modulo the difficulties with '@@'. > > > > > - QSPI nodes where the reg’s are to both the controller and mmap QSPI region, the board dts might want to manipulate the size element > > * Modify a cell of a specific index > > prop[5][1]= newvalue; So I think trying to separate elements and bytes in this way will be very confusing, but the idea of replacing a slice reference with a different bytestring sounds good to me. > > - SPI controller, having an overlay .dtsi that wants to update a cs-gpio entry > > * Replace an entry at a specific index > > prop[3] = <newvalue>; > > > > > Will let other’s hopefully chime in with other use cases examples they’ve seen. I’m guessing there are probably cases for deleting a specific index, > > prop = @@[:3] @@[5:]; > > > deleting head > > prop = @@[1:]; Yes, like those as well, once we find a different solution for @@. > > or deleting tail. > > prop = @@[:-1]; > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- David Gibson | 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
