[lm-sensors] [PATCH] Document existing support for SMSC EMC2300 fan

[lm-sensors] [PATCH] Document existing support for SMSC EMC2300 fan

[Steve Glendinning]

The recently added support for EMC6D103S also supports EMC2300.
These two devices report exactly the same revision/stepping
register, so it's not possible to tell them apart.

EMC2300 doesn't have all the voltage inputs that EMC6D103S has,
so reports in0, in3 and in4 all as zero.

Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
---
 Documentation/hwmon/lm85 |   10 +++++++++-
 drivers/hwmon/lm85.c     |    2 ++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85
index 7c49fea..04cc342 100644
--- a/Documentation/hwmon/lm85
+++ b/Documentation/hwmon/lm85
@@ -34,6 +34,10 @@ Supported chips:
     Prefix: 'emc6d103s'
     Addresses scanned: I2C 0x2c, 0x2d, 0x2e
     Datasheet: http://www.smsc.com/main/catalog/emc6d103s.html
+  * SMSC EMC2300
+    Prefix: 'emc6d103s'
+    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
+    Datasheet: http://www.smsc.com/media/Downloads_Public/Data_Sheets/2300.pdf
 
 Authors:
         Philip Pokorny <ppokorny@penguincomputing.com>,
@@ -47,7 +51,7 @@ Description
 
 This driver implements support for the National Semiconductor LM85 and
 compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
-SMSC EMC6D10x chips family.
+SMSC EMC6D10x and EMC2300 chips family.
 
 The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
 specification. Using an analog to digital converter it measures three (3)
@@ -136,6 +140,10 @@ of voltage and temperature channels.
 SMSC EMC6D103S is similar to EMC6D103, but does not support pwm#_auto_pwm_minctl
 and temp#_auto_temp_off.
 
+SMSC EMC2300 is similar to EMC6D103S, with fewer voltage inputs.
+Unfortunately it is not possible to distinguish between these two on a register
+level so EMC2300's voltage inputs in0, in3 and in4 will read zero.
+
 Hardware Configurations
 -----------------------
 
diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
index da72dc1..4b89b70 100644
--- a/drivers/hwmon/lm85.c
+++ b/drivers/hwmon/lm85.c
@@ -1260,6 +1260,8 @@ static int lm85_detect(struct i2c_client *client, struct i2c_board_info *info)
 			type_name = "emc6d103";
 			break;
 		case LM85_VERSTEP_EMC6D103S:
+			/* Note: this also matches EMC2300, we can't tell
+			 * the difference between the two */
 			type_name = "emc6d103s";
 			break;
 		}
-- 
1.7.4.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Jean Delvare]

Hi Steve,

On Tue, 10 May 2011 15:21:28 +0100, Steve Glendinning wrote:
> The recently added support for EMC6D103S also supports EMC2300.
> These two devices report exactly the same revision/stepping
> register, so it's not possible to tell them apart.

Thanks for your contribution, this is very appreciated.

> EMC2300 doesn't have all the voltage inputs that EMC6D103S has,
> so reports in0, in3 and in4 all as zero.

Wouldn't this be good way to differentiate between the parts? What
values are returned by the EMC2300 for registers 0x20, 0x23, 0x24,
0x44, 0x45, 0x4a, 0x4b 0x4c and 0x4d?

BTW, if you could provide a register dump for the EMC2300 (using the
i2c-dev kernel driver and i2cdump tool from the i2c-tools package) that
would be appreciated.

