Re: [lm-sensors] Error message when ACPI causes a device probe to

[Jean Delvare <khali@linux-fr.org>]

On Fri, 2 Oct 2009 07:19:14 -0700, Greg KH wrote:
> On Fri, Oct 02, 2009 at 03:43:32PM +0200, Jean Delvare wrote:
> > Hi all,
> > 
> > We have recently added a mechanism to check for ACPI vs. native driver
> > resource conflicts. When such a conflict happens, we get an error
> > message of the following form in the logs:
> > 
> > ACPI: I/O resource 0000:00:1f.3 [0x18a0-0x18bf] conflicts with ACPI region SMBI [0x18a0-0x18af]
> > ACPI: Device needs an ACPI driver
> > 
> > But when the conflict is found in probe(), we also get the following
> > error message:
> > 
> > i801_smbus: probe of 0000:00:1f.3 failed with error -16
> > 
> > This is because the probe() method returns -EBUSY. The driver core
> > currently silents some error codes (ENODEV and ENXIO) but not EBUSY.
> > This error message is redundant with the ones printed by ACPI, and
> > somewhat more frightening, so users may report it to us, as was the
> > case here:
> > http://bugzilla.kernel.org/show_bug.cgi?id\x14293
> > 
> > So I would like to get rid of this message. I can think of two ways:
> > 
> > * Change the driver core to silent EBUSY as it does for ENODEV and
> >   ENXIO. Greg, I guess you wouldn't like that?
> 
> Nah, I don't, drivers should return -ENODEV if they can't bind to the
> device.  The -ENXIO was for some odd driver that I can't remember, we
> should remove that and change the source of it as well.
> 
> > * Change all drivers to return either -ENODEV or -ENXIO when an ACPI
> >   resource conflict is found inside a probe function. After all, nobody
> >   will ever see the error code in question so maybe it's acceptable
> >   even though these error codes don't really match the reality?
> 
> They should be changed to -ENODEV, as that means the driver can not
> handle the device for a valid reason.  And resource conflicts are valid
> reasons.

OK, perfect, I'll just do that then. Thanks!

-- 
Jean Delvare

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