From: Greg KH <greg@kroah.com>
To: Michael Hunold <hunold-ml@web.de>
Cc: linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Subject: Re: [PATCH][2.6] Add command function to struct i2c_adapter
Date: Thu, 30 Sep 2004 23:52:09 -0700 [thread overview]
Message-ID: <20041001065209.GA9561@kroah.com> (raw)
In-Reply-To: <415481B4.10804@web.de>
On Fri, Sep 24, 2004 at 10:21:08PM +0200, Michael Hunold wrote:
> >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?
>
> Partly, yes.
>
> The .class approach is necessary to have a finer grained access control
> by the i2c-core regarding bus classes, ie. not the client drivers have
> to check if the bus should be probed (for example dcc drivers on a dvb
> bus). This is useful in general.
>
> If we have a PCI card where we exactly know what we are doing, we can
> use the NO_PROBE flag to effectively block any probing and can use the
> proposed interface to manually connect the clients.
But why? The .class feature can accomplish this too. Just create a new
class for this type of adapter and device. Then only that device will
be able to be connected to that adapter, just like you want to have
happen, right?
thanks,
greg k-h
next prev parent reply other threads:[~2004-10-01 7:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 17:19 [PATCH][2.6] Add command function to struct i2c_adapter Michael Hunold
2004-09-21 15:41 ` Greg KH
2004-09-21 17:10 ` Michael Hunold
2004-09-21 17:39 ` Jon Smirl
2004-09-21 18:05 ` Michael Hunold
2004-09-22 8:56 ` Adrian Cox
2004-09-22 12:08 ` Jean Delvare
2004-09-22 11:54 ` Adrian Cox
2004-09-22 13:38 ` Jean Delvare
2004-09-22 13:13 ` Adrian Cox
2004-09-22 15:40 ` Jon Smirl
2004-09-22 15:56 ` Adrian Cox
2004-09-22 16:07 ` Jon Smirl
2004-09-22 16:51 ` Adrian Cox
2004-09-22 17:17 ` Jon Smirl
2004-09-22 18:55 ` Jean Delvare
2004-09-22 18:32 ` Adrian Cox
2004-09-22 20:04 ` Mark M. Hoffman
2004-09-23 7:41 ` Michael Hunold
2004-09-23 7:48 ` Michael Hunold
2004-09-23 7:09 ` Michael Hunold
2004-09-23 20:18 ` Adrian Cox
2004-09-21 20:33 ` Jean Delvare
2004-09-21 21:02 ` Jon Smirl
2004-09-24 17:06 ` Michael Hunold
2004-09-24 18:05 ` Jean Delvare
2004-09-24 20:21 ` Michael Hunold
2004-10-01 6:52 ` Greg KH [this message]
2004-10-01 12:22 ` Adrian Cox
2004-10-01 13:57 ` Jean Delvare
2004-10-01 23:41 ` Greg KH
[not found] <41500BED.8090607@linuxtv.org>
2004-09-21 13:28 ` Jean Delvare
2004-09-21 14:38 ` Michael Hunold
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=20041001065209.GA9561@kroah.com \
--to=greg@kroah.com \
--cc=hunold-ml@web.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox