drivers/iio/light/acpi-als.c
Source file repositories/reference/linux-study-clean/drivers/iio/light/acpi-als.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/iio/light/acpi-als.c- Extension
.c- Size
- 6586 bytes
- Lines
- 258
- Domain
- Driver Families
- Bucket
- drivers/iio
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/module.hlinux/acpi.hlinux/err.hlinux/irq.hlinux/mutex.hlinux/platform_device.hlinux/iio/iio.hlinux/iio/buffer.hlinux/iio/trigger.hlinux/iio/triggered_buffer.hlinux/iio/trigger_consumer.h
Detected Declarations
struct acpi_alsfunction acpi_als_read_valuefunction acpi_als_notifyfunction acpi_als_read_rawfunction acpi_als_trigger_handlerfunction acpi_als_probefunction acpi_als_remove
Annotated Snippet
struct acpi_als {
struct acpi_device *device;
struct mutex lock;
struct iio_trigger *trig;
};
/*
* All types of properties the ACPI0008 block can report. The ALI, ALC, ALT
* and ALP can all be handled by acpi_als_read_value() below, while the ALR is
* special.
*
* The _ALR property returns tables that can be used to fine-tune the values
* reported by the other props based on the particular hardware type and it's
* location (it contains tables for "rainy", "bright inhouse lighting" etc.).
*
* So far, we support only ALI (illuminance).
*/
#define ACPI_ALS_ILLUMINANCE "_ALI"
#define ACPI_ALS_CHROMATICITY "_ALC"
#define ACPI_ALS_COLOR_TEMP "_ALT"
#define ACPI_ALS_POLLING "_ALP"
#define ACPI_ALS_TABLES "_ALR"
static int acpi_als_read_value(struct acpi_als *als, char *prop, s32 *val)
{
unsigned long long temp_val;
acpi_status status;
status = acpi_evaluate_integer(als->device->handle, prop, NULL,
&temp_val);
if (ACPI_FAILURE(status)) {
acpi_evaluation_failure_warn(als->device->handle, prop, status);
return -EIO;
}
*val = temp_val;
return 0;
}
static void acpi_als_notify(acpi_handle handle, u32 event, void *data)
{
struct iio_dev *indio_dev = data;
struct acpi_als *als = iio_priv(indio_dev);
if (iio_buffer_enabled(indio_dev) && iio_trigger_using_own(indio_dev)) {
switch (event) {
case ACPI_ALS_NOTIFY_ILLUMINANCE:
iio_trigger_poll_nested(als->trig);
break;
default:
/* Unhandled event */
dev_dbg(&als->device->dev,
"Unhandled ACPI ALS event (%08x)!\n",
event);
}
}
}
static int acpi_als_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan, int *val,
int *val2, long mask)
{
struct acpi_als *als = iio_priv(indio_dev);
s32 temp_val;
int ret;
if ((mask != IIO_CHAN_INFO_PROCESSED) && (mask != IIO_CHAN_INFO_RAW))
return -EINVAL;
/* we support only illumination (_ALI) so far. */
if (chan->type != IIO_LIGHT)
return -EINVAL;
ret = acpi_als_read_value(als, ACPI_ALS_ILLUMINANCE, &temp_val);
if (ret < 0)
return ret;
*val = temp_val;
return IIO_VAL_INT;
}
static const struct iio_info acpi_als_info = {
.read_raw = acpi_als_read_raw,
};
static irqreturn_t acpi_als_trigger_handler(int irq, void *p)
{
Annotation
- Immediate include surface: `linux/module.h`, `linux/acpi.h`, `linux/err.h`, `linux/irq.h`, `linux/mutex.h`, `linux/platform_device.h`, `linux/iio/iio.h`, `linux/iio/buffer.h`.
- Detected declarations: `struct acpi_als`, `function acpi_als_read_value`, `function acpi_als_notify`, `function acpi_als_read_raw`, `function acpi_als_trigger_handler`, `function acpi_als_probe`, `function acpi_als_remove`.
- Atlas domain: Driver Families / drivers/iio.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.