drivers/acpi/acpica/hwxface.c
Source file repositories/reference/linux-study-clean/drivers/acpi/acpica/hwxface.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/acpi/acpica/hwxface.c- Extension
.c- Size
- 13453 bytes
- Lines
- 449
- Domain
- Driver Families
- Bucket
- drivers/acpi
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
acpi/acpi.haccommon.hacnamesp.h
Detected Declarations
function Copyrightfunction acpi_readfunction acpi_writefunction bit0function registersfunction acpi_get_sleep_type_data
Annotated Snippet
if (ACPI_FAILURE(status)) {
goto unlock_and_exit;
}
/*
* Insert the input bit into the value that was just read
* and write the register
*/
ACPI_REGISTER_INSERT_VALUE(register_value,
bit_reg_info->bit_position,
bit_reg_info->access_bit_mask,
value);
status = acpi_hw_register_write(bit_reg_info->parent_register,
register_value);
} else {
/*
* 2) Case for PM1 Status
*
* The Status register is different from the rest. Clear an event
* by writing 1, writing 0 has no effect. So, the only relevant
* information is the single bit we're interested in, all others
* should be written as 0 so they will be left unchanged.
*/
register_value = ACPI_REGISTER_PREPARE_BITS(value,
bit_reg_info->
bit_position,
bit_reg_info->
access_bit_mask);
/* No need to write the register if value is all zeros */
if (register_value) {
status =
acpi_hw_register_write(ACPI_REGISTER_PM1_STATUS,
register_value);
}
}
ACPI_DEBUG_PRINT((ACPI_DB_IO,
"BitReg %X, ParentReg %X, Value %8.8X, Actual %8.8X\n",
register_id, bit_reg_info->parent_register, value,
register_value));
unlock_and_exit:
acpi_os_release_raw_lock(acpi_gbl_hardware_lock, lock_flags);
return_ACPI_STATUS(status);
}
ACPI_EXPORT_SYMBOL(acpi_write_bit_register)
#endif /* !ACPI_REDUCED_HARDWARE */
/*******************************************************************************
*
* FUNCTION: acpi_get_sleep_type_data
*
* PARAMETERS: sleep_state - Numeric sleep state
* *sleep_type_a - Where SLP_TYPa is returned
* *sleep_type_b - Where SLP_TYPb is returned
*
* RETURN: Status
*
* DESCRIPTION: Obtain the SLP_TYPa and SLP_TYPb values for the requested
* sleep state via the appropriate \_Sx object.
*
* The sleep state package returned from the corresponding \_Sx_ object
* must contain at least one integer.
*
* March 2005:
* Added support for a package that contains two integers. This
* goes against the ACPI specification which defines this object as a
* package with one encoded DWORD integer. However, existing practice
* by many BIOS vendors is to return a package with 2 or more integer
* elements, at least one per sleep type (A/B).
*
* January 2013:
* Therefore, we must be prepared to accept a package with either a
* single integer or multiple integers.
*
* The single integer DWORD format is as follows:
* BYTE 0 - Value for the PM1A SLP_TYP register
* BYTE 1 - Value for the PM1B SLP_TYP register
* BYTE 2-3 - Reserved
*
* The dual integer format is as follows:
* Integer 0 - Value for the PM1A SLP_TYP register
* Integer 1 - Value for the PM1A SLP_TYP register
*
******************************************************************************/
acpi_status
Annotation
- Immediate include surface: `acpi/acpi.h`, `accommon.h`, `acnamesp.h`.
- Detected declarations: `function Copyright`, `function acpi_read`, `function acpi_write`, `function bit0`, `function registers`, `function acpi_get_sleep_type_data`.
- Atlas domain: Driver Families / drivers/acpi.
- Implementation status: integration implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.