> 
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
> ---
>  Documentation/hwmon/lm85 |   10 +++++++++-
>  drivers/hwmon/lm85.c     |    2 ++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85
> index 7c49fea..04cc342 100644
> --- a/Documentation/hwmon/lm85
> +++ b/Documentation/hwmon/lm85
> @@ -34,6 +34,10 @@ Supported chips:
>      Prefix: 'emc6d103s'
>      Addresses scanned: I2C 0x2c, 0x2d, 0x2e
>      Datasheet: http://www.smsc.com/main/catalog/emc6d103s.html
> +  * SMSC EMC2300
> +    Prefix: 'emc6d103s'
> +    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
> +    Datasheet: http://www.smsc.com/media/Downloads_Public/Data_Sheets/2300.pdf
>  
>  Authors:
>          Philip Pokorny <ppokorny@penguincomputing.com>,
> @@ -47,7 +51,7 @@ Description
>  
>  This driver implements support for the National Semiconductor LM85 and
>  compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
> -SMSC EMC6D10x chips family.
> +SMSC EMC6D10x and EMC2300 chips family.
>  
>  The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
>  specification. Using an analog to digital converter it measures three (3)
> @@ -136,6 +140,10 @@ of voltage and temperature channels.
>  SMSC EMC6D103S is similar to EMC6D103, but does not support pwm#_auto_pwm_minctl
>  and temp#_auto_temp_off.
>  
> +SMSC EMC2300 is similar to EMC6D103S, with fewer voltage inputs.
> +Unfortunately it is not possible to distinguish between these two on a register
> +level so EMC2300's voltage inputs in0, in3 and in4 will read zero.
> +
>  Hardware Configurations
>  -----------------------
>  
> diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
> index da72dc1..4b89b70 100644
> --- a/drivers/hwmon/lm85.c
> +++ b/drivers/hwmon/lm85.c
> @@ -1260,6 +1260,8 @@ static int lm85_detect(struct i2c_client *client, struct i2c_board_info *info)
>  			type_name = "emc6d103";
>  			break;
>  		case LM85_VERSTEP_EMC6D103S:
> +			/* Note: this also matches EMC2300, we can't tell
> +			 * the difference between the two */
>  			type_name = "emc6d103s";
>  			break;
>  		}

This looks good, if there's really no way to differentiate between
those two. We used a heuristic to differentiate between the LM96000
(supported) and the WPCD377I (unsupported), see function lm85_is_fake
in the driver source. Maybe we can do something similar for the EMC2300
(although I agree it is less critical here, as both chips are supported
by the driver.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Guenter Roeck]

On Tue, 2011-05-10 at 10:58 -0400, Jean Delvare wrote:
> Hi Steve,
> 
> On Tue, 10 May 2011 15:21:28 +0100, Steve Glendinning wrote:
> > The recently added support for EMC6D103S also supports EMC2300.
> > These two devices report exactly the same revision/stepping
> > register, so it's not possible to tell them apart.
> 
> Thanks for your contribution, this is very appreciated.
> 
> > EMC2300 doesn't have all the voltage inputs that EMC6D103S has,
> > so reports in0, in3 and in4 all as zero.
> 
> Wouldn't this be good way to differentiate between the parts? What
> values are returned by the EMC2300 for registers 0x20, 0x23, 0x24,
> 0x44, 0x45, 0x4a, 0x4b 0x4c and 0x4d?
> 
> BTW, if you could provide a register dump for the EMC2300 (using the
> i2c-dev kernel driver and i2cdump tool from the i2c-tools package) that
> would be appreciated.
> 
> > 
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
> > ---
> >  Documentation/hwmon/lm85 |   10 +++++++++-
> >  drivers/hwmon/lm85.c     |    2 ++
> >  2 files changed, 11 insertions(+), 1 deletions(-)
> > 
> > diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85
> > index 7c49fea..04cc342 100644
> > --- a/Documentation/hwmon/lm85
> > +++ b/Documentation/hwmon/lm85
> > @@ -34,6 +34,10 @@ Supported chips:
> >      Prefix: 'emc6d103s'
> >      Addresses scanned: I2C 0x2c, 0x2d, 0x2e
> >      Datasheet: http://www.smsc.com/main/catalog/emc6d103s.html
> > +  * SMSC EMC2300
> > +    Prefix: 'emc6d103s'
> > +    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
> > +    Datasheet: http://www.smsc.com/media/Downloads_Public/Data_Sheets/2300.pdf
> >  
> >  Authors:
> >          Philip Pokorny <ppokorny@penguincomputing.com>,
> > @@ -47,7 +51,7 @@ Description
> >  
> >  This driver implements support for the National Semiconductor LM85 and
> >  compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
> > -SMSC EMC6D10x chips family.
> > +SMSC EMC6D10x and EMC2300 chips family.
> >  
> >  The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
> >  specification. Using an analog to digital converter it measures three (3)
> > @@ -136,6 +140,10 @@ of voltage and temperature channels.
> >  SMSC EMC6D103S is similar to EMC6D103, but does not support pwm#_auto_pwm_minctl
> >  and temp#_auto_temp_off.
> >  
> > +SMSC EMC2300 is similar to EMC6D103S, with fewer voltage inputs.
> > +Unfortunately it is not possible to distinguish between these two on a register
> > +level so EMC2300's voltage inputs in0, in3 and in4 will read zero.
> > +
> >  Hardware Configurations
> >  -----------------------
> >  
> > diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
> > index da72dc1..4b89b70 100644
> > --- a/drivers/hwmon/lm85.c
> > +++ b/drivers/hwmon/lm85.c
> > @@ -1260,6 +1260,8 @@ static int lm85_detect(struct i2c_client *client, struct i2c_board_info *info)
> >  			type_name = "emc6d103";
> >  			break;
> >  		case LM85_VERSTEP_EMC6D103S:
> > +			/* Note: this also matches EMC2300, we can't tell
> > +			 * the difference between the two */
> >  			type_name = "emc6d103s";
> >  			break;
> >  		}
> 
> This looks good, if there's really no way to differentiate between
> those two. We used a heuristic to differentiate between the LM96000
> (supported) and the WPCD377I (unsupported), see function lm85_is_fake
> in the driver source. Maybe we can do something similar for the EMC2300
> (although I agree it is less critical here, as both chips are supported
> by the driver.)
> 
Datasheet says that 0x20, 0x23, 0x24, 0x43..0x45, and 0x4a..0x4d are all
zero on the EMC2300. Most interesting would be 0x45, 0x4b, and 0x4d,
which are initialized with 0x00 on the EMC2300 but 0xff for the
EMC6D103S.

