Date: Fri, 24 Sep 2004 20:05:03 +0200
From: Jean Delvare <khali@linux-fr.org>
To: Michael Hunold <hunold-ml@web.de>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org,
       sensors@Stimpy.netroedge.com
Subject: Re: [PATCH][2.6] Add command function to struct i2c_adapter
Message-Id: <20040924200503.652ccf8e.khali@linux-fr.org>
In-Reply-To: <41545421.5080408@web.de>
References: <414F111C.9030809@linuxtv.org>
	<20040921154111.GA13028@kroah.com>
	<41545421.5080408@web.de>
Reply-To: linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1229
Lines: 29

> We like to have an completly isolated i2c adapter, where the device 
> driver can invite i2c drivers to connect an i2c client to. When the 
> connection is made, an "interface" pointer with client-specific data
> or function pointers can be provided.
> (...)
> - add a new NO_PROBE flag to struct i2c_adapter, so a particular
> adapter is never probed by anyone

I don't get it. If the adapter is isolated, there is no way the i2c-core
will probe it anyway. As Adrian Cox underlined, it should be far easier
and more efficient to separate these adapters from the main i2c adapters
list from the beginning than leaving them in the main list and then try
and prevent future probings using a flag.

Also, how does this proposal interact with the work on the i2c classes?
Although the classes carry more information than a simple flag or a
complete separation, both were/may be introduced to achieve the same
goal, isn't it?

Thanks,

-- 
Jean "Khali" Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/