[PATCH] ACPI: Clarify resource conflict message

[PATCH] ACPI: Clarify resource conflict message

[Jean Delvare]

The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented an API for
the device in question (which, AFAIK, can't be checked.) If not, then
either the generic "thermal" ACPI driver may be used, or nothing can
be done (other than a white list, if we really want to get hardware
monitoring on some machines.)

I propose to reword the message to:

ACPI: Device may still be supported by an ACPI driver

which I think is more correct. Comments and suggestions welcome.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Thomas Renninger <trenn@suse.de>
---
 drivers/acpi/osl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.31-rc8.orig/drivers/acpi/osl.c	2009-08-28 19:48:58.000000000 +0200
+++ linux-2.6.31-rc8/drivers/acpi/osl.c	2009-08-30 10:10:51.000000000 +0200
@@ -1182,7 +1182,8 @@ int acpi_check_resource_conflict(struct
 			       res_list_elem->name,
 			       (long long) res_list_elem->start,
 			       (long long) res_list_elem->end);
-			printk(KERN_INFO "ACPI: Device needs an ACPI driver\n");
+			printk(KERN_INFO "ACPI: Device may still be supported"
+			       " by an ACPI driver\n");
 		}
 		if (acpi_enforce_resources == ENFORCE_RESOURCES_STRICT)
 			return -EBUSY;

-- 
Jean Delvare
Suse L3

Re: [PATCH] ACPI: Clarify resource conflict message

[Alan Jenkins]

On 8/30/09, Jean Delvare <jdelvare@suse.de> wrote:
> The message "ACPI: Device needs an ACPI driver" is misleading. The
> device _may_ need an ACPI driver, if the BIOS implemented an API for
> the device in question (which, AFAIK, can't be checked.) If not, then
> either the generic "thermal" ACPI driver may be used,

Um, the 'generic "thermal" ACPI driver' counts as 'an ACPI driver' :-).

> or nothing can
> be done (other than a white list, if we really want to get hardware
> monitoring on some machines.)

Fair point.  I don't like the message either.  "needs" seems quite a
demanding word to me.  Personally I'd be happy with just the conflict
message which precedes it.

> I propose to reword the message to:
>
> ACPI: Device may still be supported by an ACPI driver
>
> which I think is more correct. Comments and suggestions welcome.

I would drop the word "still", but otherwise I think this is a good idea.

Regards
Alan

Re: [PATCH] ACPI: Clarify resource conflict message

[Len Brown]

> > The message "ACPI: Device needs an ACPI driver" is misleading...

> > ACPI: Device may still be supported by an ACPI driver

> I would drop the word "still", but otherwise I think this is a good idea.

I agree we need to clarify this message.

Right now we have (copied from a recent bug report):

w83627ehf: Found W83627EHG chip at 0x290
ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region SEN1
[0x295-0x296]
ACPI: Device needs an ACPI driver

This results in people filing bugs against ACPI because their sensor
driver does not load -- we've seen several already.

I'm okay with the 1st ACPI line -- it tells somebody who cares exactly
what is going on.

"Device needs an ACPI driver", however, fails to tell the administrator
what they can do about it.  We should probably mention that they
can test "acpi_enforce_resources=lax".  However, we should probably
put a big WARNING - using-at-own-risk note in the dmesg when
that option is actually used.

And then what is the next course of action -- possible inclusion
on a white-list if they conflict turns out to be benign,
or (less likely) possible development of a missing ACPI driver?

We could have quite a few bug reports filed on this,
so wording is important.

thanks,
-Len Brown, Intel Open Source Technology Center

Re: [PATCH] ACPI: Clarify resource conflict message

[Jean Delvare]

Hi Len,

Le lundi 31 août 2009, Len Brown a écrit :
> > > The message "ACPI: Device needs an ACPI driver" is misleading...
> 
> > > ACPI: Device may still be supported by an ACPI driver
> 
> > I would drop the word "still", but otherwise I think this is a good idea.
> 
> I agree we need to clarify this message.
> 
> Right now we have (copied from a recent bug report):
> 
> w83627ehf: Found W83627EHG chip at 0x290
> ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region SEN1
> [0x295-0x296]
> ACPI: Device needs an ACPI driver
> 
> This results in people filing bugs against ACPI because their sensor
> driver does not load -- we've seen several already.

I know, and this is why I sent a patch to change the wording.

> I'm okay with the 1st ACPI line -- it tells somebody who cares exactly
> what is going on.
> 
> "Device needs an ACPI driver", however, fails to tell the administrator
> what they can do about it.  We should probably mention that they
> can test "acpi_enforce_resources=lax".  However, we should probably
> put a big WARNING - using-at-own-risk note in the dmesg when
> that option is actually used.

I don't think we want to unconditionally point the user to
"acpi_enforce_resources=lax". Doing so would essentially void our
effort to get rid of concurrent access to these resources.

In particular, now that we have the asus_atk0110 driver and this
driver loads automatically on the boards which need it, we certainly
do NOT want to tell these users that they should use
"acpi_enforce_resources=lax". What they should do is use the
asus_atk0110 driver instead of the native driver they were using so
far.

Only if no ACPI-based hardware monitoring driver has been loaded, we
could point the user to "acpi_enforce_resources=lax". With a warning
and disclaimer, of course.

> And then what is the next course of action -- possible inclusion
> on a white-list if they conflict turns out to be benign,
> or (less likely) possible development of a missing ACPI driver?

I wasn't sure whether you would be OK with a whitelist. I too
think we will need one, although this won't be in 2.6.31. Then it
indeed makes sense to ask the users to test
"acpi_enforce_resources=lax", and if it works, they can report to us
and after a DSDT code review, their system can be added to the
whitelist.

I am curious how many systems will have to be added to the whitelist.
I presume that the whitelist would consist in DMI board vendor +
model entries?

> We could have quite a few bug reports filed on this,
> so wording is important.

I fully agree.

What I propose:
* For 2.6.30 (if we are fast enough), an updated version of my patch,
  taking Alan Jenkins' suggestion into account, and an additional
  warning when "acpi_enforce_resources=lax" is used.
* For 2.6.31, a whitelisting mechanism, and a verbose log message
  explaining the steps to get a system into this whitelist.

OK?

Thanks,
-- 
Jean Delvare
Suse L3
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html