drivers/acpi/acpica/utxfmutex.c
Source file repositories/reference/linux-study-clean/drivers/acpi/acpica/utxfmutex.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/acpi/acpica/utxfmutex.c- Extension
.c- Size
- 4544 bytes
- Lines
- 155
- 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 acpi_ut_get_mutex_objectfunction acpi_acquire_mutexfunction acpi_release_mutex
Annotated Snippet
if (ACPI_FAILURE(status)) {
return (status);
}
}
/* Ensure that we actually have a Mutex object */
if (!mutex_node || (mutex_node->type != ACPI_TYPE_MUTEX)) {
return (AE_TYPE);
}
/* Get the low-level mutex object */
mutex_obj = acpi_ns_get_attached_object(mutex_node);
if (!mutex_obj) {
return (AE_NULL_OBJECT);
}
*ret_obj = mutex_obj;
return (AE_OK);
}
/*******************************************************************************
*
* FUNCTION: acpi_acquire_mutex
*
* PARAMETERS: handle - Mutex or prefix handle (optional)
* pathname - Mutex pathname (optional)
* timeout - Max time to wait for the lock (millisec)
*
* RETURN: Status
*
* DESCRIPTION: Acquire an AML mutex. This is a device driver interface to
* AML mutex objects, and allows for transaction locking between
* drivers and AML code. The mutex node is pointed to by
* Handle:Pathname. Either Handle or Pathname can be NULL, but
* not both.
*
******************************************************************************/
acpi_status
acpi_acquire_mutex(acpi_handle handle, acpi_string pathname, u16 timeout)
{
acpi_status status;
union acpi_operand_object *mutex_obj;
/* Get the low-level mutex associated with Handle:Pathname */
status = acpi_ut_get_mutex_object(handle, pathname, &mutex_obj);
if (ACPI_FAILURE(status)) {
return (status);
}
/* Acquire the OS mutex */
status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
return (status);
}
ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
/*******************************************************************************
*
* FUNCTION: acpi_release_mutex
*
* PARAMETERS: handle - Mutex or prefix handle (optional)
* pathname - Mutex pathname (optional)
*
* RETURN: Status
*
* DESCRIPTION: Release an AML mutex. This is a device driver interface to
* AML mutex objects, and allows for transaction locking between
* drivers and AML code. The mutex node is pointed to by
* Handle:Pathname. Either Handle or Pathname can be NULL, but
* not both.
*
******************************************************************************/
acpi_status acpi_release_mutex(acpi_handle handle, acpi_string pathname)
{
acpi_status status;
union acpi_operand_object *mutex_obj;
/* Get the low-level mutex associated with Handle:Pathname */
status = acpi_ut_get_mutex_object(handle, pathname, &mutex_obj);
if (ACPI_FAILURE(status)) {
return (status);
}
/* Release the OS mutex */
Annotation
- Immediate include surface: `acpi/acpi.h`, `accommon.h`, `acnamesp.h`.
- Detected declarations: `function acpi_ut_get_mutex_object`, `function acpi_acquire_mutex`, `function acpi_release_mutex`.
- 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.