All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.