drivers/input/misc/cpcap-pwrbutton.c
Source file repositories/reference/linux-study-clean/drivers/input/misc/cpcap-pwrbutton.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/input/misc/cpcap-pwrbutton.c- Extension
.c- Size
- 2677 bytes
- Lines
- 113
- Domain
- Driver Families
- Bucket
- drivers/input
- 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- 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/module.hlinux/init.hlinux/kernel.hlinux/errno.hlinux/input.hlinux/interrupt.hlinux/regmap.hlinux/of.hlinux/platform_device.hlinux/mfd/motorola-cpcap.h
Detected Declarations
struct cpcap_power_buttonfunction powerbutton_irqfunction cpcap_power_button_probe
Annotated Snippet
struct cpcap_power_button {
struct regmap *regmap;
struct input_dev *idev;
struct device *dev;
};
static irqreturn_t powerbutton_irq(int irq, void *_button)
{
struct cpcap_power_button *button = _button;
int val;
val = cpcap_sense_virq(button->regmap, irq);
if (val < 0) {
dev_err(button->dev, "irq read failed: %d", val);
return IRQ_HANDLED;
}
pm_wakeup_event(button->dev, 0);
input_report_key(button->idev, KEY_POWER, val);
input_sync(button->idev);
return IRQ_HANDLED;
}
static int cpcap_power_button_probe(struct platform_device *pdev)
{
struct cpcap_power_button *button;
int irq;
int err;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
button = devm_kmalloc(&pdev->dev, sizeof(*button), GFP_KERNEL);
if (!button)
return -ENOMEM;
button->idev = devm_input_allocate_device(&pdev->dev);
if (!button->idev)
return -ENOMEM;
button->regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!button->regmap)
return -ENODEV;
button->dev = &pdev->dev;
button->idev->name = "cpcap-pwrbutton";
button->idev->phys = "cpcap-pwrbutton/input0";
input_set_capability(button->idev, EV_KEY, KEY_POWER);
err = devm_request_threaded_irq(&pdev->dev, irq, NULL,
powerbutton_irq, IRQF_ONESHOT, "cpcap_pwrbutton", button);
if (err < 0) {
dev_err(&pdev->dev, "IRQ request failed: %d\n", err);
return err;
}
err = input_register_device(button->idev);
if (err) {
dev_err(&pdev->dev, "Input register failed: %d\n", err);
return err;
}
device_init_wakeup(&pdev->dev, true);
return 0;
}
#ifdef CONFIG_OF
static const struct of_device_id cpcap_pwrbutton_dt_match_table[] = {
{ .compatible = "motorola,cpcap-pwrbutton" },
{},
};
MODULE_DEVICE_TABLE(of, cpcap_pwrbutton_dt_match_table);
#endif
static struct platform_driver cpcap_power_button_driver = {
.probe = cpcap_power_button_probe,
.driver = {
.name = "cpcap-pwrbutton",
.of_match_table = of_match_ptr(cpcap_pwrbutton_dt_match_table),
},
};
module_platform_driver(cpcap_power_button_driver);
MODULE_ALIAS("platform:cpcap-pwrbutton");
MODULE_DESCRIPTION("CPCAP Power Button");
MODULE_LICENSE("GPL");
Annotation
- Immediate include surface: `linux/module.h`, `linux/init.h`, `linux/kernel.h`, `linux/errno.h`, `linux/input.h`, `linux/interrupt.h`, `linux/regmap.h`, `linux/of.h`.
- Detected declarations: `struct cpcap_power_button`, `function powerbutton_irq`, `function cpcap_power_button_probe`.
- Atlas domain: Driver Families / drivers/input.
- Implementation status: source 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.