[lm-sensors] PATCH: abituguru3-fix-detect.patch

[lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Hi All,

It has been reported that the abituguru3 driver fails to load after a BIOS
update. This patch fixes this by loosening the detection routine so that it
will work after the BIOS update too. To compensate for the now very loose
detection an additional check is added on the DMI Base Board vendor string to
make sure we only load on Abit motherboards, this is the same as the check in
the abituguru (1 / 2) driver.

Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>

Regards,

Hans

p.s.

Alistair can you test the abituguru3 driver compiled with this patch on your 
motherboard and confirm that it fixes the issue (and still works).

[-- Attachment #2: abituguru3-fix-detect.patch --]
[-- Type: text/plain, Size: 2129 bytes --]

It has been reported that the abituguru3 driver fails to load after a BIOS
update. This patch fixes this by loosening the detection routine so that it
will work after the BIOS update too. To compensate for the now very loose
detection an additional check is added on the DMI Base Board vendor string to
make sure we only load on Abit motherboards, this is the same as the check in
the abituguru (1 / 2) driver.

Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
diff -up vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c~ vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c
--- vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c~	2008-05-23 16:03:28.000000000 +0200
+++ vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c	2008-05-23 16:03:28.000000000 +0200
@@ -30,6 +30,7 @@
 #include <linux/platform_device.h>
 #include <linux/hwmon.h>
 #include <linux/hwmon-sysfs.h>
+#include <linux/dmi.h>
 #include <asm/io.h>
 
 /* uGuru3 bank addresses */
@@ -1111,11 +1112,12 @@ static int __init abituguru3_detect(void
 {
 	/* See if there is an uguru3 there. An idle uGuru3 will hold 0x00 or
 	   0x08 at DATA and 0xAC at CMD. Sometimes the uGuru3 will hold 0x05
-	   at CMD instead, why is unknown. So we test for 0x05 too. */
+	   or 0x55 at CMD instead, why is unknown. */
 	u8 data_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_DATA);
 	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
 	if (((data_val == 0x00) || (data_val == 0x08)) &&
-			((cmd_val == 0xAC) || (cmd_val == 0x05)))
+			((cmd_val == 0xAC) || (cmd_val == 0x05) ||
+			 (cmd_val == 0x55)))
 		return ABIT_UGURU3_BASE;
 
 	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "
@@ -1138,6 +1140,15 @@ static int __init abituguru3_init(void)
 	int address, err;
 	struct resource res = { .flags = IORESOURCE_IO };
 
+#ifdef CONFIG_DMI
+	const char *board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
+
+	/* safety check, refuse to load on non Abit motherboards */
+	if (!force && (!board_vendor ||
+			strcmp(board_vendor, "http://www.abit.com.tw/")))
+		return -ENODEV;
+#endif
+
 	address = abituguru3_detect();
 	if (address < 0)
 		return address;

[-- Attachment #3: 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: abituguru3-fix-detect.patch

[Alistair John Strachan]

On Friday 23 May 2008 15:10:41 Hans de Goede wrote:
[snip]
> Alistair can you test the abituguru3 driver compiled with this patch on
> your motherboard and confirm that it fixes the issue (and still works).

Confirmed. Thanks a lot for doing this.

Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Jean Delvare]

Hi Hans,

On Fri, 23 May 2008 16:10:41 +0200, Hans de Goede wrote:
> It has been reported that the abituguru3 driver fails to load after a BIOS
> update. This patch fixes this by loosening the detection routine so that it
> will work after the BIOS update too. To compensate for the now very loose
> detection an additional check is added on the DMI Base Board vendor string to
> make sure we only load on Abit motherboards, this is the same as the check in
> the abituguru (1 / 2) driver.
> 
> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>

I'm trading the review of this patch for the review of one of mine, for
example:
  http://lists.lm-sensors.org/pipermail/lm-sensors/2008-April/022998.html
Or any other you'd like. Deal?

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Fri, 23 May 2008 16:10:41 +0200, Hans de Goede wrote:
>> It has been reported that the abituguru3 driver fails to load after a BIOS
>> update. This patch fixes this by loosening the detection routine so that it
>> will work after the BIOS update too. To compensate for the now very loose
>> detection an additional check is added on the DMI Base Board vendor string to
>> make sure we only load on Abit motherboards, this is the same as the check in
>> the abituguru (1 / 2) driver.
>>
>> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
> 
> I'm trading the review of this patch for the review of one of mine, for
> example:
>   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-April/022998.html
> Or any other you'd like. Deal?
> 

Deal!

Regards,

Hans

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Jean Delvare]

Hi Hans,

On Fri, 23 May 2008 16:10:41 +0200, Hans de Goede wrote:
> It has been reported that the abituguru3 driver fails to load after a BIOS
> update. This patch fixes this by loosening the detection routine so that it
> will work after the BIOS update too. To compensate for the now very loose
> detection an additional check is added on the DMI Base Board vendor string to
> make sure we only load on Abit motherboards, this is the same as the check in
> the abituguru (1 / 2) driver.
> 
> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>

Missing "f".

> diff -up vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c~ vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c
> --- vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c~	2008-05-23 16:03:28.000000000 +0200
> +++ vanilla-2.6.26-rc3-git4/drivers/hwmon/abituguru3.c	2008-05-23 16:03:28.000000000 +0200
> @@ -30,6 +30,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/hwmon.h>
>  #include <linux/hwmon-sysfs.h>
> +#include <linux/dmi.h>
>  #include <asm/io.h>
>  
>  /* uGuru3 bank addresses */
> @@ -1111,11 +1112,12 @@ static int __init abituguru3_detect(void
>  {
>  	/* See if there is an uguru3 there. An idle uGuru3 will hold 0x00 or
>  	   0x08 at DATA and 0xAC at CMD. Sometimes the uGuru3 will hold 0x05
> -	   at CMD instead, why is unknown. So we test for 0x05 too. */
> +	   or 0x55 at CMD instead, why is unknown. */
>  	u8 data_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_DATA);
>  	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
>  	if (((data_val = 0x00) || (data_val = 0x08)) &&
> -			((cmd_val = 0xAC) || (cmd_val = 0x05)))
> +			((cmd_val = 0xAC) || (cmd_val = 0x05) ||
> +			 (cmd_val = 0x55)))
>  		return ABIT_UGURU3_BASE;
>  
>  	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "
> @@ -1138,6 +1140,15 @@ static int __init abituguru3_init(void)
>  	int address, err;
>  	struct resource res = { .flags = IORESOURCE_IO };
>  
> +#ifdef CONFIG_DMI
> +	const char *board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
> +
> +	/* safety check, refuse to load on non Abit motherboards */
> +	if (!force && (!board_vendor ||
> +			strcmp(board_vendor, "http://www.abit.com.tw/")))
> +		return -ENODEV;
> +#endif
> +
>  	address = abituguru3_detect();
>  	if (address < 0)
>  		return address;

Looks good to me.

Acked-by: Jean Delvare <khali@linux-fr.org>

Note though that the #ifdef is not needed as far as I can see. Without
DMI, dmi_get_system_info() will simply return NULL and your code
handles this case properly.

-- 
Jean Delvare

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Mark M. Hoffman]

