devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
To: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	David Gibson
	<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH] libfdt: fdt_path_offset_*(): Fix handling of paths with options in them
Date: Wed, 03 Jun 2015 09:02:35 -0400	[thread overview]
Message-ID: <556EFAEB.9070004@hurleysoftware.com> (raw)
In-Reply-To: <55696C37.6090806-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On 05/30/2015 03:52 AM, Hans de Goede wrote:
> Hi,
> 
> On 29-05-15 14:26, David Gibson wrote:
>> On Thu, May 21, 2015 at 03:00:52PM +0200, Hans de Goede wrote:
>>> This is another approach at fixing the issues with paths with have options
>>> appended seperated by a ':' character.
>>>
>>> commit b4150b59ae ("libfdt: Add fdt_path_offset_namelen()")
>>>
>>> Is related to this, it allows the caller to specify to only look at part
>>> of the passed in path. But as experience with using this in the kernel has
>>> shown using this properly is quite hard since the options itself may have
>>> a '/' in them, also see the comment above the new fdt_path_next_seperator
>>> helper this commit adds.
>>>
>>> So this commit, which currently is being used by u-boot, instead simply
>>> teaches fdt_path_offset() to just do the right thing when it encounters
>>> paths with a ':' in them.
>>
>> I dislike this - it's building into the core path handling something
>> related to how external things happen to glue extra options on there.
>>
>> I also don't see why it's necessary.  ':' shouldn't appear in paths,
>> so why can't you just strchr() for the first ':', pass the first path
>> to path_offset_namelen, and the last part to your option parsing code?
> 
> When I wrote this (I was a bit slow in submitting it upstream)
> path_offset_namelen did not exist yet.
> 
> But more importantly the Linux kernel is also doing the handling of ':'
> at the same low level, see __of_find_node_by_path in drivers/of/base.c
> in the kernel, which is the kernel equivalent of fdt_path_offset.

Not quite; that code is for _after_ the devicetree is unflattened.

The patch-on-deck for handling stdout-path options in earlycon code,
[v3] of:earlycon: Fix 'stdout-path' with ':' path terminator,
does just as David suggests.

Regards,
Peter Hurley

> So to me it seems best to also handle this at the same level in libfdt
> rather then expecting callers to deal with this, as that will lead to
> more and more callers needing to be fixed when the same construct gets
> used in more places.
> 
> Regards,
> 
> Hans
> 
>>>
>>> Cc: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>   libfdt/fdt_ro.c | 25 ++++++++++++++++++++++---
>>>   1 file changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
>>> index a65e4b5..9efbcb2 100644
>>> --- a/libfdt/fdt_ro.c
>>> +++ b/libfdt/fdt_ro.c
>>> @@ -154,6 +154,25 @@ int fdt_subnode_offset(const void *fdt, int parentoffset,
>>>       return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
>>>   }
>>>
>>> +/*
>>> + * Find the next of path seperator, note we need to search for both '/' and ':'
>>> + * and then take the first one so that we do the rigth thing for e.g.
>>> + * "foo/bar:option" and "bar:option/otheroption", both of which happen, so
>>> + * first searching for either ':' or '/' does not work.
>>> + */
>>> +static const char *fdt_path_next_seperator(const char *path, int len)
>>> +{
>>> +    const char *sep1 = memchr(path, '/', len);
>>> +    const char *sep2 = memchr(path, ':', len);
>>> +
>>> +    if (sep1 && sep2)
>>> +        return (sep1 < sep2) ? sep1 : sep2;
>>> +    else if (sep1)
>>> +        return sep1;
>>> +    else
>>> +        return sep2;
>>> +}
>>> +
>>>   int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
>>>   {
>>>       const char *end = path + namelen;
>>> @@ -164,7 +183,7 @@ int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
>>>
>>>       /* see if we have an alias */
>>>       if (*path != '/') {
>>> -        const char *q = memchr(path, '/', end - p);
>>> +        const char *q = fdt_path_next_seperator(path, end - p);
>>>
>>>           if (!q)
>>>               q = end;
>>> @@ -182,10 +201,10 @@ int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
>>>
>>>           while (*p == '/') {
>>>               p++;
>>> -            if (p == end)
>>> +            if (p == end || *p == ':')
>>>                   return offset;
>>>           }
>>> -        q = memchr(p, '/', end - p);
>>> +        q = fdt_path_next_seperator(p, end - p);
>>>           if (! q)
>>>               q = end;
>>>

  parent reply	other threads:[~2015-06-03 13:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-21 13:00 [PATCH] libfdt: fdt_path_offset_*(): Fix handling of paths with options in them Hans de Goede
     [not found] ` <1432213252-30292-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-29 12:26   ` David Gibson
     [not found]     ` <20150529122605.GC3664-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-05-30  7:52       ` Hans de Goede
     [not found]         ` <55696C37.6090806-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-03 13:02           ` Peter Hurley [this message]
2015-07-02  7:16           ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556EFAEB.9070004@hurleysoftware.com \
    --to=peter-wagbzjegnqdsbiue7sb01tbpr1lh4cv8@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).