Locking out AML code
I'm writing a driver to access some EC-related functionality on some Acer laptops. This uses a separate IO port interface and cannot be done using the standard ec_read / ec_write ACPI functions. The DSDT also accesses these IO ports for a few things (most notably display brightness and some WMI methods). Is there a lock I can hold (from outside the ACPI subsystem) that will lock out AML method execution while I poke the hardware?
FWIW, the Windows drivers from Acer also access those IO ports directly (from userspace, no less, with a dumb kernel driver to provide port I/O to userspace and in the process introduce a huge security hole of course). There is no way of talking to this hardware via DSDT methods.
Signature · 2 lines
Hector Martin ([email protected]) Public Key: http://www.marcansoft.com/marcan.asc
Quoted 7 lines · Hector Martin
I'm writing a driver to access some EC-related functionality on some Acer laptops. This uses a separate IO port interface and cannot be done using the standard
ec_read/ec_writeACPI functions. The DSDT also accesses these IO ports for a few things (most notably display brightness and some WMI methods). Is there a lock I can hold (from outside the ACPI subsystem) that will lock out AML method execution while I poke the hardware?
Try acpi_os_acquire_lock(acpi_gbl_hardware_lock).
But acpi_gbl_hardware_lock is defined in the ACPICA internal header "drivers/acpi/acpica/acglobal.h",
you need to move it to public header, for example, include/acpi/acpixf.h
Lin Ming
Quoted 9 lines
FWIW, the Windows drivers from Acer also access those IO ports directly (from userspace, no less, with a dumb kernel driver to provide port I/O to userspace and in the process introduce a huge security hole of course). There is no way of talking to this hardware via DSDT methods.
--
Hector Martin ([email protected])
Public Key: http://www.marcansoft.com/marcan.asc