[lm-sensors] [PATCH 0/2] hwmon: (abituguru3) Partial DMI matching, add IN9 32X MAX DMI product string

[Alistair John Strachan]

On Thursday 15 January 2009 15:22:45 Jean Delvare wrote:
> > (One remaining question would be whether patch 1 should be CCed to
> > -stable, since there has been a regression introduced into 2.6.27 and
> > present in 2.6.28 for some BIOS revisions of the IP35 Pro.)
>
> Is there really a regression? If the DMI matching doesn't work, we fall
> back to the old detection method, so I can't see how there would be a
> regression. Care to explain?

Having looked at this properly I agree. It's clear that in this bug report 
what actually happened was the DMI match failed, AND the probe routine failed.

This definitely puts the final nail in the coffin of manual probing, 
especially on the IP35 Pro (which was where all these changes originated 
from).

Sorry for the confusion, you are correct, and there is no way this could be 
considered a regression. I had just extrapolated that from the original 
poster, but it must be the case that it has never worked, or worked 
unreliably.

> Speaking of DMI matching... If DMI is disabled, we do:
>
> static inline int abituguru3_dmi_detect(void)
> {
> 	return -ENODEV;
> }
>
> And this error value causes abituguru3_init() to bail out. Unless I'm
> missing something, the abituguru3 driver is simply useless without DMI
> support at the moment. We should either make that official and make the
> driver depend on DMI at Kconfig level, or change
> abituguru3_dmi_detect() to return 1, so that we fallback to the old
> detection method. Opinions?

It should return 1. This is simply a blunder. Fortunately CONFIG_DMI is quite 
difficult to turn off, and no distribution would. I'll follow up to this email 
with a proper patch.

Apologies for the mistakes..

-- 
Cheers,
Alistair.