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?
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
