Personally, I'm not fond of this approach. There is already some
traction to using the reg-shift property to specify spacing, and I
think it would be appropriate to also define a reg-offset property to
handle the +3 offset and then let the xilinx 16550 nodes use those.
That's making things only worse than the mere "reg-shift" idea. I
think that both are totally wrong. Everything about the programming
interface should be said in the "compatible" and possibly "model"
properties.
No. In effect, you are saying here that no device binding should define
any binding-specific properties. This will just lead to combinatorial
explosion of "compatible" values.
That said, "reg-spacing"/"reg-shift"/"reg-offset" should *not* be
considered something generic; they are part of specific device
bindings. Of course it is nice if various bindings use the same
names for the same concepts, but that's an orthogonal issue.
of_serial driver should recognize them and pass the necessary details
to 8250.c. As for me, I'm strongly against plaguing the device tree
with the *Linux driver implementation specifics*
"reg-*" has nothing to do with Linux device driver implementation
issues: it describes how a device is physically wired up!
(despite I was trying this with MTD -- there it seemed somewhat more
grounded :-).
Quite the opposite, but let's not rehash that discussion.
In support of my argument; the fact that you need a table of data says
to me that this data should really be encoded in the device tree. :-)
Not at all.
Not _necessarily_. I agree with Grant here: for many of these devices
with byte-size registers, it is very common to find them with their
register banks wired up differently, and that is often the *only*
difference to the "normal" device. In this situation, it makes a lot
of sense to describe that difference with "reg-*" properties.
In some other situations, it is better to create a new binding for
the device.
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