I don't mind if we accept the code as-is for now, though I would prefer
detection and correct handling of emc2300. But that can also be added
later on. 

I think the text above should not claim that it is not possible to
distinguish between the two chips, or it should be amended with "...
using the Manufacturer/Version registers".

Guenter



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Steve.Glendinning]

[-- Attachment #1: Type: text/html, Size: 2166 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Steve.Glendinning]

--=_mixed 002E5EC6C125788E_MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Hi Jean,<BR><DIV><BR>&gt;&gt;&gt;&nbsp;BTW,&nbsp;if&nbsp;you&nbsp;could&nbsp;provide&nbsp;a&nbsp;register&nbsp;dump&nbsp;for&nbsp;the&nbsp;EMC2300&nbsp;(using <BR>&gt;&gt;the&nbsp; <BR>&gt;&gt;&gt;&nbsp;i2c-dev&nbsp;kernel&nbsp;driver&nbsp;and&nbsp;i2cdump&nbsp;tool&nbsp;from&nbsp;the&nbsp;i2c-tools<BR>&gt;package) <BR>&gt;&gt;that&nbsp; <BR>&gt;&gt;&gt;&nbsp;would&nbsp;be&nbsp;appreciated.&nbsp; <BR></DIV><DIV>Dump as requested:</DIV><DIV>&nbsp;</DIV><DIV><A href="mailto:ste@mustafa:~$" target=blank>ste@mustafa:~$</A> sudo i2cdump 3 0x2e b<BR>WARNING! This program can confuse your I2C bus, cause data loss and worse!<BR>I will probe file /dev/i2c-3, address 0x2e, mode byte<BR>Continue? [Y/n] <BR>&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp; 1&nbsp; 2&nbsp; 3&nbsp; 4&nbsp; 5&nbsp; 6&nbsp; 7&nbsp; 8&nbsp; 9&nbsp; a&nbsp; b&nbsp; c&nbsp; d&nbsp; e&nbsp; f&nbsp;&nbsp;&nbsp; 0123456789abcdef<BR>00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>20: bf ff ff ff ff ff 00 ff dd 02 ff ff ff ff ff ff&nbsp;&nbsp;&nbsp; ?.......??......<BR>30: ff ff ff 00 00 00 00 00 00 00 00 00 00 00 5c 6a&nbsp;&nbsp;&nbsp; ..............\j<BR>40: 04 00 00 00 00 ff 00 ff 00 ff 00 ff 00 ff 81 7f&nbsp;&nbsp;&nbsp; ?.............??<BR>50: 81 7f 81 7f ff ff ff ff ff ff ff ff 62 62 62 c3&nbsp;&nbsp;&nbsp; ????........bbb?<BR>60: c3 c3 e0 00 80 80 80 80 80 80 64 64 64 44 40 00&nbsp;&nbsp;&nbsp; ???.??????dddD@.<BR>70: ff ff ff 09 09 09 09 07 07 00 00 00 40 00 ec 10&nbsp;&nbsp;&nbsp; ...??????...@.??<BR>80: 1e a4 0e 00 00 ff ff ff ff 03 57 57 0b 0b 0b 00&nbsp;&nbsp;&nbsp; ???......?WW???.<BR>90: 04 04 04 04 0c 0c 0c 5a f1 00 00 00 23 00 00 00&nbsp;&nbsp;&nbsp; ???????Z?...#...<BR>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................</DIV><DIV>&nbsp;</DIV><DIV>&nbsp;</DIV><DIV>Steve</DIV></DIV></FONT>
--=_mixed 002E5EC6C125788E_Content-Type: application/octet-stream; name="i2cdump.txt"
Content-Disposition: attachment; filename="i2cdump.txt"
Content-Transfer-Encoding: base64

c3RlQG11c3RhZmE6fiQgc3VkbyBpMmNkdW1wIDMgMHgyZSBiCldBUk5JTkchIFRoaXMgcHJvZ3Jh
bSBjYW4gY29uZnVzZSB5b3VyIEkyQyBidXMsIGNhdXNlIGRhdGEgbG9zcyBhbmQgd29yc2UhCkkg
d2lsbCBwcm9iZSBmaWxlIC9kZXYvaTJjLTMsIGFkZHJlc3MgMHgyZSwgbW9kZSBieXRlCkNvbnRp
bnVlPyBbWS9uXSAKICAgICAwICAxICAyICAzICA0ICA1ICA2ICA3ICA4ICA5ICBhICBiICBjICBk
ICBlICBmICAgIDAxMjM0NTY3ODlhYmNkZWYKMDA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4uLi4uLi4uLi4KMTA6IDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4uLi4uLi4uLi4K
MjA6IGJmIGZmIGZmIGZmIGZmIGZmIDAwIGZmIGRkIDAyIGZmIGZmIGZmIGZmIGZmIGZmICAgID8u
Li4uLi4uPz8uLi4uLi4KMzA6IGZmIGZmIGZmIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDVjIDZhICAgIC4uLi4uLi4uLi4uLi4uXGoKNDA6IDA0IDAwIDAwIDAwIDAwIGZmIDAwIGZm
IDAwIGZmIDAwIGZmIDAwIGZmIDgxIDdmICAgID8uLi4uLi4uLi4uLi4uPz8KNTA6IDgxIDdmIDgx
IDdmIGZmIGZmIGZmIGZmIGZmIGZmIGZmIGZmIDYyIDYyIDYyIGMzICAgID8/Pz8uLi4uLi4uLmJi
Yj8KNjA6IGMzIGMzIGUwIDAwIDgwIDgwIDgwIDgwIDgwIDgwIDY0IDY0IDY0IDQ0IDQwIDAwICAg
ID8/Py4/Pz8/Pz9kZGREQC4KNzA6IGZmIGZmIGZmIDA5IDA5IDA5IDA5IDA3IDA3IDAwIDAwIDAw
IDQwIDAwIGVjIDEwICAgIC4uLj8/Pz8/Py4uLkAuPz8KODA6IDFlIGE0IDBlIDAwIDAwIGZmIGZm
IGZmIGZmIDAzIDU3IDU3IDBiIDBiIDBiIDAwICAgID8/Py4uLi4uLj9XVz8/Py4KOTA6IDA0IDA0
IDA0IDA0IDBjIDBjIDBjIDVhIGYxIDAwIDAwIDAwIDIzIDAwIDAwIDAwICAgID8/Pz8/Pz9aPy4u
LiMuLi4KYTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
ICAgIC4uLi4uLi4uLi4uLi4uLi4KYjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4uLi4uLi4uLi4KYzA6IDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4uLi4uLi4uLi4KZDA6IDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4u
Li4uLi4uLi4KZTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwICAgIC4uLi4uLi4uLi4uLi4uLi4KZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwICAgIC4uLi4uLi4uLi4uLi4uLi4KCg=

--=_mixed 002E5EC6C125788E_Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
--=_mixed 002E5EC6C125788E_=--

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Jean Delvare]

