[i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.

[Matt Sealey]

Segher Boessenkool wrote:
> 
> Yes, all devices should be in the device tree.  That's
> what it's for.
> 
>> You're not ever going to be able to specify in the device tree
>> exactly how to handle a driver, encompassing both implementation,
>> bugs in revisions, quirks of board design, but you can specify
>> for a driver a very accurate, very educated guess on it (any
>> quirks, bugs or implementation differences would be board/chip
>> specific, and are easily derived from the other device nodes
>> like the cpu node, soc node, and so on)
> 
> Actually, you can, and should.  All this information is
> contained in the "compatible" and "model" properties.
> "Quirks of board design" can be described too, on a case-
> by-case basis.
>
> All the knowledge about how to drive the device resides
> in the kernel, but the device tree describes exactly what
> device this is, so the kernel can match a driver to it
> uniquely, and the driver can know exactly what revision
> chip this is and what quirks to apply.

That's what I said wasn't it?

If you have a buggy i2c controller or one that has a strange
quirk, but it's present as fsl-i2c in those device trees,
would you specify that it is fsl-i2c-less-bugs later?
Would you add property after property to describe errata,
quirks in the nodes themselves?

I don't see the point in that, when such information is
nearly always derivable from other parts of the device
tree. An ATA node does not contain the timings for devices
on that bus. The driver usually has to work that out. If
there is a quirk to be implemented, this will be described
by the PVR/SVR and other system information already in the
device tree. The clock distribution module in the MPC52xx
changed some bit settings between the original and B versions,
I don't see any benefit in having a property or a name
change (from mpc5200-cdm or so in this example) when the
differences are well documented and also easy to work out
from the device tree without additional properties, or
name changes. If the register location changes, the register
property handles it. If the operation changes this is defined
by both the soc svr, possibly a board model, and also
possibly by the pvr (cache sizes etc.).

I'll take an example of putting useless information in
the device tree - how about the CPU node? It has all the
information for cache sizes etc. but does Linux use it?
No.. the only ONLY chip I have seen this information be
relevant on is the MPC7447/MPC7457 where it is impossible
to determine by PVR which chip you have, and even then
impossible to determine the L3 cache size. And Linux
does not even handle this; the firmware sets it up and
the L3 registers are already there for Linux to pick up
on.

This is what I mean by 'describing exactly what the device
is' being rather a tedious and time-wasting concept.

I might be a little less noisy about it if there was
some kind of edict for devices never to wander outside
of their own node in the device tree, but there isn't.
You have the entire board description available and when
that information doesn't exist, it is usually in the
chip or board itself.

I don't think the device tree has much use beyond the
advertisement and authorisation of use of system devices,
and as the most basic and essential automatic driver
processes (probe and initialisation). It is quite another
matter to make it a kind of Linux-programmers errata
replacement framework and artificially recreate already
easily-accessible information.

-- 
Matt Sealey <matt at genesi-usa.com>
Genesi, Manager, Developer Relations