From: Wolfgang Grandegger <wg@grandegger.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
Detlev Zundel <dzu@denx.de>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 09:50:15 +0000 [thread overview]
Message-ID: <487DC457.6000103@grandegger.com> (raw)
In-Reply-To: <20080716113311.384d211e@hyperion.delvare>
Hi Jean;
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> For hwmon chips, probing only occurs if the i2c adapter accepts to be
>>> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
>>> you do not want a given i2c bus to be probed, then do not set the flag
>>> for that bus.
>> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
>> for the MPC:
>>
>> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>>
>> If I disable it, the LM75 driver only probes the addresses of the I2C
>> nodes defined in the FDT DTS file. I wonder if this should not be the
>> default behaviour for kernels using OF platform description. For this
>> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
>> are some patches for OF I2C pending. I will check.
>
> The problem is that at this point in time, only a couple hwmon drivers
> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> would break most systems.
>
> I have a set of patches converting most hwmon drivers to new-style i2c.
> I plan to send it to Linus later today. Once all drivers are converted,
> everyone can start adding device definitions to platform code. And only
> once this is done for all platforms, you may remove I2C_CLASS_HWMON
> from the i2c-mpc driver.
Of course.
> But even then, you can't exclude the possibility that some people want
> to keep relying on the auto-detection mode. In that case, the setting
I understood that this is only true for the HWMON devices. Why the
special treatment?
> of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
> device.
Yep, as probing might not be acceptable in some cases, I makes sense to
add a property to suppress probing:
i2c@3000 {
...
compatible = "fsl-i2c";
dfsrr;
no-probing;
rtc@32 {
compatible = "epson,rx8025";
reg = <0x32>;
};
dtt@4c {
compatible = "dallas,ds75";
reg = <0x4c>;
};
};
> Anyway, this is something for every platform community to decide and
> work on. As the i2c subsystem maintainer, I made my best so that
> everything (sensible) is possible. But in the end it's up to the
> "users" (i.e. platform developers and maintainers) to make the decision
> of how things should work in their area. I can give advice on migration
> paths, but I can't take decisions for them.
I'm going to prepare a patch for that purpose.
Wolfgang.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg@grandegger.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
Detlev Zundel <dzu@denx.de>,
lm-sensors@lm-sensors.org
Subject: Re: [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 11:50:15 +0200 [thread overview]
Message-ID: <487DC457.6000103@grandegger.com> (raw)
In-Reply-To: <20080716113311.384d211e@hyperion.delvare>
Hi Jean;
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> For hwmon chips, probing only occurs if the i2c adapter accepts to be
>>> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
>>> you do not want a given i2c bus to be probed, then do not set the flag
>>> for that bus.
>> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
>> for the MPC:
>>
>> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>>
>> If I disable it, the LM75 driver only probes the addresses of the I2C
>> nodes defined in the FDT DTS file. I wonder if this should not be the
>> default behaviour for kernels using OF platform description. For this
>> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
>> are some patches for OF I2C pending. I will check.
>
> The problem is that at this point in time, only a couple hwmon drivers
> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> would break most systems.
>
> I have a set of patches converting most hwmon drivers to new-style i2c.
> I plan to send it to Linus later today. Once all drivers are converted,
> everyone can start adding device definitions to platform code. And only
> once this is done for all platforms, you may remove I2C_CLASS_HWMON
> from the i2c-mpc driver.
Of course.
> But even then, you can't exclude the possibility that some people want
> to keep relying on the auto-detection mode. In that case, the setting
I understood that this is only true for the HWMON devices. Why the
special treatment?
> of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
> device.
Yep, as probing might not be acceptable in some cases, I makes sense to
add a property to suppress probing:
i2c@3000 {
...
compatible = "fsl-i2c";
dfsrr;
no-probing;
rtc@32 {
compatible = "epson,rx8025";
reg = <0x32>;
};
dtt@4c {
compatible = "dallas,ds75";
reg = <0x4c>;
};
};
> Anyway, this is something for every platform community to decide and
> work on. As the i2c subsystem maintainer, I made my best so that
> everything (sensible) is possible. But in the end it's up to the
> "users" (i.e. platform developers and maintainers) to make the decision
> of how things should work in their area. I can give advice on migration
> paths, but I can't take decisions for them.
I'm going to prepare a patch for that purpose.
Wolfgang.
next prev parent reply other threads:[~2008-07-16 9:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 9:22 [lm-sensors] [PATCH] Support for DS75 thermal sensor Wolfgang Grandegger
2008-07-08 9:53 ` Jean Delvare
2008-07-08 13:09 ` Wolfgang Grandegger
2008-07-08 13:29 ` Jean Delvare
2008-07-08 13:38 ` Wolfgang Grandegger
2008-07-11 12:40 ` Wolfgang Grandegger
2008-07-11 12:56 ` Jean Delvare
2008-07-16 9:12 ` Wolfgang Grandegger
2008-07-16 9:12 ` Wolfgang Grandegger
2008-07-16 9:33 ` Jean Delvare
2008-07-16 9:33 ` Jean Delvare
2008-07-16 9:50 ` Wolfgang Grandegger [this message]
2008-07-16 9:50 ` Wolfgang Grandegger
2008-07-16 10:10 ` [lm-sensors] " Jean Delvare
2008-07-16 10:10 ` Jean Delvare
2008-07-16 10:23 ` [lm-sensors] " Wolfgang Grandegger
2008-07-16 10:23 ` Wolfgang Grandegger
2008-07-16 14:08 ` [lm-sensors] " Grant Likely
2008-07-16 14:08 ` Grant Likely
2008-07-16 14:18 ` [lm-sensors] " Jon Smirl
2008-07-16 14:18 ` Jon Smirl
2008-07-16 14:29 ` [lm-sensors] " Jean Delvare
2008-07-16 14:29 ` Jean Delvare
2008-07-17 7:31 ` [lm-sensors] " Wolfgang Grandegger
2008-07-17 7:31 ` Wolfgang Grandegger
2008-07-17 7:33 ` [lm-sensors] " Grant Likely
2008-07-17 7:33 ` Grant Likely
2008-07-17 10:39 ` [lm-sensors] " Wolfgang Grandegger
2008-07-17 10:39 ` Wolfgang Grandegger
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=487DC457.6000103@grandegger.com \
--to=wg@grandegger.com \
--cc=Linuxppc-dev@ozlabs.org \
--cc=alanc@pipstechnology.co.uk \
--cc=dzu@denx.de \
--cc=khali@linux-fr.org \
--cc=lm-sensors@lm-sensors.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.