Re: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

[Robert Hancock <hancockrwd@gmail.com>]

On 07/02/2009 09:49 AM, Moore, Robert wrote:
>> -----Original Message-----
>> From: Jean Delvare [mailto:jdelvare@suse.de]
> ...
>> Native Linux drivers trying to access devices which ACPI also wants
>> to access. Most frequently these are SMBus master drivers or hardware
>> monitoring drivers (for Super I/O chips) but virtually any other
>> device type could be affected, due to the fact that ACPI I/O
>> resources do not show up in /proc/ioports and /proc/iomem.
>
>
> I have some concern with this. The implication is that there is a serious hole in ACPI that can only be solved by monitoring exactly what the AML code is doing, because access to resources may conflict with device drivers. I have to think that if this were truly the case, the operating system vendors and the ACPI contributors would have pushed a fix for this problem into the ACPI specification by now (in the 13 years since the first release of ACPI).
>
> The SMBus driver issue is very interesting. I have not heard of any conflicts between AML code and SMBus drivers on other operating systems, nor have we received any other complaints about removing the acpi_os_validate_address interface. I wonder if the Linux SMBus driver is doing something that it should not be doing.
>
> I'd like to see a concrete example of the problem. If someone can send me a DSDT that contains such an example, I would appreciate it. I want to see the exact ASL code that is causing the problem along with the driver code that conflicts with it. This information will help me understand the problem in relation to the ACPICA code, and I can also present this to other ACPI and BIOS experts for their opinions.
>
> As far as an immediate fix for the problem, I suggest that you think about using acpi_walk_namespace to retrieve all objects of type Region (or field). It seems a waste to build an entire list of objects that duplicates information that already exists in the namespace.

My guess is that exactly the same thing will happen if you install 
add-on hardware monitoring software on Windows that loads drivers that 
access SMBus hardware directly on such systems where ACPI accesses the 
same devices. The ACPI code and the native driver will likely stomp on 
each other's hardware accesses. Likely on Linux it's more frequent that 
this kind of native hardware monitoring driver gets used (in some setups 
it seems they will auto-load by default..)