On Fri, Mar 23, 2018 at 08:30:34AM -0600, Simon Glass wrote:
> On 20 March 2018 at 21:45, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> > The current code throws away all the data type and grouping information
> > when parsing the DTS source file, which makes it difficult to
> > reconstruct the data format when emitting a format that can express data
> > types (ie. dts and yaml). Use the marker structure to mark the beginning
> > of each integer array block (<> and []), and the datatype contained in
> > each (8, 16, 32 & 64 bit widths).
> >
> > Signed-off-by: Grant Likely <grant.likely@xxxxxxx>
> > ---
> > data.c | 4 +++-
> > dtc-parser.y | 15 ++++++++++-----
> > dtc.h | 7 +++++++
> > 3 files changed, 20 insertions(+), 6 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@xxxxxxxxxxxx>
>
> > diff --git a/dtc.h b/dtc.h
> > index 760f9e3..8734f47 100644
> > --- a/dtc.h
> > +++ b/dtc.h
> > @@ -76,7 +76,14 @@ enum markertype {
> > REF_PHANDLE,
> > REF_PATH,
> > LABEL,
> > + MARKER_UINT8,
> > + MARKER_UINT16,
> > + MARKER_UINT32,
> > + MARKER_UINT64,
> > + MARKER_BLOB,
> > + MARKER_STRING,
>
> The names are now inconsistent - perhaps they should all have a
> MARKER_ prefix?
I think it makes sense to separate these new markers from the others
by name, since they're all about type information. "MARKER" is kind
of meaningless, though. How about "TYPE_*".
>
> > };
> > +extern const char *markername(enum markertype markertype);
> >
> > struct marker {
> > enum markertype type;
> >
>
> REgards,
> Simon
--
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