Hi Hans:

* Hans de Goede <j.w.r.degoede@hhs.nl> [2008-05-23 16:10:41 +0200]:
(...)
> It has been reported that the abituguru3 driver fails to load after a BIOS
> update. This patch fixes this by loosening the detection routine so that it
> will work after the BIOS update too. To compensate for the now very loose
> detection an additional check is added on the DMI Base Board vendor string to
> make sure we only load on Abit motherboards, this is the same as the check in
> the abituguru (1 / 2) driver.
> 
> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>

Applied to hwmon-2.6.git/testing, thanks.

(will include in final batch to Linus for 2.6.26 also)

-- 
Mark M. Hoffman
mhoffman@lightlink.com


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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Alistair John Strachan]

Hi,

On Sunday 08 June 2008 16:16:33 Mark M. Hoffman wrote:
> > It has been reported that the abituguru3 driver fails to load after a
> > BIOS update. This patch fixes this by loosening the detection routine so
> > that it will work after the BIOS update too. To compensate for the now
> > very loose detection an additional check is added on the DMI Base Board
> > vendor string to make sure we only load on Abit motherboards, this is the
> > same as the check in the abituguru (1 / 2) driver.
> >
> > Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
>
> Applied to hwmon-2.6.git/testing, thanks.
>
> (will include in final batch to Linus for 2.6.26 also)