Hi Steve, Guenter,

On Wed, 11 May 2011 20:53:59 +0200, Steve.Glendinning@smsc.com wrote:
> Hi all,
>  
> >Datasheet says that 0x20, 0x23, 0x24, 0x43..0x45, and 0x4a..0x4d are
> >all
> >zero on the EMC2300. Most interesting would be 0x45, 0x4b, and 0x4d,
> >which are initialized with 0x00 on the EMC2300 but 0xff for the
> >EMC6D103S.
> The datasheet lies :-)
>  
> They return the same as the EMC6D103S, i.e. 0xff for 0x45, 0x4b, and 0x4d.

0x43 is somewhat interesting. It corresponds to the VID pins the
EMC2300 doesn't have, so this register will always return zero for the
EMC2300. Unfortunately, most recent systems don't use the VID pins anyway 

> >> > EMC2300 doesn't have all the voltage inputs that EMC6D103S has,
> >> > so reports in0, in3 and in4 all as zero.
> >> 
> >> Wouldn't this be good way to differentiate between the parts? What
> >> values are returned by the EMC2300 for registers 0x20, 0x23, 0x24,
> >> 0x44, 0x45, 0x4a, 0x4b 0x4c and 0x4d?
> I thought of this, yes the missing voltage inputs all always return 0.

