From: greg@kroah.com (Greg KH)
To: Michael Hunold <hunold@convergence.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
sensors@stimpy.netroedge.com
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: <20040316154454.GA13854@kroah.com> (raw)
In-Reply-To: <4056C805.8090004@convergence.de>
On Tue, Mar 16, 2004 at 10:25:25AM +0100, Michael Hunold wrote:
> Here, all client drivers are unconditionally told to try and attach to
> the adapter. There is no way that an i2c adapter can keep an i2c driver
> away from the bus.
Yes, but the different i2c chip drivers all check for the class setting
to be correct before they really do anything, right?
> Currently, adapters can already specify a class, for DVB
> I2C_ADAP_CLASS_TV_DIGITAL matches perfectly.
Yes, and that is what you should check for. It's a bug if any of the
non-DVB i2c drivers probe devices with the .class set to
I2C_ADAP_CLASS_TV_DIGITAL. Fix that and you should be fine, right?
> 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.
Yeah, right now it's up to the chip drivers to be honest. If you want
to implement a change to do this instead, I'll be glad to apply it.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Michael Hunold <hunold@convergence.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
sensors@stimpy.netroedge.com
Subject: Re: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Tue, 16 Mar 2004 07:44:54 -0800 [thread overview]
Message-ID: <20040316154454.GA13854@kroah.com> (raw)
In-Reply-To: <4056C805.8090004@convergence.de>
On Tue, Mar 16, 2004 at 10:25:25AM +0100, Michael Hunold wrote:
> Here, all client drivers are unconditionally told to try and attach to
> the adapter. There is no way that an i2c adapter can keep an i2c driver
> away from the bus.
Yes, but the different i2c chip drivers all check for the class setting
to be correct before they really do anything, right?
> Currently, adapters can already specify a class, for DVB
> I2C_ADAP_CLASS_TV_DIGITAL matches perfectly.
Yes, and that is what you should check for. It's a bug if any of the
non-DVB i2c drivers probe devices with the .class set to
I2C_ADAP_CLASS_TV_DIGITAL. Fix that and you should be fine, right?
> 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.
Yeah, right now it's up to the chip drivers to be honest. If you want
to implement a change to do this instead, I'll be glad to apply it.
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 [this message]
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 ` [RFC][2.6] Additional i2c adapter flags for i2c client isolation Greg KH
2005-05-19 6:24 ` 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=20040316154454.GA13854@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.