From: Michael Hunold <hunold@convergence.de>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Tue, 16 Mar 2004 15:23:45 +0100 [thread overview]
Message-ID: <40570DF1.7090605@convergence.de> (raw)
In-Reply-To: <1079443611.1677.194.camel@newt>
Hello Adrian,
On 16.03.2004 14:26, Adrian Cox wrote:
> On Tue, 2004-03-16 at 09:25, Michael Hunold wrote:
>>What I'd like to have is that client can specify some sort of "class",
>>too, and that i2c adapters can tell the core that only clients where the
>>class is matching are allowed to probe their existence.
>
>
> How about a general "never probe" flag combined with a function to
> connect an adapter to a client? High level drivers like DVB or BTTV
> could then do something like:
> adapter = i2c_bit_add_bus(&my_card_ops);
> i2c_connect_client(adapter, &client_ops, address);
>
> This problem comes up a lot, and i2c probing is only necessary for
> finding motherboard sensors. For add-in cards and embedded systems the
> driver developer normally knows exactly what is wired to what.
This is true for most devices (i2c eeprom, video decoder, ...), but not
for all. All DVB cards have a device called "frontend" (basically a
tuner with some additional stuff) connected via i2c.
Sometimes different frontends are used for the same revisons of one
card, so we need the probe functionality at least for these kinds of
devices.
> - Adrian Cox
> http://www.humboldt.co.uk/
CU
Michael.
next prev parent reply other threads:[~2004-03-16 14:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 9:25 [RFC][2.6] Additional i2c adapter flags for i2c client isolation Michael Hunold
2004-03-16 13:26 ` Adrian Cox
2004-03-16 14:23 ` Michael Hunold [this message]
2004-03-16 15:44 ` Greg KH
2004-03-16 19:14 ` Jean Delvare
2004-03-16 19:53 ` Greg KH
2004-03-17 9:17 ` Jean Delvare
2004-03-17 17:42 ` Greg KH
2004-03-17 20:05 ` Jean Delvare
2004-03-17 23:11 ` Greg KH
2004-03-18 15:56 ` Michael Hunold
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=40570DF1.7090605@convergence.de \
--to=hunold@convergence.de \
--cc=adrian@humboldt.co.uk \
--cc=linux-kernel@vger.kernel.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