[lm-sensors] #2195: Fails to detect ITE family chip with ID

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Juerg Haefliger]

Yes, the chip is a DME1737.
0x3e: 0x5c = SMSC
0x3f: 0x8a = DME1737


Jean: I tried to add the comment to the ticket but get a
'TICKET_APPEND privileges are required to perform this operation'
error. I logged in as user 'ticket'.

...juerg


On 3/21/07, lm-sensors <lm-sensors-notify at lm-sensors.org> wrote:
> #2195: Fails to detect ITE family chip with ID 0x7803
> ---------------------------+------------------------------------------------
>   Reporter:  cc at cs.aau.dk  |       Owner:  khali
>       Type:  enhancement   |      Status:  assigned
>   Priority:  minor         |   Milestone:
>  Component:  hardware      |     Version:  SVN
> Resolution:                |    Keywords:
> ---------------------------+------------------------------------------------
> Changes (by khali):
>
>  * cc: juergh at gmail.com (added)
>
> Comment:
>
>  Juerg, please check this sensors-detect output. The Super-I/O detection
>  finds a DME1737 chip, but the Intel 82801 SMBus probing fails to identify
>  the device at 0x2e as a DME1737.
>
>  Reporter, can you please provide the output of:
>  {{{
>  i2cdump 0 0x2e
>  }}}
>
> --
> Ticket URL: <http://lm-sensors.org/ticket/2195#comment:2>
> lm-sensors <http://lm-sensors.org/>
> Linux hardware monitoring

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Juerg Haefliger]

looking at sensors-detect:

> # $_[0]: A reference to the file descriptor to access this chip.
> # $_[1]: Address
> # Returns: undef if not detected, 5 or 6 if detected.
> # Registers used:
> #   0x3E: Manufacturer ID
> #   0x3F: Version/Stepping
> #   0x40: Configuration (2 reserved bits)
> #   0x42: Interrupt Status 2 (1 reserved bit)
> #   0x43: VID (2 reserved bits)
> sub dme1737_detect
> {
>   my ($file, $addr) = @_;
>   return unless i2c_smbus_read_byte_data($file, 0x3E) = 0x55

this should be 0x5c not 0x55.


>            and (i2c_smbus_read_byte_data($file, 0x3F) & 0xF8) = 0x88
>            and (i2c_smbus_read_byte_data($file, 0x40) & 0xC4) = 0x04
>            and (i2c_smbus_read_byte_data($file, 0x42) & 0x02) = 0x00
>            and (i2c_smbus_read_byte_data($file, 0x43) & 0xC0) = 0x00;

Are the checks of addresses 0x40, 0x42 & 0x43 really necessary?

>   return ($addr = 0x2e ? 6 : 5);
}


...juerg




On 3/22/07, Juerg Haefliger <juergh at gmail.com> wrote:
> Yes, the chip is a DME1737.
> 0x3e: 0x5c = SMSC
> 0x3f: 0x8a = DME1737
>
>
> Jean: I tried to add the comment to the ticket but get a
> 'TICKET_APPEND privileges are required to perform this operation'
> error. I logged in as user 'ticket'.
>
> ...juerg
>
>
> On 3/21/07, lm-sensors <lm-sensors-notify at lm-sensors.org> wrote:
> > #2195: Fails to detect ITE family chip with ID 0x7803
> > ---------------------------+------------------------------------------------
> >   Reporter:  cc at cs.aau.dk  |       Owner:  khali
> >       Type:  enhancement   |      Status:  assigned
> >   Priority:  minor         |   Milestone:
> >  Component:  hardware      |     Version:  SVN
> > Resolution:                |    Keywords:
> > ---------------------------+------------------------------------------------
> > Changes (by khali):
> >
> >  * cc: juergh at gmail.com (added)
> >
> > Comment:
> >
> >  Juerg, please check this sensors-detect output. The Super-I/O detection
> >  finds a DME1737 chip, but the Intel 82801 SMBus probing fails to identify
> >  the device at 0x2e as a DME1737.
> >
> >  Reporter, can you please provide the output of:
> >  {{{
> >  i2cdump 0 0x2e
> >  }}}
> >
> > --
> > Ticket URL: <http://lm-sensors.org/ticket/2195#comment:2>
> > lm-sensors <http://lm-sensors.org/>
> > Linux hardware monitoring
>

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Jean Delvare]

Hi Juerg,

On Thu, 22 Mar 2007 09:38:55 -0700, Juerg Haefliger wrote:
> looking at sensors-detect:
> 
> > # $_[0]: A reference to the file descriptor to access this chip.
> > # $_[1]: Address
> > # Returns: undef if not detected, 5 or 6 if detected.
> > # Registers used:
> > #   0x3E: Manufacturer ID
> > #   0x3F: Version/Stepping
> > #   0x40: Configuration (2 reserved bits)
> > #   0x42: Interrupt Status 2 (1 reserved bit)
> > #   0x43: VID (2 reserved bits)
> > sub dme1737_detect
> > {
> >   my ($file, $addr) = @_;
> >   return unless i2c_smbus_read_byte_data($file, 0x3E) = 0x55
> 
> this should be 0x5c not 0x55.

Correct, I came up to the same conclusion.

> >            and (i2c_smbus_read_byte_data($file, 0x3F) & 0xF8) = 0x88
> >            and (i2c_smbus_read_byte_data($file, 0x40) & 0xC4) = 0x04
> >            and (i2c_smbus_read_byte_data($file, 0x42) & 0x02) = 0x00
> >            and (i2c_smbus_read_byte_data($file, 0x43) & 0xC0) = 0x00;
> 
> Are the checks of addresses 0x40, 0x42 & 0x43 really necessary?
> 
> >   return ($addr = 0x2e ? 6 : 5);
> }

There are no standard registers and no standard values to identify I2C
manufacturers and devices. So adding a few tests where possible cannot
hurt and is considered a good practice. So unless you have a reason to
believe that these tests could fail for an otherwise valid chip, I'd
leave them in. Especially the test of register 0x40 is valuable - the
test of register 0x42 certainly less.

We don't need to do this for Super-I/O or PCI devices because they have
standard identification registers.

Can you please provide a patch fixing sensors-detect for the DME1737?

Thanks,
-- 
Jean Delvare

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Jean Delvare]

On Thu, 22 Mar 2007 09:24:14 -0700, Juerg Haefliger wrote:
> Jean: I tried to add the comment to the ticket but get a
> 'TICKET_APPEND privileges are required to perform this operation'
> error. I logged in as user 'ticket'.

User 'ticket' definitely has permission TICKET_APPEND, I just checked.
So I can't tell you what went wrong, sorry.

We can give you a personal account on the system if you want, though
(for both the wiki and the ticket system.)

-- 
Jean Delvare

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Juerg Haefliger]

Hi Jean,

> There are no standard registers and no standard values to identify I2C
> manufacturers and devices. So adding a few tests where possible cannot
> hurt and is considered a good practice. So unless you have a reason to
> believe that these tests could fail for an otherwise valid chip, I'd
> leave them in. Especially the test of register 0x40 is valuable - the
> test of register 0x42 certainly less.
>
> We don't need to do this for Super-I/O or PCI devices because they have
> standard identification registers.
>
> Can you please provide a patch fixing sensors-detect for the DME1737?

Do you mean just fixing the 0x55?

...juerg


> Thanks,
> --
> Jean Delvare
>

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Jean Delvare]

Juerg,

On Thu, 22 Mar 2007 11:16:03 -0700, Juerg Haefliger wrote:
> > Can you please provide a patch fixing sensors-detect for the DME1737?
> 
> Do you mean just fixing the 0x55?

That and possibly fixing other mistakes I made. You wrote the dme1737
driver, so I assume you have (or have access to) a DME1737 device or
compatible for testing, while I don't.

Thanks,
-- 
Jean Delvare

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Juerg Haefliger]

Hi Jean,

> > > Can you please provide a patch fixing sensors-detect for the DME1737?
> >
> > Do you mean just fixing the 0x55?
>
> That and possibly fixing other mistakes I made. You wrote the dme1737
> driver, so I assume you have (or have access to) a DME1737 device or
> compatible for testing, while I don't.

Ok. Can I roll libsensor/sensors support for the dme1737 into the same
patch or do I need to hold off until the driver is accepted?

...juerg


> Thanks,
> --
> Jean Delvare
>

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Jean Delvare]

On Thu, 22 Mar 2007 12:45:11 -0700, Juerg Haefliger wrote:
> > That and possibly fixing other mistakes I made. You wrote the dme1737
> > driver, so I assume you have (or have access to) a DME1737 device or
> > compatible for testing, while I don't.
> 
> Ok. Can I roll libsensor/sensors support for the dme1737 into the same
> patch or do I need to hold off until the driver is accepted?

I'm fine with a single patch for both, yes.

-- 
Jean Delvare

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Juerg Haefliger]

On 3/22/07, Jean Delvare <khali at linux-fr.org> wrote:
> On Thu, 22 Mar 2007 12:45:11 -0700, Juerg Haefliger wrote:
> > > That and possibly fixing other mistakes I made. You wrote the dme1737
> > > driver, so I assume you have (or have access to) a DME1737 device or
> > > compatible for testing, while I don't.
> >
> > Ok. Can I roll libsensor/sensors support for the dme1737 into the same
> > patch or do I need to hold off until the driver is accepted?
>
> I'm fine with a single patch for both, yes.

OK, started looking at it and noticed 2 things:

1) The ITE superio enter sequence also works for the SMSC, so
sensor-detects reports both an (unknown) ITE and a dme1737 SMSC chip.
I guess there's nothing we can do about this, can we?

2) Even though the datasheet shows a device ID of 0x78 which matches
the sensor-detect output of the ticket reporter, my DME1737 returns
0x77. Should I just add another entry for a DME1737 with dev id 0x77?


...juerg


>
> --
> Jean Delvare
>

[lm-sensors] #2195: Fails to detect ITE family chip with ID

[Jean Delvare]

Hi Juerg,

On Thu, 22 Mar 2007 21:12:25 -0700, Juerg Haefliger wrote:
> 1) The ITE superio enter sequence also works for the SMSC, so
> sensor-detects reports both an (unknown) ITE and a dme1737 SMSC chip.
> I guess there's nothing we can do about this, can we?

We can, and actually I have a local patch fixing it. I am only waiting
for lm-sensors 2.10.3 to be finally released before I commit it. I'm
attaching said patch to this post if you want to take a look and/or
give it a try. Basically, the idea is to test the families from the
shorter enter sequence (actually empty, for the National Semiconductor
chips) to the longer, and to stop as soon as one sequence was found to
work (regardless of whether or not a known chip was found.)

> 2) Even though the datasheet shows a device ID of 0x78 which matches
> the sensor-detect output of the ticket reporter, my DME1737 returns
> 0x77. Should I just add another entry for a DME1737 with dev id 0x77?

Hmm, yes, I guess you'll have to.

[/me rants against manufacturers who can't stick to their own
standards.]

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-detect-superio-family-order.patch
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070323/2f31c496/attachment.pl