[U-Boot] [PATCH] fdt: Fix handling of paths with options in them

[Simon Glass]

On 24 April 2015 at 07:34, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 24-04-15 14:42, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 23 April 2015 at 10:15, Simon Glass <sjg at chromium.org> wrote:
>>>
>>> Hi Hans,
>>>
>>> On 23 April 2015 at 00:55, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 22-04-15 19:20, Simon Glass wrote:
>>>>>
>>>>>
>>>>> Hi Hans,
>>>>>
>>>>> On 20 April 2015 at 12:10, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 20-04-15 17:39, Simon Glass wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> On 20 April 2015 at 03:13, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> After syncing the sunxi dts files with the upstream kernel dm/fdt
>>>>>>>> sunxi
>>>>>>>> builds would no longer boot.
>>>>>>>>
>>>>>>>> The problem is that stdout-path is now set like this in the upstream
>>>>>>>> dts
>>>>>>>> files: stdout-path = "serial0:115200n8". The use of options in
>>>>>>>> of-paths,
>>>>>>>> either after an alias name, or after a full path, e.g. stdout-path =
>>>>>>>> "/soc at 01c00000/serial at 01c28000:115200", is standard of usage, but
>>>>>>>> something
>>>>>>>> which the u-boot dts code so far did not handle.
>>>>>>>>
>>>>>>>> This commit fixes this, adding support for both path formats.
>>>>>>>>
>>>>>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>>>>>> ---
>>>>>>>>     arch/arm/dts/sun7i-a20-pcduino3.dts |  2 +-
>>>>>>>>     lib/libfdt/fdt_ro.c                 | 25
>>>>>>>> ++++++++++++++++++++++---
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I haven't looked. but is this change in dtc upstream or just in the
>>>>>>> kernel?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is just a change in the dts files shipped with the kernel not in
>>>>>> dtc,
>>>>>> the dts files for sunxi used to not set stdout-path, and you patched
>>>>>> in
>>>>>> a stdout-path setting for u-boot:
>>>>>
>>>>>
>>>>>
>>>>> In that case, can we change this in the fdt support /fdtdec code,
>>>>> instead of making a change to libfdt that will never go upstream?
>>>>>
>>>>> If that doesn't work or is too painful, then we should take this patch.
>>>>
>>>>
>>>>
>>>> Actually I started with fixing this the fdtdev level, but then I noticed
>>>> that the kernel does this at the of_find_node_by_path level, so if we
>>>> fix this for stdout-path only (which a fdtdec patch would do) then we
>>>> may
>>>> get bit by this again later.
>>>>
>>>> Also fixing it at the fdtdec level means adding a strdup + error
>>>> checking
>>>> since then we need to pass a truncated (options removed) copy of the
>>>> path
>>>> to fdt_path_offset(), while with the current patch we can keep using
>>>> read only access to the fdt.
>>>>
>>>> So I've a slight preference for going this way. Why would libfdt
>>>> upstream
>>>> not
>>>> take this patch ?
>>>
>>>
>>> I'm not sure, but please go ahead and send it upstream. Thanks for the
>>> explanation, I'll pick this up.
>>>
>>> Acked-by: Simon Glass <sjg at chromium.org>
>>>
>>
>> Can I just check if you are OK to send this upstream? We don't need to
>> wait for it to be accepted, just want to know it will be sent.
>
>
> Yes I will submit this upstream.

Applied to u-boot-fdt, thanks!

- Simon