From: Segher Boessenkool <segher@kernel.crashing.org>
To: Matt Sealey <matt@genesi-usa.com>
Cc: Jean Delvare <khali@linux-fr.org>,
linuxppc-dev@ozlabs.org, i2c@lm-sensors.org
Subject: Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
Date: Sat, 19 May 2007 18:25:38 +0200 [thread overview]
Message-ID: <94e1abed8781f279d2d4c7cddbc25ba2@kernel.crashing.org> (raw)
In-Reply-To: <464EFE96.3000801@genesi-usa.com>
>> 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?
Not at all, no.
> 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?
No. All this can be easily derived from the "model"
properties in the relevant nodes.
> 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?
It *should* use it though. But it cannot really do that,
since many/most device trees are broken in this respect.
Linux *does* use some of the "cpu" properties though.
Maybe in the future it will use more.
> This is what I mean by 'describing exactly what the device
> is' being rather a tedious and time-wasting concept.
This is equivalent to stating the device tree is a useless
concept. You are free to your opinion of course.
> 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.
I'm not sure what you mean here. It is best practice
for device nodes to be reasonably self-contained though.
Of course not completely; every node always has to refer
to its parent bus, etc. Device drivers will sometimes
have to refer to board model for board-specific workarounds.
> 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).
Again, you are free to your own opinion.
> It is quite another
> matter to make it a kind of Linux-programmers errata
> replacement framework and artificially recreate already
> easily-accessible information.
No one is proposing that I hope. This information indeed
is already easily available in most cases -- namely, in
the device tree.
Segher
next prev parent reply other threads:[~2007-05-19 16:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-17 14:38 [PATCH 3/5] powerpc: Document device nodes for I2C devices Scott Wood
2007-05-17 16:12 ` Kumar Gala
2007-05-17 16:17 ` Scott Wood
2007-05-17 16:39 ` Kumar Gala
2007-05-17 16:47 ` Scott Wood
2007-05-17 17:21 ` Kumar Gala
2007-05-17 18:29 ` Scott Wood
2007-05-18 15:15 ` [i2c] " Jean Delvare
2007-05-18 16:24 ` Kumar Gala
2007-05-18 16:35 ` Scott Wood
2007-05-18 17:10 ` Kumar Gala
2007-05-18 17:17 ` Scott Wood
2007-05-18 17:33 ` Kumar Gala
2007-05-18 17:55 ` Scott Wood
2007-05-20 11:53 ` Jean Delvare
2007-05-21 14:57 ` Scott Wood
2007-05-19 0:04 ` Matt Sealey
2007-05-19 0:17 ` Segher Boessenkool
2007-05-19 13:41 ` Matt Sealey
2007-05-19 16:25 ` Segher Boessenkool [this message]
2007-05-20 14:53 ` Matt Sealey
2007-05-20 15:48 ` Segher Boessenkool
2007-05-27 9:48 ` Matt Sealey
2007-05-20 11:42 ` Jean Delvare
2007-05-18 20:07 ` Segher Boessenkool
2007-05-17 19:18 ` Segher Boessenkool
2007-05-17 19:32 ` Scott Wood
2007-05-17 19:44 ` Segher Boessenkool
2007-05-17 21:15 ` Scott Wood
2007-05-18 15:27 ` [i2c] " Jean Delvare
2007-05-18 15:58 ` Scott Wood
2007-05-18 16:29 ` Kumar Gala
2007-05-18 16:31 ` Jean Delvare
2007-05-18 16:56 ` Kumar Gala
2007-05-18 19:00 ` David Brownell
2007-05-18 15:19 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94e1abed8781f279d2d4c7cddbc25ba2@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=i2c@lm-sensors.org \
--cc=khali@linux-fr.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=matt@genesi-usa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.