drivers/fsi/i2cr-scom.c
Source file repositories/reference/linux-study-clean/drivers/fsi/i2cr-scom.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/fsi/i2cr-scom.c- Extension
.c- Size
- 3144 bytes
- Lines
- 152
- Domain
- Driver Families
- Bucket
- drivers/fsi
- Inferred role
- Driver Families: operation-table or driver-model contract
- Status
- pattern 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 an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- 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/cdev.hlinux/device.hlinux/fs.hlinux/fsi.hlinux/module.hlinux/mod_devicetable.hfsi-master-i2cr.hfsi-slave.h
Detected Declarations
struct i2cr_scomfunction i2cr_scom_llseekfunction i2cr_scom_readfunction i2cr_scom_writefunction i2cr_scom_probefunction i2cr_scom_remove
Annotated Snippet
static const struct file_operations i2cr_scom_fops = {
.owner = THIS_MODULE,
.open = simple_open,
.llseek = i2cr_scom_llseek,
.read = i2cr_scom_read,
.write = i2cr_scom_write,
};
static int i2cr_scom_probe(struct fsi_device *fsi_dev)
{
struct device *dev = &fsi_dev->dev;
struct i2cr_scom *scom;
int didx;
int ret;
if (!is_fsi_master_i2cr(fsi_dev->slave->master))
return -ENODEV;
scom = devm_kzalloc(dev, sizeof(*scom), GFP_KERNEL);
if (!scom)
return -ENOMEM;
scom->i2cr = to_fsi_master_i2cr(fsi_dev->slave->master);
dev_set_drvdata(dev, scom);
scom->dev.type = &fsi_cdev_type;
scom->dev.parent = dev;
device_initialize(&scom->dev);
ret = fsi_get_new_minor(fsi_dev, fsi_dev_scom, &scom->dev.devt, &didx);
if (ret)
return ret;
dev_set_name(&scom->dev, "scom%d", didx);
cdev_init(&scom->cdev, &i2cr_scom_fops);
ret = cdev_device_add(&scom->cdev, &scom->dev);
if (ret)
fsi_free_minor(scom->dev.devt);
return ret;
}
static void i2cr_scom_remove(struct fsi_device *fsi_dev)
{
struct i2cr_scom *scom = dev_get_drvdata(&fsi_dev->dev);
cdev_device_del(&scom->cdev, &scom->dev);
fsi_free_minor(scom->dev.devt);
}
static const struct of_device_id i2cr_scom_of_ids[] = {
{ .compatible = "ibm,i2cr-scom" },
{ }
};
MODULE_DEVICE_TABLE(of, i2cr_scom_of_ids);
static const struct fsi_device_id i2cr_scom_ids[] = {
{ 0x5, FSI_VERSION_ANY },
{ }
};
static struct fsi_driver i2cr_scom_driver = {
.probe = i2cr_scom_probe,
.remove = i2cr_scom_remove,
.id_table = i2cr_scom_ids,
.drv = {
.name = "i2cr_scom",
.of_match_table = i2cr_scom_of_ids,
}
};
module_fsi_driver(i2cr_scom_driver);
MODULE_AUTHOR("Eddie James <eajames@linux.ibm.com>");
MODULE_DESCRIPTION("IBM I2C Responder SCOM driver");
MODULE_LICENSE("GPL");
Annotation
- Immediate include surface: `linux/cdev.h`, `linux/device.h`, `linux/fs.h`, `linux/fsi.h`, `linux/module.h`, `linux/mod_devicetable.h`, `fsi-master-i2cr.h`, `fsi-slave.h`.
- Detected declarations: `struct i2cr_scom`, `function i2cr_scom_llseek`, `function i2cr_scom_read`, `function i2cr_scom_write`, `function i2cr_scom_probe`, `function i2cr_scom_remove`.
- Atlas domain: Driver Families / drivers/fsi.
- Implementation status: pattern implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
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.