I see the following code in winbond.c: ... {0x52f, "W83977EF/EG", { ... /* ID only */ {0x52, "W83627HF/F/HG/G", { {NOLDN, NULL, ... if (devid == 0x52 || devid == 0x68 || devid == 0x88) id = devid; /* ID only */ ...
According to my understanding this means that W83627HF chip entry claims ID 0x52 regardless of revision.
But, on the other hand, I have W83977EF-AW in my system and according to its specification it has ID 0x52 and revision 0xFx. My particular chip has 0x52 and 0xF4 for instance. And with current code its entry (0x52f) is not reachable.
Looking at specification of W83627HF that I found I see that it actually has ID of 0x52 and revision 0x1x.
So while W83627 family of chips may cover a range of revisions for ID 0x52, it doesn't cover them all. And there are some significant differences in registers. For example W83977EF doesn't have logical devices 6, 9 and 0xb.
References: 1. http://www.datasheet4u.com/html/W/8/3/W83977EF-AW_Winbond.pdf.html Section 10.0
2. http://www.datasheet4u.com/html/W/8/3/W83627HF_Winbond.pdf.html Section 13.1
Add register definitions for W83627HF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon avg@icyb.net.ua
---
What about this patch (in addition to my previous question/rant)?
Please note that the last line of the patch simply fixes the comment about internal device id composition (upper half of reg 0x21 is used). I chose the most conservative way of detecting W83627HF - only if reg 0x21 value matches 0xFx we skip the previous logic and keep using it for all other revisions.
Here's an output of patched superiotool on my system, Delta MP2-BX-X:
superiotool r3658 Found Winbond W83977EF/EG (id=0x52, rev=0xf4) at 0x3f0 Register dump: idx 02 20 21 22 23 24 25 26 28 2a 2b 2c 2d 2e 2f val ff 52 f4 ff fe 84 00 00 00 00 00 00 00 00 ff def RR 52 NA ff fe MM 00 MM 00 00 00 00 RR RR RR LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 00 00 00 00 04 0c 00 ff 00 00 def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 00 00 00 00 04 00 def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 01 02 e8 03 00 00 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 40 def 01 00 60 00 64 01 0c 83 LDN 0x07 (GPIO 1) idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 val 01 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 LDN 0x08 (GPIO 2) idx 30 60 61 70 72 e8 e9 ea eb ec ed f0 f1 f2 f3 f4 val 01 00 00 00 00 10 01 01 01 01 08 00 ff 00 00 00 def 00 00 00 00 00 01 01 01 01 01 01 00 RR 00 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff val 00 00 00 00 00 00 00 00 00 00 00 8f 30 00 00 00 00 00 00 def 00 00 00 00 MM MM MM 00 00 00 00 00 00 00 00 00 00 RR RR
On Fri, Oct 17, 2008 at 06:26:52PM +0300, Andriy Gapon wrote:
Add register definitions for W83627HF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon avg@icyb.net.ua
Looks good, thanks! Committed in r3670.
In addition, I've added your name to the list of contributors in the README, and I removed...
Index: winbond.c
--- winbond.c (revision 3667) +++ winbond.c (working copy) @@ -39,7 +39,46 @@ /* ID and rev[3..0] */ {0x527, "W83977CTF", { /* TODO: Not yet in sensors-detect */ {EOT}}},
[...]
{0xa, "ACPI",
/* Note: Datasheet says 0xe2 can't be read/written. */
... this line. It seem to be copy-paste from some other Super I/O, the datasheet for this one doesn't seem to say that 0xe2 cannot be read/written anywhere (or at least I didn't find that place).
{0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},{0x00,0x00,0x00,0x00,MISC,MISC,MISC,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,RSVD,RSVD,EOT}},
Uwe.
on 20/10/2008 00:06 Uwe Hermann said the following:
On Fri, Oct 17, 2008 at 06:26:52PM +0300, Andriy Gapon wrote:
Add register definitions for W83627HF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon avg@icyb.net.ua
Looks good, thanks! Committed in r3670.
In addition, I've added your name to the list of contributors in the README,
Uwe, thanks a lot!
and I removed...
Index: winbond.c
--- winbond.c (revision 3667) +++ winbond.c (working copy) @@ -39,7 +39,46 @@ /* ID and rev[3..0] */ {0x527, "W83977CTF", { /* TODO: Not yet in sensors-detect */ {EOT}}},
[...]
{0xa, "ACPI",
/* Note: Datasheet says 0xe2 can't be read/written. */... this line. It seem to be copy-paste from some other Super I/O, the datasheet for this one doesn't seem to say that 0xe2 cannot be read/written anywhere (or at least I didn't find that place).
I was going to do the same but then noticed that this register is just mentioned in documentation, there is a section and a name for it, but there is zero description, the section is just empty. So I kept that line to be on the "safe side", but I agree with its removal.
{0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},{0x00,0x00,0x00,0x00,MISC,MISC,MISC,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,RSVD,RSVD,EOT}},Uwe.
on 20/10/2008 00:06 Uwe Hermann said the following:
On Fri, Oct 17, 2008 at 06:26:52PM +0300, Andriy Gapon wrote:
Add register definitions for W83627HF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon avg@icyb.net.ua
Looks good, thanks! Committed in r3670.
Uwe,
I've just noticed this and I apologize a lot: it seems that I used "W83627HF" and "W83627HF/GF" where I should have used "W83977EF" "W83977EF/EG" in the commit message above. Sorry for causing this confusions, maybe it's still possible to fix the commit message.
It should have read:
Add register definitions for W83977EF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83977EF/EG family have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon avg@icyb.net.ua
-
Andriy Gapon -
Uwe Hermann