After updating my BIOS (from 16 to 17) the driver has stopped loading
again. This is with 2.6.26-rc8. The reason is that the command byte has
changed value to 0xFF (this is reproducible across cold and warm starts).

The following diff fixes it, but the "probe" is now looking even more creaky..

---

Fix loading of abituguru3 on Abit IP35 Pro with BIOS 17. The magic bytes have
changed value (again).

Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>

diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
index f00f497..53ee148 100644
--- a/drivers/hwmon/abituguru3.c
+++ b/drivers/hwmon/abituguru3.c
@@ -1118,7 +1118,7 @@ static int __init abituguru3_detect(void)
 	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
 	if (((data_val = 0x00) || (data_val = 0x08)) &&
 			((cmd_val = 0xAC) || (cmd_val = 0x05) ||
-			 (cmd_val = 0x55)))
+			 (cmd_val = 0x55) || (cmd_val = 0xFF)))
 		return ABIT_UGURU3_BASE;
 
 	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "


-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

Alistair John Strachan wrote:
> Hi,
> 
> On Sunday 08 June 2008 16:16:33 Mark M. Hoffman wrote:
>>> It has been reported that the abituguru3 driver fails to load after a
>>> BIOS update. This patch fixes this by loosening the detection routine so
>>> that it will work after the BIOS update too. To compensate for the now
>>> very loose detection an additional check is added on the DMI Base Board
>>> vendor string to make sure we only load on Abit motherboards, this is the
>>> same as the check in the abituguru (1 / 2) driver.
>>>
>>> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
>> Applied to hwmon-2.6.git/testing, thanks.
>>
>> (will include in final batch to Linus for 2.6.26 also)
> 
> After updating my BIOS (from 16 to 17) the driver has stopped loading
> again. This is with 2.6.26-rc8. The reason is that the command byte has
> changed value to 0xFF (this is reproducible across cold and warm starts).
> 
> The following diff fixes it, but the "probe" is now looking even more creaky..
> 

Ah what fun, well luckily I've added the DMI based check so the detection 
routine is less important now.

Mark, please apply.

Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>

Regards,

Hans

> ---
> 
> Fix loading of abituguru3 on Abit IP35 Pro with BIOS 17. The magic bytes have
> changed value (again).
> 
> Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
> 
> diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
> index f00f497..53ee148 100644
> --- a/drivers/hwmon/abituguru3.c
> +++ b/drivers/hwmon/abituguru3.c
> @@ -1118,7 +1118,7 @@ static int __init abituguru3_detect(void)
>  	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
>  	if (((data_val = 0x00) || (data_val = 0x08)) &&
>  			((cmd_val = 0xAC) || (cmd_val = 0x05) ||
> -			 (cmd_val = 0x55)))
> +			 (cmd_val = 0x55) || (cmd_val = 0xFF)))
>  		return ABIT_UGURU3_BASE;
>  
>  	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "
> 
> 


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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Jean Delvare]

Hi Hans,

