drivers/acpi/acpica/utlock.c
Source file repositories/reference/linux-study-clean/drivers/acpi/acpica/utlock.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/acpi/acpica/utlock.c- Extension
.c- Size
- 4001 bytes
- Lines
- 142
- Domain
- Driver Families
- Bucket
- drivers/acpi
- Inferred role
- Driver Families: implementation source
- Status
- source 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
acpi/acpi.haccommon.h
Detected Declarations
function Copyrightfunction acpi_ut_delete_rw_lockfunction tofunction acpi_ut_release_read_lockfunction acpi_ut_acquire_write_lockfunction acpi_ut_release_write_lock
Annotated Snippet
// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
/******************************************************************************
*
* Module Name: utlock - Reader/Writer lock interfaces
*
* Copyright (C) 2000 - 2026, Intel Corp.
*
*****************************************************************************/
#include <acpi/acpi.h>
#include "accommon.h"
#define _COMPONENT ACPI_UTILITIES
ACPI_MODULE_NAME("utlock")
/*******************************************************************************
*
* FUNCTION: acpi_ut_create_rw_lock
* acpi_ut_delete_rw_lock
*
* PARAMETERS: lock - Pointer to a valid RW lock
*
* RETURN: Status
*
* DESCRIPTION: Reader/writer lock creation and deletion interfaces.
*
******************************************************************************/
acpi_status acpi_ut_create_rw_lock(struct acpi_rw_lock *lock)
{
acpi_status status;
lock->num_readers = 0;
status = acpi_os_create_mutex(&lock->reader_mutex);
if (ACPI_FAILURE(status)) {
return (status);
}
status = acpi_os_create_mutex(&lock->writer_mutex);
return (status);
}
void acpi_ut_delete_rw_lock(struct acpi_rw_lock *lock)
{
acpi_os_delete_mutex(lock->reader_mutex);
acpi_os_delete_mutex(lock->writer_mutex);
lock->num_readers = 0;
lock->reader_mutex = NULL;
lock->writer_mutex = NULL;
}
/*******************************************************************************
*
* FUNCTION: acpi_ut_acquire_read_lock
* acpi_ut_release_read_lock
*
* PARAMETERS: lock - Pointer to a valid RW lock
*
* RETURN: Status
*
* DESCRIPTION: Reader interfaces for reader/writer locks. On acquisition,
* only the first reader acquires the write mutex. On release,
* only the last reader releases the write mutex. Although this
* algorithm can in theory starve writers, this should not be a
* problem with ACPICA since the subsystem is infrequently used
* in comparison to (for example) an I/O system.
*
******************************************************************************/
acpi_status acpi_ut_acquire_read_lock(struct acpi_rw_lock *lock)
{
acpi_status status;
status = acpi_os_acquire_mutex(lock->reader_mutex, ACPI_WAIT_FOREVER);
if (ACPI_FAILURE(status)) {
return (status);
}
/* Acquire the write lock only for the first reader */
lock->num_readers++;
if (lock->num_readers == 1) {
status =
acpi_os_acquire_mutex(lock->writer_mutex,
ACPI_WAIT_FOREVER);
}
acpi_os_release_mutex(lock->reader_mutex);
return (status);
Annotation
- Immediate include surface: `acpi/acpi.h`, `accommon.h`.
- Detected declarations: `function Copyright`, `function acpi_ut_delete_rw_lock`, `function to`, `function acpi_ut_release_read_lock`, `function acpi_ut_acquire_write_lock`, `function acpi_ut_release_write_lock`.
- Atlas domain: Driver Families / drivers/acpi.
- Implementation status: source 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.