| Message ID | 200908301546.22827.jdelvare@suse.de (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
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 -- 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
> > 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 -- 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
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,
--- 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;
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(-)