On Thu, Aug 23, 2018 at 7:37 AM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Thu, Aug 23, 2018 at 11:29:01AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-08-22 at 20:26 -0500, Rob Herring wrote: > > > On Wed, Aug 22, 2018 at 8:14 PM Benjamin Herrenschmidt > > > <b...@kernel.crashing.org> wrote: > > > > > > > > On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote: > > > > > The default DT string handling in the kernel is node names and > > > > > compatibles are case insensitive and property names are case sensitive > > > > > (Sparc is the the only variation and is opposite). It seems only PPC > > > > > (and perhaps only Power Macs?) needs to support case insensitive > > > > > comparisons. It was probably a mistake to follow PPC for new arches > > > > > and we should have made everything case sensitive from the start. So I > > > > > have a few questions for the DT historians. :) > > > > > > > > Open Firmware itself is insensitive. > > > > > > Doesn't it depend on the implementation? Otherwise, how is Sparc > > > different? > > > > Not sure ... > > The standard requires case-sensitive. > > > Forth itself is insensitive for words > > Not even. http://forth.sourceforge.net/std/dpans/dpans3.htm#3.3.1.2 > > (Most non-ancient implementations are though). > > > but maybe not for string comparisons. > > Only COMPARE is standardised, and that is case-sensitive comparison. Many > systems have other words to do case-insensitive comparisons, or words where > some runtime flag determines the case-sensitivity. > > Btw. A node name in Open Firmware is generically > driver-name@unit-address:device-arguments > where driver-name is the part that is in the "name" property; this whole > case-sensitivity business is even worse for FDT, where you also treat the > unit address as part of the name. In real Open Firmware the address is > compared *as a number* (or as a few numbers), so it is naturally case- > insensitive (it does not care if you write 01a0 or 01A0, or 1a0 or 000001a0 > etc.)
True, but it is very rare at least in Linux to look at the unit-addresses. dtc now does some checking on unit-addresses too, so we should at least be consistent. Another question: Is there ever a case where the node name in the path aka 'driver-name' doesn't match the 'name' property? I think this generally can't happen on FDT as the 'name' property is generated when we unflatten it though I suppose one could craft an FDT with name properties. There's also various places in the kernel that check for a NULL name which doesn't seem like it could happen either other than the root node. Rob
