From: ppokorny@penguincomputing.com (Philip Pokorny)
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: sensors@Stimpy.netroedge.com, linux-kernel@vger.kernel.org,
Michael Hunold <m.hunold@gmx.de>, Greg KH <greg@kroah.com>
Subject: [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client
Date: Thu, 19 May 2005 06:24:50 +0000 [thread overview]
Message-ID: <40716F40.4070609@penguincomputing.com> (raw)
In-Reply-To: <1081163597.607.15.camel@newt>
Adrian Cox wrote:
>On Sat, 2004-04-03 at 15:30, Jean Delvare wrote:
>
>
>
>>I'm not sure that the function you propose would be really useful. I
>>guess that most people don't load i2c chip drivers they don't need. The
>>class filter you propose, added to the different I2C addresses, should
>>do the rest.
>>
>>
>
>What about using two DVB cards of different models to record off one
>multiplex while watching another?
>
>Only an explicit list of which chips should be probed on each I2C bus is
>safe for this sort of system.
>
>
>
You might be able to use the ignore= and force= parameters to the i2c
drivers to accomplish this. With ignore you can prevent a driver from
scanning an address (specify -1 as the bus to ignore that address on all
busses) and with force you can specify which bus/address to find the
specific chip.
I haven't read the code in detail yet, but if force doesn't already
override ignore, it probably should. I can't think of reason why you
would want ignore to override a force directive.
:v)
WARNING: multiple messages have this Message-ID (diff)
From: Philip Pokorny <ppokorny@penguincomputing.com>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: sensors@Stimpy.netroedge.com, linux-kernel@vger.kernel.org,
Michael Hunold <m.hunold@gmx.de>, Greg KH <greg@kroah.com>
Subject: Re: [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation
Date: Mon, 05 Apr 2004 07:37:52 -0700 [thread overview]
Message-ID: <40716F40.4070609@penguincomputing.com> (raw)
In-Reply-To: <1081163597.607.15.camel@newt>
Adrian Cox wrote:
>On Sat, 2004-04-03 at 15:30, Jean Delvare wrote:
>
>
>
>>I'm not sure that the function you propose would be really useful. I
>>guess that most people don't load i2c chip drivers they don't need. The
>>class filter you propose, added to the different I2C addresses, should
>>do the rest.
>>
>>
>
>What about using two DVB cards of different models to record off one
>multiplex while watching another?
>
>Only an explicit list of which chips should be probed on each I2C bus is
>safe for this sort of system.
>
>
>
You might be able to use the ignore= and force= parameters to the i2c
drivers to accomplish this. With ignore you can prevent a driver from
scanning an address (specify -1 as the bus to ignore that address on all
busses) and with force you can specify which bus/address to find the
specific chip.
I haven't read the code in detail yet, but if force doesn't already
override ignore, it probably should. I can't think of reason why you
would want ignore to override a force directive.
:v)
next prev parent reply other threads:[~2005-05-19 6:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-19 6:24 [Fwd: [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Michael Hunold
2004-03-30 19:34 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Jean Delvare
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-04-03 13:20 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Michael Hunold
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Michael Hunold
2004-04-03 14:30 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Jean Delvare
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-04-04 13:05 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Michael Hunold
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Michael Hunold
2004-04-04 14:48 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Jean Delvare
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-04-05 11:03 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Michael Hunold
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Michael Hunold
2004-04-05 11:13 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client isolation Adrian Cox
2005-05-19 6:24 ` [RFC|PATCH][2.6] Additional i2c adapter flags for i2c client Adrian Cox
2004-04-05 14:37 ` Philip Pokorny [this message]
2005-05-19 6:24 ` Philip Pokorny
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=40716F40.4070609@penguincomputing.com \
--to=ppokorny@penguincomputing.com \
--cc=adrian@humboldt.co.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.hunold@gmx.de \
--cc=sensors@Stimpy.netroedge.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.