drivers/iio/imu/bmi323/bmi323_i2c.c
Source file repositories/reference/linux-study-clean/drivers/iio/imu/bmi323/bmi323_i2c.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/iio/imu/bmi323/bmi323_i2c.c- Extension
.c- Size
- 4018 bytes
- Lines
- 144
- 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.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/i2c.hlinux/mod_devicetable.hlinux/module.hlinux/regmap.hbmi323.h
Detected Declarations
struct bmi323_i2c_privfunction bmi323_regmap_i2c_readfunction bmi323_regmap_i2c_writefunction bmi323_i2c_probe
Annotated Snippet
struct bmi323_i2c_priv {
struct i2c_client *i2c;
u8 i2c_rx_buffer[BMI323_FIFO_LENGTH_IN_BYTES + BMI323_I2C_DUMMY];
};
/*
* From BMI323 datasheet section 4: Notes on the Serial Interface Support.
* Each I2C register read operation requires to read two dummy bytes before
* the actual payload.
*/
static int bmi323_regmap_i2c_read(void *context, const void *reg_buf,
size_t reg_size, void *val_buf,
size_t val_size)
{
struct bmi323_i2c_priv *priv = context;
struct i2c_msg msgs[2];
int ret;
msgs[0].addr = priv->i2c->addr;
msgs[0].flags = priv->i2c->flags;
msgs[0].len = reg_size;
msgs[0].buf = (u8 *)reg_buf;
msgs[1].addr = priv->i2c->addr;
msgs[1].len = val_size + BMI323_I2C_DUMMY;
msgs[1].buf = priv->i2c_rx_buffer;
msgs[1].flags = priv->i2c->flags | I2C_M_RD;
ret = i2c_transfer(priv->i2c->adapter, msgs, ARRAY_SIZE(msgs));
if (ret < 0)
return -EIO;
memcpy(val_buf, priv->i2c_rx_buffer + BMI323_I2C_DUMMY, val_size);
return 0;
}
static int bmi323_regmap_i2c_write(void *context, const void *data,
size_t count)
{
struct bmi323_i2c_priv *priv = context;
u8 reg;
reg = *(u8 *)data;
return i2c_smbus_write_i2c_block_data(priv->i2c, reg,
count - sizeof(u8),
data + sizeof(u8));
}
static const struct regmap_bus bmi323_regmap_bus = {
.read = bmi323_regmap_i2c_read,
.write = bmi323_regmap_i2c_write,
};
static const struct regmap_config bmi323_i2c_regmap_config = {
.reg_bits = 8,
.val_bits = 16,
.max_register = BMI323_CFG_RES_REG,
.val_format_endian = REGMAP_ENDIAN_LITTLE,
};
static int bmi323_i2c_probe(struct i2c_client *i2c)
{
struct device *dev = &i2c->dev;
struct bmi323_i2c_priv *priv;
struct regmap *regmap;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
priv->i2c = i2c;
regmap = devm_regmap_init(dev, &bmi323_regmap_bus, priv,
&bmi323_i2c_regmap_config);
if (IS_ERR(regmap))
return dev_err_probe(dev, PTR_ERR(regmap),
"Failed to initialize I2C Regmap\n");
return bmi323_core_probe(dev);
}
static const struct acpi_device_id bmi323_acpi_match[] = {
/*
* The "BOSC0200" identifier used here is not unique to bmi323 devices.
* The same "BOSC0200" identifier is found in the ACPI tables of devices
* using the bmc150 chip. This creates a conflict with duplicate ACPI
* identifiers which multiple drivers want to use. If a non-bmi323
* device starts to load with this "BOSC0200" ACPI match here, then the
* chip ID check portion should fail because the chip IDs received (via
* i2c) are unique between bmc150 and bmi323 and the driver should
Annotation
- Immediate include surface: `linux/i2c.h`, `linux/mod_devicetable.h`, `linux/module.h`, `linux/regmap.h`, `bmi323.h`.
- Detected declarations: `struct bmi323_i2c_priv`, `function bmi323_regmap_i2c_read`, `function bmi323_regmap_i2c_write`, `function bmi323_i2c_probe`.
- Atlas domain: Driver Families / drivers/iio.
- 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.