On Wed, Jun 29, 2016 at 07:34:54PM -0700, Frank Rowand wrote:
> On 06/27/16 20:12, David Gibson wrote:
> > On Mon, Jun 27, 2016 at 01:40:00PM +0200, Maxime Ripard wrote:
> >> Hi David,
> >>
> >> On Mon, Jun 27, 2016 at 03:26:07PM +1000, David Gibson wrote:
> >>>> +static uint32_t overlay_get_target_phandle(const void *fdto, int fragment)
> >>>> +{
> >>>> + const uint32_t *val;
> >>>> + int len;
> >>>> +
> >>>> + val = fdt_getprop(fdto, fragment, "target", &len);
> >>>> + if (!val || (*val == 0xffffffff) || (len != sizeof(*val)))
> >>>> + return 0;
> >>>
> >>> This doesn't distinguish between a missing property (which may
> >>> indicate a valid overlay using a target-path or some other method)
> >>> and a badly formatted 'target' property, which is definitely an error
> >>> in the overlay.
> >>>
> >>> I think those should be treated differently.
> >>
> >> AFAIK, phandles can have any 32 bits values but 0xffffffff. In order
> >> to cover the two cases, we would need to have some error code, but
> >> that doesn't really work with returning a uint32_t.
> >
> > Actually phandles can have any value except 0xffffffff *or* 0. So you
> > can use 0 for "couldn't find" and -1 for "badly formatted".
>
> < snip >
>
> Hi David,
>
> I would like to capture this for the specification.
>
> It seems like I could say that a value of 0 in the FDT is not allowed.
>
> Then thinking of what Pantelis is doing with overlays, it seems like a
> value of 0xffffffff is allowed in the FDT, but it means not a valid
> phandle, so do not try to de-reference it.
>
> Does that sound good?
That should be ok. Basically both 0 and -1 are invalid phandle
values, so it's up to us if we want to assign them specific "error"
meanings.
--
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
