[lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Juerg Haefliger]

All,

I looked through a lot of SMSC datasheets the last couple of days with
the goal to improve sensor-detect to correctly identify more SMSC
Super I/Os. I noticed that some of the chips don't conform to the ISA
PNP standard with the device ID register living at a different address
(0x0d instead of 0x20). In order to correctly identify those chips, a
somewhat ugly (and totally SMSC specific) hack would be necessary.
Something like reading from both addresses and then using the value
from 0x0d for some of the SMSC chips.

I wonder how much value this adds given that none of these Super IOs
have HW monitoring capabilities? The only benefit I can see is that
the chip is correctly identified and we can flag it as not being a
sensor and thus users won't bug us for adding support.

Any thoughts, comments, ideas?

Thanks
...juerg

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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Hans de Goede]

Juerg Haefliger wrote:
 > All,
 >
 > I looked through a lot of SMSC datasheets the last couple of days with
 > the goal to improve sensor-detect to correctly identify more SMSC
 > Super I/Os. I noticed that some of the chips don't conform to the ISA
 > PNP standard with the device ID register living at a different address
 > (0x0d instead of 0x20). In order to correctly identify those chips, a
 > somewhat ugly (and totally SMSC specific) hack would be necessary.
 > Something like reading from both addresses and then using the value
 > from 0x0d for some of the SMSC chips.
 >
 > I wonder how much value this adds given that none of these Super IOs
 > have HW monitoring capabilities? The only benefit I can see is that
 > the chip is correctly identified and we can flag it as not being a
 > sensor and thus users won't bug us for adding support.
 >
 > Any thoughts, comments, ideas?
 >

I think that if the hack isn't too gross, it would be good to also be able to 
identify those chips.

Regards,

Hans


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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Jean Delvare]

On Mon, 11 Jun 2007 21:54:50 +0200, Hans de Goede wrote:
> Juerg Haefliger wrote:
>  > All,
>  >
>  > I looked through a lot of SMSC datasheets the last couple of days with
>  > the goal to improve sensor-detect to correctly identify more SMSC
>  > Super I/Os. I noticed that some of the chips don't conform to the ISA
>  > PNP standard with the device ID register living at a different address
>  > (0x0d instead of 0x20). In order to correctly identify those chips, a
>  > somewhat ugly (and totally SMSC specific) hack would be necessary.
>  > Something like reading from both addresses and then using the value
>  > from 0x0d for some of the SMSC chips.
>  >
>  > I wonder how much value this adds given that none of these Super IOs
>  > have HW monitoring capabilities? The only benefit I can see is that
>  > the chip is correctly identified and we can flag it as not being a
>  > sensor and thus users won't bug us for adding support.
>  >
>  > Any thoughts, comments, ideas?
>  >
> 
> I think that if the hack isn't too gross, it would be good to also be able to 
> identify those chips.

Same for me, it depends on how the code looks like. If it's clean and
safe, no objection.

I am curious how you can tell between the two types of register
mappings? Is there a perfect solution, or do you have some heuristic?

-- 
Jean Delvare

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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Juerg Haefliger]

On 6/12/07, Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 11 Jun 2007 21:54:50 +0200, Hans de Goede wrote:
> > Juerg Haefliger wrote:
> >  > All,
> >  >
> >  > I looked through a lot of SMSC datasheets the last couple of days with
> >  > the goal to improve sensor-detect to correctly identify more SMSC
> >  > Super I/Os. I noticed that some of the chips don't conform to the ISA
> >  > PNP standard with the device ID register living at a different address
> >  > (0x0d instead of 0x20). In order to correctly identify those chips, a
> >  > somewhat ugly (and totally SMSC specific) hack would be necessary.
> >  > Something like reading from both addresses and then using the value
> >  > from 0x0d for some of the SMSC chips.
> >  >
> >  > I wonder how much value this adds given that none of these Super IOs
> >  > have HW monitoring capabilities? The only benefit I can see is that
> >  > the chip is correctly identified and we can flag it as not being a
> >  > sensor and thus users won't bug us for adding support.
> >  >
> >  > Any thoughts, comments, ideas?
> >  >
> >
> > I think that if the hack isn't too gross, it would be good to also be able to
> > identify those chips.
>
> Same for me, it depends on how the code looks like. If it's clean and
> safe, no objection.
>
> I am curious how you can tell between the two types of register
> mappings? Is there a perfect solution, or do you have some heuristic?

