All of lore.kernel.org
 help / color / mirror / Atom feed
* [lm-sensors] Error message when ACPI causes a device probe to fail
@ 2009-10-02 13:43 Jean Delvare
  2009-10-02 14:19 ` [lm-sensors] Error message when ACPI causes a device probe to Greg KH
  2009-10-02 14:35 ` Jean Delvare
  0 siblings, 2 replies; 3+ messages in thread
From: Jean Delvare @ 2009-10-02 13:43 UTC (permalink / raw)
  To: lm-sensors

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?

* 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?

Or maybe there's another fix possible and I did not see it. Feel free
to speak up if you have an idea.

Thanks,
-- 
Jean Delvare

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [lm-sensors] Error message when ACPI causes a device probe to
  2009-10-02 13:43 [lm-sensors] Error message when ACPI causes a device probe to fail Jean Delvare
@ 2009-10-02 14:19 ` Greg KH
  2009-10-02 14:35 ` Jean Delvare
  1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2009-10-02 14:19 UTC (permalink / raw)
  To: lm-sensors

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.

thanks,

greg k-h

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [lm-sensors] Error message when ACPI causes a device probe to
  2009-10-02 13:43 [lm-sensors] Error message when ACPI causes a device probe to fail Jean Delvare
  2009-10-02 14:19 ` [lm-sensors] Error message when ACPI causes a device probe to Greg KH
@ 2009-10-02 14:35 ` Jean Delvare
  1 sibling, 0 replies; 3+ messages in thread
From: Jean Delvare @ 2009-10-02 14:35 UTC (permalink / raw)
  To: lm-sensors

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-10-02 14:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-02 13:43 [lm-sensors] Error message when ACPI causes a device probe to fail Jean Delvare
2009-10-02 14:19 ` [lm-sensors] Error message when ACPI causes a device probe to Greg KH
2009-10-02 14:35 ` Jean Delvare

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.