Advanced Configuration and Power Interface Specification

ACPI Hardware Specification
Generic hardware power management features can be implemented accessing spare I/O ports
residing in any of these address spaces. The ACPI specification defines an optional embedded
controller and SMBus interfaces needed to communicate with these associated address spaces.
4.6.1 Hardware Reserved Bits
ACPI hardware registers are designed such that reserved bits always return zero, and data writes to
them have no side affects. OSPM implementations must write zeros to reserved bits in enable and
status registers and preserve bits in control registers, and they will treat these bits as ignored.
4.6.2 Hardware Ignored Bits
ACPI hardware registers are designed such that ignored bits are undefined and are ignored by
software. Hardware-ignored bits can return zero or one. When software reads a register with ignored
bits, it masks off ignored bits prior to operating on the result. When software writes to a register with
ignored bit fields, it preserves the ignored bit fields.
4.6.3 Hardware Write-Only Bits
ACPI hardware defines a number of write-only control bits. These bits are activated by software
writing a 1 to their bit position. Reads to write-only bit positions generate undefined results. Upon
reads to registers with write-only bits, software masks out all write-only bits.
4.6.4 Cross Device Dependencies
Cross Device Dependency is a condition in which an operation to a device interferes with the
operation of other unrelated devices, or allows other unrelated devices to interfere with its behavior.
This condition is not supportable and can cause platform failures. ACPI provides no support for
cross device dependencies and suggests that devices be designed to not exhibit this behavior. The
following two examples describe cross device dependencies:
4.6.4.1 Example 1: Related Device Interference
This example illustrates a cross device dependency where a device interferes with the proper
operation of other unrelated devices. Device A has a dependency that when it is being configured it
blocks all accesses that would normally be targeted for Device B. Thus, the device driver for Device
B cannot access Device B while Device A is being configured; therefore, it would need to
synchronize access with the driver for Device A. High performance, multithreaded operating
systems cannot perform this kind of synchronization without seriously impacting performance.
To further illustrate the point, assume that Device A is a serial port and Device B is a hard drive
controller. If these devices demonstrate this behavior, then when a software driver configures the
serial port, accesses to the hard drive need to block. This can only be done if the hard disk driver
synchronizes access to the disk controller with the serial driver. Without this synchronization, hard
drive data will be lost when the serial port is being configured.
4.6.4.2 Example 2: Unrelated Device Interference
This example illustrates a cross-device dependency where a device demonstrates a behavior that
allows other unrelated devices to interfere with its proper operation. Device A exhibits a
Version 6.0 67