Hi Matthew, On Fri, 2 Mar 2007 14:57:09 +0000, Matthew Garrett wrote: > How about this? It's informational only, but ought to result in > complaints whenever ACPI tries to touch something that other hardware > has reserved. We can't fail these accesses, but in theory we could > consider some sort of locking layer that made it possible to interact > anyway. I haven't even checked if this builds, but I think the concept > is reasonable. I like the patch, after adding some casts to the printf args it compiles fine. However you print warnings each time a resource has been reserved... without checking if it hasn't been reserved by ACPI itself! My machine looks like this: 1000-107f : 0000:00:1f.0 1000-1003 : ACPI PM1a_EVT_BLK 1004-1005 : ACPI PM1a_CNT_BLK 1008-100b : ACPI PM_TMR 1010-1015 : ACPI CPU throttle 1020-1020 : ACPI PM2_CNT_BLK 1028-102b : ACPI GPE0_BLK 102c-102f : ACPI GPE1_BLK Given that these ports were reserved by ACPI it is perfectly legitimate that ACPI accesses it, so we must not print a warning in this case. We need to exclude from the test the regions those "name" starts with "ACPI", but I'm not sure how we can do that. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
