More importantly, "reg-shift" doesn't say what part of
the bigger words to access. A common example is byte-wide
registers on a 32-bit-only bus; it's about 50%-50% between
connecting the registers to the low byte vs. connecting it
to the byte with the lowest address.
We already have "big-endian" prop used in MPIC nodes, IIRC. Could
try to "reuse" it here as well...
Sure. This would be an okay way to handle legacy devices that
are connected in inventive ways: add "reg-shift" and/or "big-endian"
properties. We should make sure this is documented in the
appropriate bindings though, don't just assume it will work.
For non-legacy devices, please just use the "compatible"
property to figure out the endianness etc.; it is a bad idea
to make a "blablabla-big-endian" compatible value, but you can
almost often just use a more specific model name instead; and
typically the device has some other quirks anyway ;-)
It would be nice to not name similar properties in the
device tree dissimilarly. Kernel code doesn't come into
the picture here.
The "reg-shift" prop is yet unaccepted ad-hockery at this point. ;-)
So, I don't see why we have to be consistent with it.
Don't treat your ad-hockery ad hoc, that way leads to insanity :-)
It's quite important to use good names for all new properties
you define, so you naturally end up with similar names for
similar purposes. Of course it isn't a *requirement*, you're
right about that.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
