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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
