On Sat, Sep 15, 2018 at 12:08 PM Grant Likely <Grant.Likely@xxxxxxx> wrote:
>
>
>
> > On 14 Sep 2018, at 19:39, Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > Commit 32b9c6130762 ("Preserve datatype markers when emitting dts format")
> > fails to split string lists into multiple strings and instead just outputs
> > a "\0" between strings. This is broken when the input is dtb or fs tree.
> >
> > This could be fixed in the dts output where the problem was introduced,
> > but fix it by adding markers on the input side instead. This will allow
> > for any possible future uses of type markers.
>
> I’m not keen putting the resolution in the input stage. It creates a weird split between when the type predictions happen. Strings are predicted at input, and everything else at output. I would be happier if a middle processing stage were added to go over the entire tree and add missing data tokens. Then the output could drop all data prediction logic.
The only other prediction is 4 byte multiple cells are uint32, so it's
not like there's a whole bunch of prediction left.
The middle stage would be in the checks infra which is where I'd
envision using the markers more. But we have ways to order checks and
there's already some phandle fixups IIRC, so that could work. I'll
defer to David. I don't really care (other than I've already written
this way.)
Rob
