drivers/iio/common/st_sensors/st_sensors_buffer.c
Source file repositories/reference/linux-study-clean/drivers/iio/common/st_sensors/st_sensors_buffer.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/iio/common/st_sensors/st_sensors_buffer.c- Extension
.c- Size
- 2216 bytes
- Lines
- 80
- Domain
- Driver Families
- Bucket
- drivers/iio
- 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.
- 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/kernel.hlinux/iio/iio.hlinux/iio/trigger.hlinux/interrupt.hlinux/iio/buffer.hlinux/iio/trigger_consumer.hlinux/irqreturn.hlinux/regmap.hlinux/iio/common/st_sensors.h
Detected Declarations
function st_sensors_get_buffer_elementfunction for_each_set_bitfunction st_sensors_trigger_handler
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0-only
/*
* STMicroelectronics sensors buffer library driver
*
* Copyright 2012-2013 STMicroelectronics Inc.
*
* Denis Ciocca <denis.ciocca@st.com>
*/
#include <linux/kernel.h>
#include <linux/iio/iio.h>
#include <linux/iio/trigger.h>
#include <linux/interrupt.h>
#include <linux/iio/buffer.h>
#include <linux/iio/trigger_consumer.h>
#include <linux/irqreturn.h>
#include <linux/regmap.h>
#include <linux/iio/common/st_sensors.h>
static int st_sensors_get_buffer_element(struct iio_dev *indio_dev, u8 *buf)
{
struct st_sensor_data *sdata = iio_priv(indio_dev);
unsigned int num_data_channels = sdata->num_data_channels;
int i;
for_each_set_bit(i, indio_dev->active_scan_mask, num_data_channels) {
const struct iio_chan_spec *channel = &indio_dev->channels[i];
unsigned int bytes_to_read =
DIV_ROUND_UP(channel->scan_type.realbits +
channel->scan_type.shift, 8);
unsigned int storage_bytes =
channel->scan_type.storagebits >> 3;
buf = PTR_ALIGN(buf, storage_bytes);
if (regmap_bulk_read(sdata->regmap, channel->address,
buf, bytes_to_read) < 0)
return -EIO;
/* Advance the buffer pointer */
buf += storage_bytes;
}
return 0;
}
irqreturn_t st_sensors_trigger_handler(int irq, void *p)
{
int len;
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf->indio_dev;
struct st_sensor_data *sdata = iio_priv(indio_dev);
s64 timestamp;
/*
* If we do timestamping here, do it before reading the values, because
* once we've read the values, new interrupts can occur (when using
* the hardware trigger) and the hw_timestamp may get updated.
* By storing it in a local variable first, we are safe.
*/
if (iio_trigger_using_own(indio_dev))
timestamp = sdata->hw_timestamp;
else
timestamp = iio_get_time_ns(indio_dev);
len = st_sensors_get_buffer_element(indio_dev, sdata->buffer_data);
if (len < 0)
goto st_sensors_get_buffer_element_error;
iio_push_to_buffers_with_timestamp(indio_dev, sdata->buffer_data,
timestamp);
st_sensors_get_buffer_element_error:
iio_trigger_notify_done(indio_dev->trig);
return IRQ_HANDLED;
}
EXPORT_SYMBOL_NS(st_sensors_trigger_handler, "IIO_ST_SENSORS");
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/iio/iio.h`, `linux/iio/trigger.h`, `linux/interrupt.h`, `linux/iio/buffer.h`, `linux/iio/trigger_consumer.h`, `linux/irqreturn.h`, `linux/regmap.h`.
- Detected declarations: `function st_sensors_get_buffer_element`, `function for_each_set_bit`, `function st_sensors_trigger_handler`.
- Atlas domain: Driver Families / drivers/iio.
- Implementation status: integration implementation candidate.
- 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.