[PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.

[Segher Boessenkool]

>> 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