Support for DS75 thermal sensor
PATCH 1/1 Support for DS75 thermal sensor
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
does fix the problem and I wonder why it did not make it into the kernel yet.
--- drivers/hwmon/lm75.c | 59 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 22 deletions(-)
Index: linux-2.6-denx/drivers/hwmon/lm75.c =================================--- linux-2.6-denx.orig/drivers/hwmon/lm75.c +++ linux-2.6-denx/drivers/hwmon/lm75.c
@@ -35,7 +35,7 @@ static const unsigned short normal_i2c[]
0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(lm75);
+I2C_CLIENT_INSMOD_2(lm75, ds75);
/* Many LM75 constants specified below */
@@ -157,49 +157,64 @@ static int lm75_detect(struct i2c_adapte
new_client->flags = 0;
/* Now, we do the remaining detection. There is no identification-
- dedicated register so we have to rely on several tricks: - unused bits, registers cycling over 8-address boundaries, - addresses 0x04-0x07 returning the last read value. + dedicated register so we have to rely on several tricks. + The LM75 and DS75 share unused bits. The LM75 has registers + cycling over 8-address boundaries, and addresses 0x04-0x07 + returning the last read value. + The DS75 has addresses 0x04-0x0f returning the last read value, + but does not register cycle.
The cycling+unused addresses combination is not tested, since it would significantly slow the detection down and would hardly add any value. */
if (kind < 0) {
- int cur, conf, hyst, os;
+ int cur, conf, hyst, os, addr;
/* Unused addresses */
cur = i2c_smbus_read_word_data(new_client, 0); conf = i2c_smbus_read_byte_data(new_client, 1); hyst = i2c_smbus_read_word_data(new_client, 2);
- if (i2c_smbus_read_word_data(new_client, 4) != hyst
- || i2c_smbus_read_word_data(new_client, 5) != hyst - || i2c_smbus_read_word_data(new_client, 6) != hyst - || i2c_smbus_read_word_data(new_client, 7) != hyst)
- goto exit_free;
+
+ for (addr = 0x04; addr <= 0x0f; addr++)
+ if (i2c_smbus_read_word_data(new_client, addr) != hyst)
+ break;
+
+ if (addr < 0x08)
+ goto exit_free;
+ if (addr = 0x10)
+ kind = ds75;
+ else
+ kind = lm75;
+
os = i2c_smbus_read_word_data(new_client, 3);
- if (i2c_smbus_read_word_data(new_client, 4) != os
- || i2c_smbus_read_word_data(new_client, 5) != os - || i2c_smbus_read_word_data(new_client, 6) != os - || i2c_smbus_read_word_data(new_client, 7) != os)
- goto exit_free;
+ for (addr = 0x04; addr <= 0x0f; addr++)
+ if (i2c_smbus_read_word_data(new_client, addr) != os)
+ break;
+
+ if (addr < (kind = ds75 ? 0x10 : 0x08))
+ goto exit_free;
/* Unused bits */
if (conf & 0xe0)
goto exit_free;
- /* Addresses cycling */
- for (i = 8; i < 0xff; i += 8)
- if (i2c_smbus_read_byte_data(new_client, i + 1) != conf
- || i2c_smbus_read_word_data(new_client, i + 2) != hyst - || i2c_smbus_read_word_data(new_client, i + 3) != os)
- goto exit_free;
+ /* Addresses cycling - LM75 only */
+ if (kind = lm75) {
+ for (i = 8; i < 0xff; i += 8)
+ if (i2c_smbus_read_byte_data(new_client, i + 1) != conf
+ || i2c_smbus_read_word_data(new_client, i + 2) != hyst + || i2c_smbus_read_word_data(new_client, i + 3) != os)
+ goto exit_free;
+ }
}
- /* Determine the chip type - only one kind supported! */
if (kind <= 0)
kind = lm75;
+ /* Determine the chip type */
if (kind = lm75) {
name = "lm75";
+ } else if (kind = ds75) {
+ name = "ds75";
}
/* Fill in the remaining client fields and put it into the global list */
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 6 lines · Wolfgang Grandegger
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
does fix the problem and I wonder why it did not make it into the kernel yet.
Because meanwhile the lm75 driver was converted to a new-style i2c driver, with support for the DS75:
This will presumably go in kernel 2.6.27-rc1.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 6 lines · Jean Delvare
Quoted 5 lines · Wolfgang Grandegger
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
Quoted 8 lines
Quoted 1 line
does fix the problem and I wonder why it did not make it into the kernel yet.
Because meanwhile the lm75 driver was converted to a new-style i2c driver, with support for the DS75:
This will presumably go in kernel 2.6.27-rc1.
Ah, thanks for the info. Unfortunately, this new driver does not work with the DS75 on our custom board. THe identification fails, because it's as in the old lm75.c driver (and not like Alan suggested).
Wolfgang.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 12 lines · Wolfgang Grandegger
Quoted 11 lines · Jean Delvare
Quoted 6 lines · Wolfgang Grandegger
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
does fix the problem and I wonder why it did not make it into the kernel yet.
Because meanwhile the lm75 driver was converted to a new-style i2c driver, with support for the DS75:
Quoted 7 lines
Quoted 3 lines
This will presumably go in kernel 2.6.27-rc1.
Ah, thanks for the info. Unfortunately, this new driver does not work with the DS75 on our custom board. THe identification fails, because it's as in the old
lm75.cdriver (and not like Alan suggested).
There's no "detection" involved for the new-style i2c devices. Presumably you are still using the old binding model, not taking benefit of the patch at all. Use i2c_register_board_info() to instantiate your "ds75" i2c device from you board's platform code, and it should work.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 19 lines · Jean Delvare
Quoted 11 lines · Wolfgang Grandegger
Quoted 10 lines · Jean Delvare
Quoted 6 lines · Wolfgang Grandegger
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
does fix the problem and I wonder why it did not make it into the kernel yet.
Because meanwhile the lm75 driver was converted to a new-style i2c driver, with support for the DS75:
Quoted 6 lines
Quoted 3 lines
This will presumably go in kernel 2.6.27-rc1.
Ah, thanks for the info. Unfortunately, this new driver does not work with the DS75 on our custom board. THe identification fails, because it's as in the old
lm75.cdriver (and not like Alan suggested).
Quoted 5 lines
There's no "detection" involved for the new-style i2c devices. Presumably you are still using the old binding model, not taking benefit of the patch at all. Use
i2c_register_board_info()to instantiate your "ds75" i2c device from you board's platform code, and it should work.
OK, I see. For my board I need to add a FDT node to the DTS file and add some binding code like for the RTC. For the lm75, it still works without that.
Wolfgang.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 19 lines · Jean Delvare
Quoted 11 lines · Wolfgang Grandegger
Quoted 10 lines · Jean Delvare
Quoted 6 lines · Wolfgang Grandegger
The existing driver for the LM75 is unable to identify a compatible DS75 device properly. This patch from
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018838.html
does fix the problem and I wonder why it did not make it into the kernel yet.
Because meanwhile the lm75 driver was converted to a new-style i2c driver, with support for the DS75:
Quoted 6 lines
Quoted 3 lines
This will presumably go in kernel 2.6.27-rc1.
Ah, thanks for the info. Unfortunately, this new driver does not work with the DS75 on our custom board. THe identification fails, because it's as in the old
lm75.cdriver (and not like Alan suggested).
Quoted 5 lines
There's no "detection" involved for the new-style i2c devices. Presumably you are still using the old binding model, not taking benefit of the patch at all. Use
i2c_register_board_info()to instantiate your "ds75" i2c device from you board's platform code, and it should work.
I have some general question on I2C device probing. Our board does have two I2C buses. On the first on, there is an RTC at addr 0x32 and a DS75 at 0x4c. Both are defined in the Flattened Device Tree and therefore i2c_register_board_info() will be called for them. On the second bus, there are other I2C devices. Nevertheless, probing for RTC and DS75 at addr 0x32 and 0x4c will be performed also on that bus. Is this the normal/intended behavior? Can such probing be suppressed?
Thanks.
Wolfgang.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Wolfgang,
Quoted 7 lines · Wolfgang Grandegger
Quoted 5 lines · Jean Delvare
There's no "detection" involved for the new-style i2c devices. Presumably you are still using the old binding model, not taking benefit of the patch at all. Use
i2c_register_board_info()to instantiate your "ds75" i2c device from you board's platform code, and it should work.
Quoted 7 lines
I have some general question on I2C device probing. Our board does have two I2C buses. On the first on, there is an RTC at addr
0x32and a DS75 at0x4c. Both are defined in the Flattened Device Tree and thereforei2c_register_board_info()will be called for them. On the second bus, there are other I2C devices. Nevertheless, probing for RTC and DS75 at addr0x32and0x4cwill be performed also on that bus. Is this the normal/intended behavior? Can such probing be suppressed?
Probing isn't supposed to happen at all for RTC chips. There are a few drivers which remain to be converted though (rtc-ds1672, rtc-max6900, rtc-pcf8583.) If you use one of these and would like to help converting it, please tell me (and Alessandro Zummo.)
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.
Additionally, with legacy i2c chip drivers you can prevent a probe from happening by passing an "ignore" parameter. For example, loading the lm75 driver with:
modprobe lm75 ignore=1,0x48,1,0x49
will prevent the lm75 driver from probing I2C addresses 0x48 and 0x49 on i2c bus 1.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Jean,
Quoted 9 lines · Jean Delvare
Hi Wolfgang,
Quoted 6 lines · Wolfgang Grandegger
Quoted 5 lines · Jean Delvare
There's no "detection" involved for the new-style i2c devices. Presumably you are still using the old binding model, not taking benefit of the patch at all. Use
i2c_register_board_info()to instantiate your "ds75" i2c device from you board's platform code, and it should work.
Quoted 6 lines
Quoted 1 line
I have some general question on I2C device probing. Our board does have two I2C buses. On the first on, there is an RTC at addr
0x32and a DS75 at0x4c. Both are defined in the Flattened Device Tree and thereforei2c_register_board_info()will be called for them. On the second bus, there are other I2C devices. Nevertheless, probing for RTC and DS75 at addr0x32and0x4cwill be performed also on that bus. Is this the normal/intended behavior? Can such probing be suppressed?Probing isn't supposed to happen at all for RTC chips. There are a few drivers which remain to be converted though (rtc-ds1672, rtc-max6900, rtc-pcf8583.) If you use one of these and would like to help converting it, please tell me (and Alessandro Zummo.)
OK. We ported an old RTC driver for the Epson RX8025 for our board. Unfortunately, it did not use the new bindings but I fixed that in the meantime. It will be posted for kernel inclusion soon.
Quoted 4 lines
For hwmon chips, probing only occurs if the i2c adapter accepts to be probed, by setting the
I2C_CLASS_HWMONflag 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.
Wolfgang.
Hi Wolfgang,
Quoted 9 lines · Wolfgang Grandegger
Quoted 4 lines · Jean Delvare
For hwmon chips, probing only occurs if the i2c adapter accepts to be probed, by setting the
I2C_CLASS_HWMONflag 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_HWMONis set in the I2C bus driver for the MPC:
Quoted 7 lines
http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314If 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.
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 of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc device.
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.
Signature · 1 line
Jean Delvare
Hi Jean;
Quoted 18 lines · Jean Delvare
Hi Wolfgang,
Quoted 10 lines · Wolfgang Grandegger
Quoted 4 lines · Jean Delvare
For hwmon chips, probing only occurs if the i2c adapter accepts to be probed, by setting the
I2C_CLASS_HWMONflag 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_HWMONis set in the I2C bus driver for the MPC:http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314If 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_HWMONwould break most systems.
Quoted 5 lines
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_HWMONfrom the i2c-mpc driver.
Of course.
Quoted 2 lines
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?
Quoted 2 lines
of the
I2C_CLASS_HWMONflag 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>;
};
};Quoted 6 lines
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.
Quoted 11 lines · Wolfgang Grandegger
Quoted 9 lines · Jean Delvare
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_HWMONwould 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_HWMONfrom the i2c-mpc driver.
Quoted 7 lines
Of course.
Quoted 2 lines
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?
Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.
What makes hwmon a bit different is the historical context. Originally, the hwmon drivers were written for PCs, which have no per-system platform code, so declaring the devices was simply not an option. Additionally, i2c was maintained as part of the lm-sensors project itself. This determined the probe-everything approach that has ruled the i2c subsystem until recently. I've spent (with a few other developers) the past few years drawing a clear separation between i2c and hwmon, and now making it possible to declare i2c devices where possible. This is a lot of work if you want to do this without breaking any system out there (which is my case.)
Quoted 5 lines
Quoted 2 lines
of the
I2C_CLASS_HWMONflag should become an attribute of each i2c-mpc device.Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
But then again, that's not really my business. The decision is left to the actual users of this i2c bus driver.
Signature · 1 line
Jean Delvare
Quoted 19 lines · Jean Delvare
Quoted 10 lines · Wolfgang Grandegger
Quoted 9 lines · Jean Delvare
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_HWMONwould 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_HWMONfrom the i2c-mpc driver.Quoted 5 lines
Of course.
Quoted 2 lines
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?
Not really. There are other I2C_CLASS_* flags, just check <
linux/i2c.h>.
Quoted 10 lines
What makes hwmon a bit different is the historical context. Originally, the hwmon drivers were written for PCs, which have no per-system platform code, so declaring the devices was simply not an option. Additionally, i2c was maintained as part of the lm-sensors project itself. This determined the probe-everything approach that has ruled the i2c subsystem until recently. I've spent (with a few other developers) the past few years drawing a clear separation between i2c and hwmon, and now making it possible to declare i2c devices where possible. This is a lot of work if you want to do this without breaking any system out there (which is my case.)
I can image. Thanks for the explanation.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
of the
I2C_CLASS_HWMONflag should become an attribute of each i2c-mpc device.Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
Yep, unfortunately, HWMON devices are not defined in most cases.
Quoted 2 lines
But then again, that's not really my business. The decision is left to the actual users of this i2c bus driver.
A RFC patch is in preparation.
Wolfgang.
Quoted 8 lines · Jean Delvare
Quoted 4 lines · Wolfgang Grandegger
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
Total ACK. From my perspective, probing should be off by default because the typical use case in powerpc land is to trust data in the device tree. Add the property to turn on probing, not to turn it off. Also, you'll need to document the semantics of such a property. ie. what exactly does it mean when the probing property is present and the spi bus node has child nodes?
g.
Quoted 12 lines · Grant Likely
Quoted 9 lines · Jean Delvare
Quoted 5 lines · Wolfgang Grandegger
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
Quoted 6 lines
Total ACK. From my perspective, probing should be off by default because the
typical use case in powerpc land is to trust data in the device tree. Add the property to turn on probing, not to turn it off. Also, you'll need to document the semantics of such a property. ie. what exactly does it mean when the probing property is present and the spi bus node has child nodes?
I've found this thread now. Why can't we totally remove probing from i2c-mpc? These are embedded systems, not open boxes like a PC. If a i2c client hasn't been converted to the new model yet, convert it before deploying with the new i2c-mpc driver. It's not very hard to convert the client drivers.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 20 lines · Jon Smirl
Quoted 12 lines · Grant Likely
Quoted 9 lines · Jean Delvare
Quoted 5 lines · Wolfgang Grandegger
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
Quoted 6 lines
Total ACK. From my perspective, probing should be off by default because the
typical use case in powerpc land is to trust data in the device tree. Add the property to turn on probing, not to turn it off. Also, you'll need to document the semantics of such a property. ie. what exactly does it mean when the probing property is present and the spi bus node has child nodes?
Quoted 5 lines
I've found this thread now. Why can't we totally remove probing from i2c-mpc? These are embedded systems, not open boxes like a PC. If a i2c client hasn't been converted to the new model yet, convert it before deploying with the new i2c-mpc driver. It's not very hard to convert the client drivers.
I tend to agree. And the number of unconverted drivers is getting very low these days. Only 2 RTC drivers are left, and by the end of the day, almost all hwmon drivers will be converted as well.
Signature · 1 line
Jean Delvare
Quoted 26 lines · Jean Delvare
Quoted 19 lines · Jon Smirl
Quoted 12 lines · Grant Likely
Quoted 9 lines · Jean Delvare
Quoted 5 lines · Wolfgang Grandegger
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding is that all systems using i2c-mpc should have proper platform data.
Quoted 6 lines
Total ACK. From my perspective, probing should be off by default because the
typical use case in powerpc land is to trust data in the device tree. Add the property to turn on probing, not to turn it off. Also, you'll need to document the semantics of such a property. ie. what exactly does it mean when the probing property is present and the spi bus node has child nodes?Quoted 5 lines
I've found this thread now. Why can't we totally remove probing from i2c-mpc? These are embedded systems, not open boxes like a PC. If a i2c client hasn't been converted to the new model yet, convert it before deploying with the new i2c-mpc driver. It's not very hard to convert the client drivers.
Quoted 3 lines
I tend to agree. And the number of unconverted drivers is getting very low these days. Only 2 RTC drivers are left, and by the end of the day, almost all hwmon drivers will be converted as well.
Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag completely. It just affects HWMON devices anyhow and if there is still an old style driver around, it should be converted.
Wolfgang.
Quoted 8 lines · Wolfgang Grandegger
Quoted 7 lines · Jean Delvare
Quoted 5 lines · Jon Smirl
I've found this thread now. Why can't we totally remove probing from i2c-mpc? These are embedded systems, not open boxes like a PC. If a i2c client hasn't been converted to the new model yet, convert it before deploying with the new i2c-mpc driver. It's not very hard to convert the client drivers.
Quoted 7 lines
Quoted 3 lines
I tend to agree. And the number of unconverted drivers is getting very low these days. Only 2 RTC drivers are left, and by the end of the day, almost all hwmon drivers will be converted as well.
Thinking more about it I also prefer removing the
I2C_CLASS_HWMONflag completely. It just affects HWMON devices anyhow and if there is still an old style driver around, it should be converted.
I'm cool with that.
g.
Quoted 8 lines · Grant Likely
Quoted 7 lines · Wolfgang Grandegger
Quoted 6 lines · Jean Delvare
Quoted 5 lines · Jon Smirl
I've found this thread now. Why can't we totally remove probing from i2c-mpc? These are embedded systems, not open boxes like a PC. If a i2c client hasn't been converted to the new model yet, convert it before deploying with the new i2c-mpc driver. It's not very hard to convert the client drivers.
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
I tend to agree. And the number of unconverted drivers is getting very low these days. Only 2 RTC drivers are left, and by the end of the day, almost all hwmon drivers will be converted as well.
Thinking more about it I also prefer removing the
I2C_CLASS_HWMONflag completely. It just affects HWMON devices anyhow and if there is still an old style driver around, it should be converted.I'm cool with that.
Good, just sent a new patch.
Wolfgang.