public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Hunold <hunold@convergence.de>
To: Greg KH <greg@kroah.com>
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: Thu, 18 Mar 2004 16:56:30 +0100	[thread overview]
Message-ID: <4059C6AE.7010102@convergence.de> (raw)
In-Reply-To: <20040316154454.GA13854@kroah.com>

Hello,

On 16.03.2004 16:44, Greg KH wrote:
> 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?

As you've already noticed below, it's completely up to the driver -- and 
I don't trust i2c drivers I haven't written... ;-)

>>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?

In theory this should be sufficient, but doesn't help if you have some 
"I don't care which bus this is and I'll probe it anyway" device.

Just think of all the i2c client drivers that are not part of the 
official kernel. I don't want to fix all these, just keep them away from 
"my" i2c busses...

>>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.

Ok, thanks. I'm heading for the small solution that doesn't break any 
existing "functionality" (if it's desired or not) and that doesn't 
require to touch every i2c driver in the kernel.

Here is the agenda:

- add a "class" field to the i2c client driver struct (ie. let the 
driver specify "I'm a DVB device" for example)
- add a flag to the adapter struct telling the i2c core "I only want 
drivers with a matching class to probe on this bus"
- make the i2c core actually check if an adapter has set the flag 
mentioned above and only let any i2c clientprobe on the bus if it has 
the matching class field

This won't break existing functionality (because all "old" i2c client 
drivers don't have the "class" field set and all "old" i2c adapters 
don't have the new flag specified) and will keep all i2c client drivers 
away from my DVB i2c busses.

The DVB i2c drivers, however, will be able to probe on the DVB i2c bus.

> thanks,
> greg k-h

CU
Michael.


      parent reply	other threads:[~2004-03-18 15:56 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
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 [this message]

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=4059C6AE.7010102@convergence.de \
    --to=hunold@convergence.de \
    --cc=greg@kroah.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox