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

Simon Glass sjg at chromium.org
Tue Jul 14 21:49:08 CEST 2015


+Scott

Hi Hans,

On 28 April 2015 at 17:29, Simon Glass <sjg at chromium.org> wrote:
>
> 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!

It looks like this was rejected upstream. If so can you please create
a patch for fdtdec.c (I assume) to move your code into there?

Regards,
Simon


More information about the U-Boot mailing list