This isn't what the dump you just sent shows:

> 20: bf ff ff ff ff ff 00 ff dd 02 ff ff ff ff ff ff    ?.......??......

Values are 0xbf, 0xff and 0xff respectively for registers 0x20, 0x23
and 0x24. 0xbf is odd.

More surprisingly, register 0x22, which contains the voltage of the
monitoring chip itself, reads 0xff... Ah, I get it. On this dump,
monitoring isn't enabled (bit 0 of register 0x40 is 0).

Steve, can you please enable monitoring and provide a new dump?

# modprobe i2c-dev
# i2cset -m 0x01 3 0x2e 0x40 0x01 b
# sleep 1
# i2cdump 3 0x2e b

This means that we can't differentiate between EMC6D103S and EMC2300
before monitoring is started. D'oh. So I'll commit your sensors-detect
patch right away, as we can't enable the chip there, so your patch it
the best we can have there (and we don't need anything better anyway -
both chips are supported by the same driver.)

>  I don't have an EMC6D103S handy though, so I'm not able to check its behaviour if those pins are either not connected or connected to ground.  Presumably it could also return 0 in some cases so the detection would not be 100% foolproof?

Correct, but OTOH, if inputs are grounded or unconnected, users won't
care about them, will they? I think there is value in not exporting
channels which do not exist, to make configuration easier for the user
(and make runtime somewhat more efficient.) The downside is more
complex code in the lm85 driver.

> I figured the safe option was to leave the extra inputs visible, as I didn't want to risk blocking access to them on parts where they're present.

This is certainly the easiest option. There's indeed a risk in trying
to refine the detection and we won't do it if that can't be done
reliably. But my main concern at this point is the increased driver
complexity.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Guenter Roeck]

Hi,

