Re: case sensitivity for devicetree node names

On 06/13/16 18:10, David Gibson wrote:

On Fri, Jun 10, 2016 at 01:05:24PM -0700, Frank Rowand wrote:

quoted

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.

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".

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