I can't tell. It's arbitrary. Some of these chips have the LPC base
address (0x2e/0x4e) in register 0x12 but not all of them of course.
SMSC doesn't make it easy for us...

Anyways, below is a first shot. Let me know what you think, I'm sure
it has room for improvements :-)

...juerg



--- lm-sensors.orig/prog/detect/sensors-detect	2007-06-13
08:18:39.981298000 -0700
+++ lm-sensors/prog/detect/sensors-detect	2007-06-14 12:18:33.759404000 -0700
@@ -1831,6 +1831,20 @@ use vars qw(@chip_kern24_ids @chip_kern2
 	driver => "via-smbus-only",
 	devid => 0x77,
       },
+      {
+	name => "SMSC LPC47N227 Super IO",
+	driver => "not-a-sensor",
+	devid => 0x5a,
+	# Non-standard device ID register address
+	devidreg => 0x0d,
+      },
+      {
+	name => "SMSC FDC37N769 Super IO",
+	driver => "not-a-sensor",
+	devid => 0x28,
+	# Non-standard device ID register address
+	devidreg => 0x0d,
+      },
     ],
   },
   {
@@ -3193,6 +3207,7 @@ sub scan_superio
 {
   my ($addrreg, $datareg) = @_;
   my ($val, $found);
+  my (%devid, $reg, $chip);

   printf("Probing for Super-I/O at 0x\%x/0x\%x\n", $addrreg, $datareg);

@@ -3206,28 +3221,54 @@ sub scan_superio
     foreach $val (@{$family->{enter}->{$addrreg}}) {
       outb($addrreg, $val);
     }
-# did it work?
-    outb($addrreg, $superio{devidreg});
-    $val = inb($datareg);
-    outb($addrreg, $superio{devidreg} + 1);
-    $val = ($val << 8) | inb($datareg);
-    if ($val = 0x0000 || $val = 0xffff) {
-      print "No\n";
-      next FAMILY;
+# assemble all possible devid registers for this family
+    foreach $chip (\%superio, @{$family->{chips}}) {
+	if ($chip->{devidreg}) {
+	    $devid{$chip->{devidreg}} = 0;
+	}
+    }
+# read devid registers
+    foreach $reg (keys %devid) {
+	outb($addrreg, $reg);
+	$val = inb($datareg);
+	outb($addrreg, $reg + 1);
+	$val = ($val << 8) | inb($datareg);
+	if ($val = 0x0000 || $val = 0xffff) {
+	    delete $devid{$reg};
+	} else {
+	    $devid{$reg} = $val;
+	}
+    }
+    if (!%devid) {
+	print "No\n";
+	next FAMILY;
     }
     print "Yes\n";

     $found = 0;
-    foreach my $chip (@{$family->{chips}}) {
-      if (($chip->{devid} > 0xff && ($val & ($chip->{devid_mask} ||
0xffff)) = $chip->{devid})
-       || ($chip->{devid} <= 0xff && ($val >> 8) = $chip->{devid})) {
-        probe_superio($addrreg, $datareg, $chip);
-        $found++;
-      }
+    foreach $chip (@{$family->{chips}}) {
+	foreach $reg (keys %devid) {
+	    $val = $devid{$reg};
+	    if (($chip->{devid} > 0xff &&
+		 ($val & ($chip->{devid_mask} || 0xffff)) = $chip->{devid}) ||
+		($chip->{devid} <= 0xff && ($val >> 8) = $chip->{devid})) {
+		probe_superio($addrreg, $datareg, $chip);
+		$found++;
+	    }
+	}
     }

     if (!$found) {
-      printf("Found unknown chip with ID 0x%04x\n", $val);
+	if (scalar(keys %devid) = 1 && $devid{$superio{devidreg}}) {
+	    printf("Found unknown chip with ID 0x%04x\n",
+		   $devid{$superio{devidreg}});
+	} else {
+	    printf("Found unknown chip with possible IDs ");
+	    foreach $reg (keys %devid) {
+		printf("0x%04x(0x%02x) ", $devid{$reg}, $reg);
+	    }
+	    printf("\n");
+	}
       # Guess if a logical device could correspond to sensors
       guess_superio_ld($addrreg, $datareg, $family->{guess})
         if defined $family->{guess};

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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Jean Delvare]

Hi Juerg,

On Thu, 14 Jun 2007 12:26:25 -0700, Juerg Haefliger wrote:
> On 6/12/07, Jean Delvare <khali@linux-fr.org> wrote:
> > Same for me, it depends on how the code looks like. If it's clean and
> > safe, no objection.
> >
> > I am curious how you can tell between the two types of register
> > mappings? Is there a perfect solution, or do you have some heuristic?
> 
> I can't tell. It's arbitrary. Some of these chips have the LPC base
> address (0x2e/0x4e) in register 0x12 but not all of them of course.
> SMSC doesn't make it easy for us...

OTOH, standard LPC chips don't have anything at 0x0d (a read will
return 0xff, or possibly 0x00?) so you should be able to tell standard
chips from non-standard ones that way.

> Anyways, below is a first shot. Let me know what you think, I'm sure
> it has room for improvements :-)

First of all, an improvement would be if your e-mail client didn't fold
long lines...

For the code, it's way more complex than I hoped it would be. You went
for a generic solution, which I agree is a good idea in general, but
maybe not in this case. We don't know if other chip manufacturers will
diverge from the standard, nor how they will diverge if they do. And we
don't know if any of these non-SMSC chips has sensors. So I think I
would prefer less intrusive SMSC-specific code as long as we don't need
more.

More specifically, we could add an optional callback function for each
family, which would be called before the standard detection for this
family. Depending on the return value of this callback, the standard
processing would be applied or skipped for this family. So, in the case
of these SMSC chips, the callback would read from 0x0d, and if the
value is neither 0xff nor 0x00, a separate list of known non-standard
SMSC chips would be processed, and standard processing would be skipped.

What do you think?

-- 
Jean Delvare

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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Juerg Haefliger]

On 6/16/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Juerg,
>
> On Thu, 14 Jun 2007 12:26:25 -0700, Juerg Haefliger wrote:
> > On 6/12/07, Jean Delvare <khali@linux-fr.org> wrote:
> > > Same for me, it depends on how the code looks like. If it's clean and
> > > safe, no objection.
> > >
> > > I am curious how you can tell between the two types of register
> > > mappings? Is there a perfect solution, or do you have some heuristic?
> >
> > I can't tell. It's arbitrary. Some of these chips have the LPC base
> > address (0x2e/0x4e) in register 0x12 but not all of them of course.
> > SMSC doesn't make it easy for us...
>
> OTOH, standard LPC chips don't have anything at 0x0d (a read will
> return 0xff, or possibly 0x00?) so you should be able to tell standard
> chips from non-standard ones that way.

