On Tue, Oct 30, 2018 at 03:32:05PM -0700, Frank Rowand wrote: > On 10/30/18 11:54 AM, Rob Herring wrote: > > I found (via schema checks!) a couple of errors with stdout-path values: > > > > arch/arm/boot/dts/imx53-ppd.dts: stdout-path = "&uart1:115200n8"; > > arch/arm/boot/dts/vf610m4-colibri.dts: stdout-path = "&uart2"; > > > > Since they are quoted, there is no resolving the label ref to a path > > string. The second case is easily fixed by dropping the quotes. The > > first case is not other than switching to an alias. So should it be > > supported in some form? Perhaps a syntax like this: > > > > stdout-path = &uart1 ":115200n8"; > > > > If that's supported, then should this be: > > > > stdout-path = "/a/path/to/a/node" ":115200n8"; > > > > The downside to allowing this is a missing comma between 2 strings > > would no longer fail. > > > > Thoughts? > > > > Rob > > A string concatenate operator would be a more expected syntax to me. > > But I do not know whether that would be trivial to implement or > complicated. Allowing this would be a good thing to have, but achieving it is a bit more complicated than you'd think: 1) Overall approach I'd prefer not to special case a path label followed by a string literal, but rather allow string concatiation generally. Indeed for ages I've had vague plans to introduce the notion of "string expressions" to augment the integer expressions we already have. Concatenation would be the obvious operator, we could potentially allow substring / slicing operations as well. 2) How to evaluate At present expressions (integer expressions, because they're the only ones we have so far) are evaluated at parse time. That's significantly before we evaluate / expand path references. So naive evaluation at parse time wouldn't work for the case you give. The "full" way of handling that would be to delay evaluation of expressions, which has some other advantages, but would require a big rework (we'd need a runtime representation of expression trees, for example). However, I think we could cheat a bit and handle this using some hacks and a new "expand-to-path-without-\0" marker type. That should cover at least all the likely cases. 3) Syntax So, the remaining question is what should the string concatenation operator be. The general dtc principle of "be like C where possible" says use <empty> exactly as Rob suggests. However, in addition to the problem Rob mentions, I suspect this may cause parser conflicts which could be a pain to sort out. Other possibilities are "+" or ".", but I haven't thought of a convincing argument for any particular one so far. -- 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
