On Mon, Sep 19, 2011 at 09:45:34AM -0700, Anton Staaf wrote:
> On Sun, Sep 18, 2011 at 7:00 PM, David Gibson
> <da...@gibson.dropbear.id.au> wrote:
> > On Sat, Sep 17, 2011 at 11:49:21AM -0500, Jon Loeliger wrote:
> >> > On Fri, Sep 09, 2011 at 12:16:30PM -0700, Anton Staaf wrote:
> >> > > With this patch the following property assignment:
> >> > >
> >> > >     property = <0x12345678 'a' '\r' 100>;
> >> > >
> >> > > is equivalent to:
> >> > >
> >> > >     property = <0x12345678 0x00000061 0x0000000D 0x00000064>
> >> > >
> >> > > Signed-off-by: Anton Staaf <robot...@chromium.org>
> >> >
> >> > Acked-by: David Gibson <da...@gibson.dropbear.id.au>
> >>
> >> So, I *think* we want to wait until the question of size
> >> is resolved some more, right?  Or, take this in any event
> >> as "without a type indicator they are all 32-bit values"?
> >
> > No this patch is fine to take without changing the cell size
> > semantics.  It's just that it becomes a lot more useful when we do get
> > those.
> 
> Yup, I'm working on a size patch by the way.  Any comments on my
> previous post about it would be helpful.  But in the mean time I'm
> going ahead with a solution where the current cell size is stored in
> the "struct data" type references are not allowed in cell lists of
> size other than 32 bits.

Ah, sorry, I meant to give comments on that earlier but got
sidetracked.

Storing the cell size in struct data doesn't really work - a single
property could be assembled from several cell lists of different
sizes.  By the time the reference substitution happens, they will have
been all merged into a single struct data.

I think prohibiting cell references anywhere but 32-bit cell lists is
the right approach, but we need to work out a way to do the check
during the parse phase.

-- 
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
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Reply via email to