Is that true for all standard LPC chips? The ISA PNP spec just list
this address as part of a reserved card-level address range.


> > Anyways, below is a first shot. Let me know what you think, I'm sure
> > it has room for improvements :-)
>
> First of all, an improvement would be if your e-mail client didn't fold
> long lines...

Ah ja, sorry. Will attach patches in the future...


> For the code, it's way more complex than I hoped it would be. You went
> for a generic solution, which I agree is a good idea in general, but
> maybe not in this case. We don't know if other chip manufacturers will
> diverge from the standard, nor how they will diverge if they do. And we
> don't know if any of these non-SMSC chips has sensors. So I think I
> would prefer less intrusive SMSC-specific code as long as we don't need
> more.
>
> More specifically, we could add an optional callback function for each
> family, which would be called before the standard detection for this
> family. Depending on the return value of this callback, the standard
> processing would be applied or skipped for this family. So, in the case
> of these SMSC chips, the callback would read from 0x0d, and if the
> value is neither 0xff nor 0x00, a separate list of known non-standard
> SMSC chips would be processed, and standard processing would be skipped.
>
> What do you think?

Sounds fine. I don't care too much even though I wouldn't call the
changes complex. I'll give it a try and we'll see how complicated
it'll be.

...juerg


> --
> Jean Delvare
>

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

Re: [lm-sensors] sensor-detect and non-compliant SMSC Super I/Os

[Jean Delvare]

Hi Juerg,

On Sun, 17 Jun 2007 20:59:18 -0700, Juerg Haefliger wrote:
> On 6/16/07, Jean Delvare <khali@linux-fr.org> wrote:
> > OTOH, standard LPC chips don't have anything at 0x0d (a read will
> > return 0xff, or possibly 0x00?) so you should be able to tell standard
> > chips from non-standard ones that way.
> 
> Is that true for all standard LPC chips? The ISA PNP spec just list
> this address as part of a reserved card-level address range.

This is my experience at least, and "reserved for future use" in a 1994
specification pretty much means "unused forever", don't you think? ;)

Thanks,
-- 
Jean Delvare

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