On Thu, 03 Jul 2008 22:18:51 +0200, Hans de Goede wrote:
> Alistair John Strachan wrote:
> > Hi,
> > 
> > On Sunday 08 June 2008 16:16:33 Mark M. Hoffman wrote:
> >>> It has been reported that the abituguru3 driver fails to load after a
> >>> BIOS update. This patch fixes this by loosening the detection routine so
> >>> that it will work after the BIOS update too. To compensate for the now
> >>> very loose detection an additional check is added on the DMI Base Board
> >>> vendor string to make sure we only load on Abit motherboards, this is the
> >>> same as the check in the abituguru (1 / 2) driver.
> >>>
> >>> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
> >> Applied to hwmon-2.6.git/testing, thanks.
> >>
> >> (will include in final batch to Linus for 2.6.26 also)
> > 
> > After updating my BIOS (from 16 to 17) the driver has stopped loading
> > again. This is with 2.6.26-rc8. The reason is that the command byte has
> > changed value to 0xFF (this is reproducible across cold and warm starts).
> > 
> > The following diff fixes it, but the "probe" is now looking even more creaky..
> > 
> 
> Ah what fun, well luckily I've added the DMI based check so the detection 
> routine is less important now.
> 
> Mark, please apply.

I have to object. 0xff is the value you would get without a chip at
this address. So the change is roughly equivalent to not testing the
port at all... Plus, if the possible values change with every BIOS
update, we have to admit that the detection method isn't reliable. What
about switching to a DMI-based check? Not only checking the board
manufacturer but also the board product name. The abituguru3 driver
requires board-specific data anyway, so that's not a big change. And
there's always the "force" parameter to bypass the check for new boards.

> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
> 
> > ---
> > 
> > Fix loading of abituguru3 on Abit IP35 Pro with BIOS 17. The magic bytes have
> > changed value (again).
> > 
> > Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
> > 
> > diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
> > index f00f497..53ee148 100644
> > --- a/drivers/hwmon/abituguru3.c
> > +++ b/drivers/hwmon/abituguru3.c
> > @@ -1118,7 +1118,7 @@ static int __init abituguru3_detect(void)
> >  	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
> >  	if (((data_val = 0x00) || (data_val = 0x08)) &&
> >  			((cmd_val = 0xAC) || (cmd_val = 0x05) ||
> > -			 (cmd_val = 0x55)))
> > +			 (cmd_val = 0x55) || (cmd_val = 0xFF)))
> >  		return ABIT_UGURU3_BASE;
> >  
> >  	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "
> > 
> > 

-- 
Jean Delvare

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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Thu, 03 Jul 2008 22:18:51 +0200, Hans de Goede wrote:
>> Alistair John Strachan wrote:
>>> Hi,
>>>
>>> On Sunday 08 June 2008 16:16:33 Mark M. Hoffman wrote:
>>>>> It has been reported that the abituguru3 driver fails to load after a
>>>>> BIOS update. This patch fixes this by loosening the detection routine so
>>>>> that it will work after the BIOS update too. To compensate for the now
>>>>> very loose detection an additional check is added on the DMI Base Board
>>>>> vendor string to make sure we only load on Abit motherboards, this is the
>>>>> same as the check in the abituguru (1 / 2) driver.
>>>>>
>>>>> Signed-of-by: Hans de Goede <j.w.r.degoede@hhs.nl>
>>>> Applied to hwmon-2.6.git/testing, thanks.
>>>>
>>>> (will include in final batch to Linus for 2.6.26 also)
>>> After updating my BIOS (from 16 to 17) the driver has stopped loading
>>> again. This is with 2.6.26-rc8. The reason is that the command byte has
>>> changed value to 0xFF (this is reproducible across cold and warm starts).
>>>
>>> The following diff fixes it, but the "probe" is now looking even more creaky..
>>>
>> Ah what fun, well luckily I've added the DMI based check so the detection 
>> routine is less important now.
>>
>> Mark, please apply.
> 
> I have to object. 0xff is the value you would get without a chip at
> this address. So the change is roughly equivalent to not testing the
> port at all... Plus, if the possible values change with every BIOS
> update, we have to admit that the detection method isn't reliable. What
> about switching to a DMI-based check? Not only checking the board
> manufacturer but also the board product name. The abituguru3 driver
> requires board-specific data anyway, so that's not a big change. And
> there's always the "force" parameter to bypass the check for new boards.
> 

