devicetree-spec.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: case sensitivity for devicetree node names
Date: Tue, 14 Jun 2016 15:10:28 +1000	[thread overview]
Message-ID: <20160614051028.GL4882@voom.fritz.box> (raw)
In-Reply-To: <575F7FC1.5040508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]

On Mon, Jun 13, 2016 at 08:53:37PM -0700, Frank Rowand wrote:
> On 06/13/16 18:10, David Gibson wrote:
> > On Fri, Jun 10, 2016 at 01:05:24PM -0700, Frank Rowand wrote:
> >> I had assumed that devicetree node names were case sensitive. But a recent
> >> email thread asserted that they were not, which made me curious.
> >>
> >> dtc treats node names as case sensitive:
> >>
> >> $ cat test_node_case_1.dts
> >>
> >> /dts-v1/;
> >>
> >> / {
> >> 	node-x {
> >> 		prop_a = < 1 >;
> >> 	};
> >> };
> >>
> >> / {
> >> 	node-X {
> >> 		prop_a = < 2 >;
> >> 	};
> >> };
> >>
> >> $ cat test_node_case_2.dts
> >>
> >> /dts-v1/;
> >>
> >> / {
> >> 	node-x {
> >> 		prop_a = < 1 >;
> >> 	};
> >> };
> >>
> >> / {
> >> 	node-x {
> >> 		prop_a = < 2 >;
> >> 	};
> >> };
> >>
> >> $ dtc -O dts test_node_case_1.dts
> >> /dts-v1/;
> >>
> >> / {
> >>
> >> 	node-x {
> >> 		prop_a = <0x1>;
> >> 	};
> >>
> >> 	node-X {
> >> 		prop_a = <0x2>;
> >> 	};
> >> };
> >>
> >> $ dtc -O dts test_node_case_2.dts
> >> /dts-v1/;
> >>
> >> / {
> >>
> >> 	node-x {
> >> 		prop_a = <0x2>;
> >> 	};
> >> };
> >>
> >>
> >> But the Linux kernel source code defines of_node_cmp() as:
> >>
> >>   include/linux/of.h:
> >>
> >>   /* Default string compare functions, Allow arch asm/prom.h to override */
> >>   #if !defined(of_compat_cmp)
> >>   #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
> >>
> >> arch/sparc/include/asm/prom.h uses strcmp() instead of strcasecmp().
> >>
> >> Examples of using of_node_cmp() to check for a node name can be found,
> >> for example, of_find_node_by_name().
> >>
> >> Is case insensitivity for node names a bug in the Linux kernel, or desired
> >> for some reason?
> > 
> > Hmm.. a bit embarrassingly, I've never really thought about this in
> > all the years I've been doing dtc - I also pretty much just assumed
> > it was case-sensitive.
> > 
> > I haven't been able to find something in IEEE 1275 definitively saying
> > one way or the other - it's not exactly easy to search for since
> > "case" gives you hundreds or thousands of irrelevant hits of the form
> > "in the case of blah".
> 
> One reference in 1275 that I just happened to notice this morning is
> in "3.2.1.1 Node names":
> 
>    Each node in the device tree is identified by a node name using the following notation:
> 
>       driver-name@unit-addres:device-arguments
> 
>    The driver name field is a sequence of between one and 31 letters, digits, and punctuation characters from the set
>    ",._+-". Uppercase and lowercase characters are distinct.
> 
> I am reading "Uppercase and lowercase characters are distinct" to mean that
> node names are case sensitive.

Yes, that's my reading as well.

> > I do recall that there was a semantic difference between vendor
> > prefixes in uppercase (they were supposed to be stock tickers) and
> > those in lowercase (those were freeform).  That suggests that property
> > names at least were expected to be case sensitive.
> > 
> > Here's my inclination for how to treat this in dtc for the time being:
> >     1) Leave the bulk of dtc case sensitive, as now
> >     2) Add a new check which will generate an error if there are node
> >        names which differ only in case.
> > 
> > Any objections to that plan?
> 
> I think that the kernel should match the current behavior of dtc.
> 
> I agree with "1)".
> 
> I don't think that "2)" is required.  I think it is a really dumb idea for
> anyone to create a dts with node names that differ only in case.  But I
> don't think it is the compiler's job to protect people from being dumb.
> An analogue would be the C language and compilers.  The C compiler doesn't
> error on a program that has variables "foo" and "Foo".

Hmm.. actually I think protecting you from being dumb is exactly the
purpose of compiler warnings.  Now that you found that quote from
1275, which is pretty definitive as far as I'm concerned, I'd expect
to reduce that error to a warning (by default).

> My current thought is to create a Linux kernel RFC patch that 
> 
> 1) changes of_node_cmp() and friends to something like:
> 
>    #ifdef CONFIG_OF_CASE_BROKEN
>    #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
>    #else
>    #define of_node_cmp(s1, s2) strcmp((s1), (s2))
>    #endif
> 
> 2) remove the sparc definition of of_node_cmp() and friends.
> 
> 3) Change the Kconfig entry for CONFIG_PPC_PMAC to select
>    CONFIG_OF_CASE_BROKEN
> 
> Then let the patch sit in the -next tree for two releases to
> try to shake out any issues.  Any other case broken platform
> could then select or set CONFIG_OF_CASE_BROKEN if the dts
> and/or code can't be reasonably fixed.
> 
> I have a patch series (a few kernel printks and a userspace
> program to parse the console output) that shows 1) which
> properties the kernel attempts to access but do not exist
> in a given device tree and 2) which properties are in a
> given device tree but the kernel does _not_ attempt to
> access.  I could probably extend that to do the same checks
> for node names.  The patch series is not quite ready for
> prime-time, but I could make it easily available for
> anyone who is trying to figure out why my proposed
> kernel patch breaks a system's boot.  Then it becomes
> a case by case choice of whether to fix the devicetrees or
> modify the kernel to also check for the incorrect case node.
> 
> -Frank

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2016-06-14  5:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 20:05 case sensitivity for devicetree node names Frank Rowand
     [not found] ` <575B1D84.2010703-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-10 21:38   ` Rob Herring
     [not found]     ` <CAL_JsqKw8dVp5y487fo6_mwZfeN6ww8HiYnsudnB8afBrv2oMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-10 22:02       ` Frank Rowand
2016-06-11 19:38   ` Frank Rowand
     [not found]     ` <575C68A1.1020701-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-11 22:05       ` Benjamin Herrenschmidt
     [not found]         ` <1465682743.19533.18.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2016-06-12 18:39           ` Frank Rowand
     [not found]             ` <575DAC69.5010804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-12 21:56               ` Benjamin Herrenschmidt
2016-06-14  1:10   ` David Gibson
     [not found]     ` <20160614011021.GD4882-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2016-06-14  3:53       ` Frank Rowand
     [not found]         ` <575F7FC1.5040508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-14  5:10           ` David Gibson [this message]
     [not found]             ` <20160614051028.GL4882-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2016-06-14  5:29               ` Frank Rowand
     [not found]                 ` <575F963F.8090105-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-14  6:05                   ` 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=20160614051028.GL4882@voom.fritz.box \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@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 read-only IMAP folder(s) and NNTP newsgroup(s).