From: greg@kroah.com (Greg KH)
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: Michael Hunold <hunold-ml@web.de>,
linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Subject: [PATCH][2.6] Add command function to struct i2c_adapter
Date: Thu, 19 May 2005 06:25:18 +0000 [thread overview]
Message-ID: <20041001234115.GA9505@kroah.com> (raw)
In-Reply-To: <1096633365.16121.125.camel@newt>
On Fri, Oct 01, 2004 at 01:22:45PM +0100, Adrian Cox wrote:
> On Fri, 2004-10-01 at 07:52, Greg KH wrote:
> > On Fri, Sep 24, 2004 at 10:21:08PM +0200, Michael Hunold wrote:
>
> > > 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?
>
> Either the i2c devices need to be able to support a list of permitted
> adapters, or the i2c adapters need a list of permitted clients. A single
> class isn't adequate. Consider the following scenario:
>
> The FooTV123 has multiplexor MX3R0K3 and frontend XYZZY, the TVMatic3000
> has frontend XYZZY and multiplexor MX31337, and the FooTV124 has
> multiplexor MX31337 and frontend FR012. All three cards are installed in
> the same machine. In the worst case the probe code for MX31337 puts
> MX3R0K3 into a state that requires a hard reset.
>
> Manual connection of clients makes it easier to develop a driver outside
> the kernel tree, then merge it when ready, without having to allocate a
> number from a central authority.
Ok, I now understand better, thanks for putting up with me :)
So, got a patch to do this?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: Michael Hunold <hunold-ml@web.de>,
linux-kernel@vger.kernel.org, sensors@Stimpy.netroedge.com
Subject: Re: [PATCH][2.6] Add command function to struct i2c_adapter
Date: Fri, 1 Oct 2004 16:41:15 -0700 [thread overview]
Message-ID: <20041001234115.GA9505@kroah.com> (raw)
In-Reply-To: <1096633365.16121.125.camel@newt>
On Fri, Oct 01, 2004 at 01:22:45PM +0100, Adrian Cox wrote:
> On Fri, 2004-10-01 at 07:52, Greg KH wrote:
> > On Fri, Sep 24, 2004 at 10:21:08PM +0200, Michael Hunold wrote:
>
> > > 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?
>
> Either the i2c devices need to be able to support a list of permitted
> adapters, or the i2c adapters need a list of permitted clients. A single
> class isn't adequate. Consider the following scenario:
>
> The FooTV123 has multiplexor MX3R0K3 and frontend XYZZY, the TVMatic3000
> has frontend XYZZY and multiplexor MX31337, and the FooTV124 has
> multiplexor MX31337 and frontend FR012. All three cards are installed in
> the same machine. In the worst case the probe code for MX31337 puts
> MX3R0K3 into a state that requires a hard reset.
>
> Manual connection of clients makes it easier to develop a driver outside
> the kernel tree, then merge it when ready, without having to allocate a
> number from a central authority.
Ok, I now understand better, thanks for putting up with me :)
So, got a patch to do this?
thanks,
greg k-h
next prev parent reply other threads:[~2005-05-19 6:25 UTC|newest]
Thread overview: 65+ 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
2005-05-19 6:25 ` Greg KH
2004-09-21 17:10 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-21 17:39 ` Jon Smirl
2005-05-19 6:25 ` Jon Smirl
2004-09-21 18:05 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-22 8:56 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 12:08 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-22 11:54 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 13:38 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-22 13:13 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 15:40 ` Jon Smirl
2005-05-19 6:25 ` Jon Smirl
2004-09-22 15:56 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 16:07 ` Jon Smirl
2005-05-19 6:25 ` Jon Smirl
2004-09-22 16:51 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 17:17 ` Jon Smirl
2005-05-19 6:25 ` Jon Smirl
2004-09-22 18:55 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-22 18:32 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-22 20:04 ` Mark M. Hoffman
2005-05-19 6:25 ` Mark M. Hoffman
2004-09-23 7:41 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-23 7:48 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-23 7:09 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-23 20:18 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-09-21 20:33 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-21 21:02 ` Jon Smirl
2005-05-19 6:25 ` Jon Smirl
2004-09-24 17:06 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-09-24 18:05 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-24 20:21 ` Michael Hunold
2005-05-19 6:25 ` Michael Hunold
2004-10-01 6:52 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-10-01 12:22 ` Adrian Cox
2005-05-19 6:25 ` Adrian Cox
2004-10-01 13:57 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-10-01 23:41 ` Greg KH [this message]
2005-05-19 6:25 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2005-05-19 6:25 [Fwd: [PATCH][2.6] Add command function to struct i2c_adapter] Michael Hunold
2004-09-21 13:28 ` [PATCH][2.6] Add command function to struct i2c_adapter Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-09-21 14:38 ` Michael Hunold
2005-05-19 6:25 ` 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=20041001234115.GA9505@kroah.com \
--to=greg@kroah.com \
--cc=adrian@humboldt.co.uk \
--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 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.