From: abraham.manu@gmail.com (Manu Abraham)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow
Date: Tue, 06 Jun 2006 12:38:14 +0000 [thread overview]
Message-ID: <44857736.8080200@gmail.com> (raw)
In-Reply-To: <44802319.4050609@gmail.com>
Mark M. Hoffman wrote:
>> When this discussion comes along it reminds me of the PCI - ISA
>> discussions, why not probe for ISA devices like PCI devices ..
>>
>
> Yes, I understand that some devices are difficult or impossible to
> detect. And of course it is better, if you already know what device
> is present, to simply attach to it rather than try to detect it on
> the bus. Nathan's patch would allow for this. What is the problem?
>
For a device that which does not have any identification, when a third
party does attach the device, even more chances are there that it could
possibly be wrong. (I mean for devices that do not have any identification)
In such a case, to handle such a case the subsystem can handle this
difficult case more efficiently, since it can determine what device it
is through some way or the other (since it is there within the same
subsystem). This would be harder when such information has to be passed
on to another subsystem in a generic way.
>>> If so, that's interesting, I guess... do you then disagree with the
>>> *premise* of Nathan's patches? I mean, "DVB which no longer probes"
>>> is one of its goals after all.
>>>
>>> Actually, Manu: may I ask a favor? Could you please point out what are
>>> some of the most difficult and/or sticky "problem drivers" regarding
>>> DVB vs. I2C, and perhaps even describe what makes each particular
>>> instance such a pain for you? I would appreciate it.
>>>
>>>
>>>
>> Well Johannes has really clarified the issues in the other post.
>>
>
> Let me first say: if DVB people are content to use i2c_transfer() directly,
> then I'm not interested in forcing anyone otherwise. Nonetheless, there
> are other people who are interested in moving the I2C subsystem forward.
>
> I repeat: I'm not interested in forcing anyone to change their code!
>
Cool, no issues. Some discussions made many people think that these
changes were being forced down.
> No. DVB would be passing I2C subsystem specifics to the I2C subsystem.
> That makes perfect sense to me. PCI is able to self-discover and doesn't
> need any help. I2C core needs help to do that. So what? We do what we
> have to do. Especially with bus muxes, I don't see why you would want
> every I2C-using subsystem to have to solve that problem separately.
>
>
Because that wouldn't be part of I2C at all, but a part of the device
itself, which requires a separate command to the device.
Manu
prev parent reply other threads:[~2006-06-06 12:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 11:38 [lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow Manu Abraham
2006-06-02 12:05 ` Hans Verkuil
2006-06-02 12:05 ` Hans Verkuil
2006-06-02 12:17 ` Manu Abraham
2006-06-02 12:23 ` Manu Abraham
2006-06-02 12:29 ` Hans Verkuil
2006-06-02 12:42 ` Manu Abraham
2006-06-02 13:20 ` Hans Verkuil
2006-06-03 2:33 ` Mark M. Hoffman
2006-06-03 9:52 ` Johannes Stezenbach
2006-06-03 11:21 ` Manu Abraham
2006-06-06 12:00 ` Mark M. Hoffman
2006-06-06 12:04 ` Mark M. Hoffman
2006-06-06 12:38 ` Manu Abraham [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=44857736.8080200@gmail.com \
--to=abraham.manu@gmail.com \
--cc=lm-sensors@vger.kernel.org \
/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.