Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [PATCH 1/2] [IDE] Platform IDE driver | Date | Mon, 6 Aug 2007 19:16:27 +0200 |
| |
>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |