From: David Brownell <david-b@pacbell.net>
To: Jean Delvare <khali@linux-fr.org>
Cc: linuxppc-dev@ozlabs.org, i2c@lm-sensors.org
Subject: Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
Date: Fri, 18 May 2007 12:00:31 -0700 [thread overview]
Message-ID: <200705181200.31445.david-b@pacbell.net> (raw)
In-Reply-To: <20070518183140.4644ffc6@hyperion.delvare>
On Friday 18 May 2007, Jean Delvare wrote:
> On Fri, 18 May 2007 10:58:06 -0500, Scott Wood wrote:
> > Jean Delvare wrote:
> > > On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
> > >
> > >>(and the
> > >>i2c code in Linux should be fixed to allow drivers to specify multiple
> > >>match names).
> > >
> > >
> > > Back when David proposed his new-style i2c code, I had the same
> > > objection. But we addressed the need differently. If you look at struct
> > > i2c_board_info, you'll see two string fields, driver_name and type. The
> > > former specifies the driver name, the second specifies the exact device
> > > variant. For drivers which support several device variants, the
> > > platform code should fill both fields.
> >
> > But that still requires the platform to know the driver name, rather
> > than matching any driver which knows about the type.
Given that the platform (== board/system) may care about the upper layer
of the driver (APIs exposed) not just the lower one (talking-to-hardware),
that seems like a reasonable tradeoff. It wouldn't want to use the driver
which provides the wrong programming interface!
Plus, to repeat, there is no notion of "type" in I2C. So in order to
talk about a "type based matching" algorithm you'd have to define one...
> > This prevents the
> > use of OS-independent device trees (such as in Open Firmware), which
> > cannot know specific Linux driver names, without something hacky like a
> > type-to-driver table in the device tree code.
>
> Oh well, this was also the reason why I objected to David's approach in
> the first place. If you dig back in the i2c list archive, you'll find
> that I was asking for exactly the same thing you do now: that each i2c
> driver would export a list of supported devices, and the i2c-core would
> match a device name against that list (independent of the driver name.)
> It felt more flexible, but I wondered how useful it would be in
> practice, and finally gave up and David had the last word. If you had
> shown up back then rather than now...
With concrete suggestions and patches. I'd have to dig back in the
list archives to see the details of what was said at that time, but
I don't recall any suggestions being rejected unless they dropped
essential functionality. (There was one notion to key driver binding
purely on device address, for example...)
- Dave
next prev parent reply other threads:[~2007-05-18 19:00 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
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 [this message]
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=200705181200.31445.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=i2c@lm-sensors.org \
--cc=khali@linux-fr.org \
--cc=linuxppc-dev@ozlabs.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).