login
Search
Provide acpi_check_{mem_}region.
Drivers can additionally check against possible ACPI interference by also
invoking this shortly before they call request_region.
If -EBUSY is returned, the driver must not load.
Use acpi_enforce_resources=strict/lax/no options to:
- strict: let conflicting drivers fail to load with an error message
- lax: let conflicting driver work normal with a warning message
- no: no functional change at all
Signed-off-by: Thomas Renninger <trenn@suse.de>
---
drivers/acpi/osl.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++-
include/linux/acpi.h | 13 +++
2 files changed, 186 insertions(+), 2 deletions(-)
Index: lenb/drivers/acpi/osl.c
===================================================================
--- lenb.orig/drivers/acpi/osl.c
+++ lenb/drivers/acpi/osl.c
@@ -44,6 +44,8 @@
#include <asm/uaccess.h>
#include <linux/efi.h>
+#include <linux/ioport.h>
+#include <linux/list.h>
#define _COMPONENT ACPI_OS_SERVICES
ACPI_MODULE_NAME("osl");
@@ -74,6 +76,18 @@ static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
static struct workqueue_struct *kacpi_notify_wq;
+struct acpi_res_list {
+ resource_size_t start;
+ resource_size_t end;
+ acpi_adr_space_type resource_type; /* IO port, System memory, ...*/
+ char name[5]; /* only can have a length of 4 chars, make use of this
+ one instead of res->name, no need to kalloc then */
+ struct list_head resource_list;
+};
+
+static LIST_HEAD(resource_list_head);
+static DEFINE_SPINLOCK(acpi_res_lock);
+
#define OSI_STRING_LENGTH_MAX 64 /* arbitrary */
static char osi_additional_string[OSI_STRING_LENGTH_MAX];
@@ -1042,6 +1056,127 @@ static int __init acpi_wake_gpes_always_
__setup("acpi_wake_gpes_always_on", acpi_wake_gpes_always_on_setup);
+/* Check of resource interference between native drivers and ACPI
+ * OperationRegions (SystemIO and System Memory only).
+ * IO ports and memory declared in ACPI might be used by ...OK, so Len has merged these into the acpi test tree. My understanding is that once this work hits mainline, we can then merge check-for-acpi-resource-conflicts-in-hwmon-drivers.patch. My normal approach would be to send check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for inclusion in git-hwmon one Len has merged the prerequisites into mainline. Problem is, if Len merges late in the 2.6.26 merge window, Mark might not have time to gets these changes into mainline before 2.6.27. Which is all getting a bit dumb considering I first merged everything in October. Fortunately things aren't mormally _this_ inefficient when one follows the rules - this was an unusual patchset. But still, I think we could afford to speed things up a bit more than that. We could ask Len to consider merging this work into 2.6.25 and then if Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch (below) for an akpm-merge, we're good to go. But I do recall that people were a bit uncertain about it all back in October. Please share your thoughts with us. From: Jean Delvare <jdelvare@suse.de> Check for ACPI resource conflicts in hwmon drivers. I've included all Super-I/O and PCI drivers. I've voluntarily left out: * Laptop specific and vendor-specific drivers: if they conflicted on any system, this would pretty much mean that they conflict on all systems, and we would know by now. * Legacy ISA drivers (lm78 and w83781d): they only support chips found on old designs were ACPI either wasn't supported or didn't deal with thermal management. * Drivers accessing the I/O resources indirectly (e.g. through SMBus): the check will be added where it belongs, i.e. in the bus drivers. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Thomas Renninger <trenn@suse.de> Cc: "Mark M. Hoffman" <mhoffman@lightlink.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- drivers/hwmon/dme1737.c | ...
The patch is totally unrisky, beside of an overseen typo that always can slip in (if this should be a concern)... About the mechanism and the fact that there is another instance to check IO port and system memory resources? IIRC Bjorn did not like that, but also wanted to integrated that into pnp layer somehow. But I expect after fighting already that hard with mainboard/system pnp resource conflicts and BIOS weirdness the last weeks..., he also agrees that it makes not much sense that the OperationRegion port/memory checks should get integrated into the pnp layer now or at all (which could conflict as a third instance (driver resources vs pnp resources vs ACPI OperationRegion declarations) depending on how broken the BIOS is, even with overlapping!) --
Hi Andrew, Correct. Same applies to a second patch: check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch Len already merged all the acpi bits for 2.6.25 as far as I can see, so all that is missing now is these two patches: check-for-acpi-resource-conflicts-in-hwmon-drivers.patch check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch Both have been in -mm for quite some time. In the default mode (acpi_enforce_resources=lax) these patches simply print warnings but still let the drivers load, so they are safe to merge, and the sooner, the better. The idea is to get feedback on how many systems out there have ACPI resource conflicts. Then we'll see how we can address them (if at all.) I don't remember anyone objecting to these patches, and anyway the problem has been there for years and nobody took care, so if anyone really isn't happy with the solution designed by Thomas, that person will have to do the work and submit something better later. That shouldn't delay the merge of what we have now. Andrew, both patches are Acked-by: Jean Delvare <khali@linux-fr.org> and I am totally fine with you pushing them to Linus now. But of course having Mark's ack would be good too. Thanks, -- Jean Delvare --
On Sun, 10 Feb 2008 13:25:36 +0100 That would be nice. But I'll merge them mid-week anyway unless Mark actually nacks them: http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-... http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-... Thanks. --
Yeah but that wasn't the same me. That was me-developer-at-suse, who doesn't yet have the same aura as Yeah, sounds like a good plan, thanks for taking care. -- Jean Delvare --
Hi Andrew, Jean: OK, I pulled the first of those into my hwmon testing tree and merged it, since there are trivial conflicts with some of the other patches already there. I'll send it to Linus before -rc2. Andrew: hopefully that makes your life .001% easier. ;) Regards, -- Mark M. Hoffman mhoffman@lightlink.com --