From: greg@kroah.com (Greg KH)
To: linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Cc: Michael Hunold <hunold@convergence.de>
Subject: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Thu, 19 May 2005 06:24:48 +0000 [thread overview]
Message-ID: <20040316195325.GA22473@kroah.com> (raw)
In-Reply-To: <20040316201426.1d01f1d3.khali@linux-fr.org>
On Tue, Mar 16, 2004 at 08:14:26PM +0100, Jean Delvare wrote:
>
> I guess that chip drivers would be allowed to define only one class
> while adapters could possibly define more than one?
Not necessarily. Just make the class a bit field, showing what kind of
devices each expects to handle.
> We also would want to introduce an I2C_ADAP_CLASS_ANY define, which
> would be what the eeprom driver would use, for example (since it can be
> hosted on any kind of bus). Generic bus drivers such as i2c-parport
> would also use I2C_ADAP_CLASS_ANY, since the nature of the hosted chips
> is unknown.
Sure:
#define I2C_ADAP_CLASS_ANY 0xffffffff
works for me :)
> Having clients define a class sounds also interesting from a
> user-space's point of view. If we would export this information through
> sysfs for example, programs such as "sensors" could limit their work to
> chips of the correct class (I2C_ADAP_CLASS_SMBUS at the moment, but a
> renaming is planned).
That also is a good idea.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Cc: Michael Hunold <hunold@convergence.de>
Subject: Re: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Tue, 16 Mar 2004 11:53:26 -0800 [thread overview]
Message-ID: <20040316195325.GA22473@kroah.com> (raw)
In-Reply-To: <20040316201426.1d01f1d3.khali@linux-fr.org>
On Tue, Mar 16, 2004 at 08:14:26PM +0100, Jean Delvare wrote:
>
> I guess that chip drivers would be allowed to define only one class
> while adapters could possibly define more than one?
Not necessarily. Just make the class a bit field, showing what kind of
devices each expects to handle.
> We also would want to introduce an I2C_ADAP_CLASS_ANY define, which
> would be what the eeprom driver would use, for example (since it can be
> hosted on any kind of bus). Generic bus drivers such as i2c-parport
> would also use I2C_ADAP_CLASS_ANY, since the nature of the hosted chips
> is unknown.
Sure:
#define I2C_ADAP_CLASS_ANY 0xffffffff
works for me :)
> Having clients define a class sounds also interesting from a
> user-space's point of view. If we would export this information through
> sysfs for example, programs such as "sensors" could limit their work to
> chips of the correct class (I2C_ADAP_CLASS_SMBUS at the moment, but a
> renaming is planned).
That also is a good idea.
thanks,
greg k-h
next prev parent reply other threads:[~2005-05-19 6:24 UTC|newest]
Thread overview: 20+ 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
2004-03-16 15:44 ` Greg KH
2005-05-19 6:24 ` Greg KH
2004-03-16 19:14 ` Jean Delvare
2005-05-19 6:24 ` [RFC][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-03-16 19:53 ` Greg KH [this message]
2005-05-19 6:24 ` [RFC][2.6] Additional i2c adapter flags for i2c client isolation Greg KH
2004-03-17 9:17 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2004-03-17 17:42 ` Greg KH
2005-05-19 6:24 ` Greg KH
2004-03-17 20:05 ` Jean Delvare
2005-05-19 6:24 ` [RFC][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-03-17 23:11 ` [RFC][2.6] Additional i2c adapter flags for i2c client isolation Greg KH
2005-05-19 6:24 ` Greg KH
2004-03-18 15:56 ` Michael Hunold
2005-05-19 6:24 ` Michael Hunold
2005-05-19 6:24 ` [RFC][2.6] Additional i2c adapter flags for i2c client 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=20040316195325.GA22473@kroah.com \
--to=greg@kroah.com \
--cc=hunold@convergence.de \
--cc=linux-kernel@vger.kernel.org \
--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.