[lm-sensors] [PATCH] hwmon: (abituguru3) Support multiple DMI strings per chip ID (#2)

[Rune Svendsen]

(resending because my mail application apparently removed the CC'd addresses.)

On Sun, 2009-09-06 at 14:03 +0200, Jean Delvare wrote:
[snip]
> >  
> >  
> > @@ -947,7 +951,7 @@ static int __devinit abituguru3_probe(struct platform_device *pdev)
> >  		"ID: %04X\n", (unsigned int)id);
> >  
> >  #ifdef CONFIG_DMI
> > -	if (!abituguru3_motherboards[i].dmi_name) {
> > +	if (!abituguru3_motherboards[i].dmi_name[0]) {
> >  		printk(KERN_WARNING ABIT_UGURU3_NAME ": this motherboard was "
> >  			"not detected using DMI. Please send the output of "
> >  			"\"dmidecode\" to the abituguru3 maintainer "
> 
> This test is no longer as perfect as it used to be. Now that you admit
> that each ID can correspond to more than one board model, it is
> possible that the board was _not_ detected using DMI but this message
> will not show (because another board with this ID is already known.)
> While this is not a blocker, I still think it would be worth improving.
> 
> Maybe I am missing something obvious, but why isn't this message
> printed in abituguru3_dmi_detect() directly? This would be more
> efficient and more elegant too IMHO.

After speaking with Alistair I've been thinking about this as well.
Right now, when I'm running a kernel that doesn't support inserting the
abituguru3 module without using the "force=1" option (a kernel to which
this patch has not been applied), I don't receive a message in my kernel
log about sending the output of "dmidecode" - precisely because of what
you mention here.

I'm thinking that that same rules that decide whether I get to insert
the abituguru3 module into the kernel should decide whether the message
about sending the output of "dmidecode" will appear.