On Thu, May 12, 2011 at 05:34:21AM -0400, Jean Delvare wrote:
> Hi Steve, Guenter,
> 
> On Wed, 11 May 2011 20:53:59 +0200, Steve.Glendinning@smsc.com wrote:
> > Hi all,
> >  
> > >Datasheet says that 0x20, 0x23, 0x24, 0x43..0x45, and 0x4a..0x4d are
> > >all
> > >zero on the EMC2300. Most interesting would be 0x45, 0x4b, and 0x4d,
> > >which are initialized with 0x00 on the EMC2300 but 0xff for the
> > >EMC6D103S.
> > The datasheet lies :-)
> >  
> > They return the same as the EMC6D103S, i.e. 0xff for 0x45, 0x4b, and 0x4d.
> 
> 0x43 is somewhat interesting. It corresponds to the VID pins the
> EMC2300 doesn't have, so this register will always return zero for the
> EMC2300. Unfortunately, most recent systems don't use the VID pins anyway 
> 
> > >> > EMC2300 doesn't have all the voltage inputs that EMC6D103S has,
> > >> > so reports in0, in3 and in4 all as zero.
> > >> 
> > >> Wouldn't this be good way to differentiate between the parts? What
> > >> values are returned by the EMC2300 for registers 0x20, 0x23, 0x24,
> > >> 0x44, 0x45, 0x4a, 0x4b 0x4c and 0x4d?
> > I thought of this, yes the missing voltage inputs all always return 0.
> 
> This isn't what the dump you just sent shows:
> 
> > 20: bf ff ff ff ff ff 00 ff dd 02 ff ff ff ff ff ff    ?.......??......
> 
> Values are 0xbf, 0xff and 0xff respectively for registers 0x20, 0x23
> and 0x24. 0xbf is odd.
> 
> More surprisingly, register 0x22, which contains the voltage of the
> monitoring chip itself, reads 0xff... Ah, I get it. On this dump,
> monitoring isn't enabled (bit 0 of register 0x40 is 0).
> 
> Steve, can you please enable monitoring and provide a new dump?
> 
> # modprobe i2c-dev
> # i2cset -m 0x01 3 0x2e 0x40 0x01 b
> # sleep 1
> # i2cdump 3 0x2e b
> 
> This means that we can't differentiate between EMC6D103S and EMC2300
> before monitoring is started. D'oh. So I'll commit your sensors-detect
> patch right away, as we can't enable the chip there, so your patch it
> the best we can have there (and we don't need anything better anyway -
> both chips are supported by the same driver.)
> 
> >  I don't have an EMC6D103S handy though, so I'm not able to check its behaviour if those pins are either not connected or connected to ground.  Presumably it could also return 0 in some cases so the detection would not be 100% foolproof?
> 
> Correct, but OTOH, if inputs are grounded or unconnected, users won't
> care about them, will they? I think there is value in not exporting
> channels which do not exist, to make configuration easier for the user
> (and make runtime somewhat more efficient.) The downside is more
> complex code in the lm85 driver.
> 
> > I figured the safe option was to leave the extra inputs visible, as I didn't want to risk blocking access to them on parts where they're present.
> 
> This is certainly the easiest option. There's indeed a risk in trying
> to refine the detection and we won't do it if that can't be done
> reliably. But my main concern at this point is the increased driver
> complexity.
> 
I suspect that the EMC2300 has the same chip core as the EMC6D103S
with different pinout. Given that, and the complexity of driver changes
necessary to deal with the unsupported sensors, maybe the original patch 
is the best way to go after all.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] Document existing support for SMSC EMC2300

[Steve.Glendinning]

--=_mixed 004763B6C125788F_MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Hi Jean,<BR><DIV>&nbsp;</DIV><DIV>&gt;Ah,&nbsp;I&nbsp;get&nbsp;it.&nbsp;On&nbsp;this&nbsp;dump, <BR>&gt;monitoring&nbsp;isn't&nbsp;enabled&nbsp;(bit&nbsp;0&nbsp;of&nbsp;register&nbsp;0x40&nbsp;is&nbsp;0). <BR>&gt; <BR>&gt;Steve,&nbsp;can&nbsp;you&nbsp;please&nbsp;enable&nbsp;monitoring&nbsp;and&nbsp;provide&nbsp;a&nbsp;new&nbsp;dump? <BR></DIV><DIV>Sorry!&nbsp; Hopefully this one is more useful:</DIV><DIV>&nbsp;</DIV><DIV><A href="mailto:root@mustafa" target=blank>root@mustafa</A>:~# i2cdump 3 0x2e b<BR>WARNING! This program can confuse your I2C bus, cause data loss and worse!<BR>I will probe file /dev/i2c-3, address 0x2e, mode byte<BR>Continue? [Y/n] <BR>&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp; 1&nbsp; 2&nbsp; 3&nbsp; 4&nbsp; 5&nbsp; 6&nbsp; 7&nbsp; 8&nbsp; 9&nbsp; a&nbsp; b&nbsp; c&nbsp; d&nbsp; e&nbsp; f&nbsp;&nbsp;&nbsp; 0123456789abcdef<BR>00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>20: 00 92 c2 00 00 17 18 17 07 03 ff ff ff ff ff ff&nbsp;&nbsp;&nbsp; .??..?????......<BR>30: ff ff ff 00 00 00 00 00 00 00 00 00 00 00 5c 6a&nbsp;&nbsp;&nbsp; ..............\j<BR>40: 05 89 01 00 00 ff 00 ff 00 ff 00 ff 00 ff 81 7f&nbsp;&nbsp;&nbsp; ???...........??<BR>50: 81 7f 81 7f ff ff ff ff ff ff ff ff 62 62 62 c3&nbsp;&nbsp;&nbsp; ????........bbb?<BR>60: c3 c3 e0 00 80 80 80 80 80 80 64 64 64 44 40 00&nbsp;&nbsp;&nbsp; ???.??????dddD@.<BR>70: ff ff ff 09 09 09 09 07 07 00 30 00 40 00 ec 10&nbsp;&nbsp;&nbsp; ...??????.0.@.??<BR>80: 1e a4 0e 00 00 08 03 00 35 00 57 57 0b 0b 0c 00&nbsp;&nbsp;&nbsp; ???..??.5.WW???.<BR>90: 04 04 04 04 0c 0c 0c 5a f1 00 00 00 23 00 00 00&nbsp;&nbsp;&nbsp; ???????Z?...#...<BR>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................<BR>f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp;&nbsp;&nbsp; ................</DIV><DIV>&nbsp;</DIV><DIV>Steve</DIV></DIV></FONT>
--=_mixed 004763B6C125788F_Content-Type: application/octet-stream; name="i2cdump-active.txt"
Content-Disposition: attachment; filename="i2cdump-active.txt"
Content-Transfer-Encoding: base64