I understand where you're coming from, but I have to object to switching to DMI 
based detection. I would be happy to make that switch if and when I've got DMI 
strings for all currently supporting motherboards. I can start working on 
collecting those, but without those, switching to DMI based detection would 
cause regressions which IMHO is unacceptable.

I agree that the 0xff check is not pretty, but please keep in mind that:
1) This driver normally is never autoloaded, so it either has to be compiled in
    or explicitly loaded by the user (this is something where dmi based
    detection would be a win as dmi based autoloading is possible).

2) If someone has either compiled the driver in and/or loads it deliberately it
    will still only load (without the force parameter) on Abit motherboards.

3) After this simple read check, the driver does some reads from the chip
    (which involve isa writes) and if these fail the driver doesn't load. Note
    that these reads will most likely fail if there is no uguru3, as the uguru3
    has a quite complex handshaking scheme.

So move to DMI based detection in the future, sure. But for now I would like to 
see this patch applied.

Regards,

Hans


>> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
>>
>>> ---
>>>
>>> Fix loading of abituguru3 on Abit IP35 Pro with BIOS 17. The magic bytes have
>>> changed value (again).
>>>
>>> Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
>>>
>>> diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
>>> index f00f497..53ee148 100644
>>> --- a/drivers/hwmon/abituguru3.c
>>> +++ b/drivers/hwmon/abituguru3.c
>>> @@ -1118,7 +1118,7 @@ static int __init abituguru3_detect(void)
>>>  	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
>>>  	if (((data_val = 0x00) || (data_val = 0x08)) &&
>>>  			((cmd_val = 0xAC) || (cmd_val = 0x05) ||
>>> -			 (cmd_val = 0x55)))
>>> +			 (cmd_val = 0x55) || (cmd_val = 0xFF)))
>>>  		return ABIT_UGURU3_BASE;
>>>  
>>>  	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "
>>>
>>>
> 



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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Jean Delvare]

On Fri, 04 Jul 2008 14:02:26 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Hi Hans,
> > 
> > On Thu, 03 Jul 2008 22:18:51 +0200, Hans de Goede wrote:
> >> Alistair John Strachan wrote:
> >>> After updating my BIOS (from 16 to 17) the driver has stopped loading
> >>> again. This is with 2.6.26-rc8. The reason is that the command byte has
> >>> changed value to 0xFF (this is reproducible across cold and warm starts).
> >>>
> >>> The following diff fixes it, but the "probe" is now looking even more creaky..
> >>>
> >> Ah what fun, well luckily I've added the DMI based check so the detection 
> >> routine is less important now.
> >>
> >> Mark, please apply.
> > 
> > I have to object. 0xff is the value you would get without a chip at
> > this address. So the change is roughly equivalent to not testing the
> > port at all... Plus, if the possible values change with every BIOS
> > update, we have to admit that the detection method isn't reliable. What
> > about switching to a DMI-based check? Not only checking the board
> > manufacturer but also the board product name. The abituguru3 driver
> > requires board-specific data anyway, so that's not a big change. And
> > there's always the "force" parameter to bypass the check for new boards.
> > 
> 
> I understand where you're coming from, but I have to object to switching to DMI 
> based detection. I would be happy to make that switch if and when I've got DMI 
> strings for all currently supporting motherboards. I can start working on 
> collecting those, but without those, switching to DMI based detection would 
> cause regressions which IMHO is unacceptable.
> 
> I agree that the 0xff check is not pretty, but please keep in mind that:
> 1) This driver normally is never autoloaded, so it either has to be compiled in
>     or explicitly loaded by the user (this is something where dmi based
>     detection would be a win as dmi based autoloading is possible).
> 
> 2) If someone has either compiled the driver in and/or loads it deliberately it
>     will still only load (without the force parameter) on Abit motherboards.
> 
> 3) After this simple read check, the driver does some reads from the chip
>     (which involve isa writes) and if these fail the driver doesn't load. Note
>     that these reads will most likely fail if there is no uguru3, as the uguru3
>     has a quite complex handshaking scheme.
> 
> So move to DMI based detection in the future, sure. But for now I would like to 
> see this patch applied.

Hmm, OK. I thought that you had these DMI strings handy already. If
not, please start collecting them now, so that the driver can be
switched to DMI-based detection in the future.

-- 
Jean Delvare

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

[lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hi Andrew,

As discussed I'm sending this patch directly to you for 2.6.27 inclusion as 
Mark seems to be out of the loop at the moment.

Alistair John Strachan wrote:

"After updating my BIOS (from 16 to 17) the driver has stopped loading
again. This is with 2.6.26-rc8. The reason is that the command byte has
changed value to 0xFF (this is reproducible across cold and warm starts).

The following diff fixes it."

Regards,

Hans

[-- Attachment #2: abituguru3-fix-detect.patch --]
[-- Type: text/x-patch, Size: 672 bytes --]

Fix loading of abituguru3 on Abit IP35 Pro with BIOS 17. The magic bytes have
changed value (again).

Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>

--- a/drivers/hwmon/abituguru3.c
+++ b/drivers/hwmon/abituguru3.c
@@ -1118,7 +1118,7 @@ static int __init abituguru3_detect(void)
 	u8 cmd_val = inb_p(ABIT_UGURU3_BASE + ABIT_UGURU3_CMD);
 	if (((data_val == 0x00) || (data_val == 0x08)) &&
 			((cmd_val == 0xAC) || (cmd_val == 0x05) ||
-			 (cmd_val == 0x55)))
+			 (cmd_val == 0x55) || (cmd_val == 0xFF)))
 		return ABIT_UGURU3_BASE;
 
 	ABIT_UGURU3_DEBUG("no Abit uGuru3 found, data = 0x%02X, cmd = "

[-- Attachment #3: 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: abituguru3-fix-detect.patch

[Andrew Morton]

On Thu, 31 Jul 2008 12:30:05 +0200 Hans de Goede <j.w.r.degoede@hhs.nl> wrote:

> Hi Andrew,
> 
> As discussed I'm sending this patch directly to you for 2.6.27 inclusion as 
> Mark seems to be out of the loop at the moment.
> 
> Alistair John Strachan wrote:
> 
> "After updating my BIOS (from 16 to 17) the driver has stopped loading
> again. This is with 2.6.26-rc8. The reason is that the command byte has
> changed value to 0xFF (this is reproducible across cold and warm starts).
> 
> The following diff fixes it."
> 

OK, I'll prepare a hwmon patchbombing over the next few days.

Regarding this patch:

a) "abituguru3-fix-detect.patch" isn't a nice title.  I retitled it
   to "hwmon: fix loading of abituguru3 on Abit IP35 Pro with BIOS 17"

b) The way you presented this email would cause the patch to be
   attributed to yourself.  However I have a suspicion that Alistair
   wrote it.

   If this was the case then the way to communicate that authorship
   is to put his From: line right at the start of the changelog.


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

Re: [lm-sensors] PATCH: abituguru3-fix-detect.patch

[Hans de Goede]

Andrew Morton wrote:
> b) The way you presented this email would cause the patch to be
>    attributed to yourself.  However I have a suspicion that Alistair
>    wrote it.
> 

Correct, thanks for the education :)

Regards,

Hans

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