cm9vdEBtdXN0YWZhOn4jIGkyY2R1bXAgMyAweDJlIGIKV0FSTklORyEgVGhpcyBwcm9ncmFtIGNh
biBjb25mdXNlIHlvdXIgSTJDIGJ1cywgY2F1c2UgZGF0YSBsb3NzIGFuZCB3b3JzZSEKSSB3aWxs
IHByb2JlIGZpbGUgL2Rldi9pMmMtMywgYWRkcmVzcyAweDJlLCBtb2RlIGJ5dGUKQ29udGludWU/
IFtZL25dIAogICAgIDAgIDEgIDIgIDMgIDQgIDUgIDYgIDcgIDggIDkgIGEgIGIgIGMgIGQgIGUg
IGYgICAgMDEyMzQ1Njc4OWFiY2RlZgowMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4uLi4uLgoxMDogMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4uLi4uLgoyMDog
MDAgOTIgYzIgMDAgMDAgMTcgMTggMTcgMDcgMDMgZmYgZmYgZmYgZmYgZmYgZmYgICAgLj8/Li4/
Pz8/Py4uLi4uLgozMDogZmYgZmYgZmYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
NWMgNmEgICAgLi4uLi4uLi4uLi4uLi5cago0MDogMDUgODkgMDEgMDAgMDAgZmYgMDAgZmYgMDAg
ZmYgMDAgZmYgMDAgZmYgODEgN2YgICAgPz8/Li4uLi4uLi4uLi4/Pwo1MDogODEgN2YgODEgN2Yg
ZmYgZmYgZmYgZmYgZmYgZmYgZmYgZmYgNjIgNjIgNjIgYzMgICAgPz8/Py4uLi4uLi4uYmJiPwo2
MDogYzMgYzMgZTAgMDAgODAgODAgODAgODAgODAgODAgNjQgNjQgNjQgNDQgNDAgMDAgICAgPz8/
Lj8/Pz8/P2RkZERALgo3MDogZmYgZmYgZmYgMDkgMDkgMDkgMDkgMDcgMDcgMDAgMzAgMDAgNDAg
MDAgZWMgMTAgICAgLi4uPz8/Pz8/LjAuQC4/Pwo4MDogMWUgYTQgMGUgMDAgMDAgMDggMDMgMDAg
MzUgMDAgNTcgNTcgMGIgMGIgMGMgMDAgICAgPz8/Li4/Py41LldXPz8/Lgo5MDogMDQgMDQgMDQg
MDQgMGMgMGMgMGMgNWEgZjEgMDAgMDAgMDAgMjMgMDAgMDAgMDAgICAgPz8/Pz8/P1o/Li4uIy4u
LgphMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAg
Li4uLi4uLi4uLi4uLi4uLgpiMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4uLi4uLgpjMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4uLi4uLgpkMDogMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4u
Li4uLgplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
ICAgLi4uLi4uLi4uLi4uLi4uLgpmMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgICAgLi4uLi4uLi4uLi4uLi4uLgoK

--=_mixed 004763B6C125788F_Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
--=_mixed 004763B6C125788F_=--