drivers/input/misc/da9052_onkey.c
Source file repositories/reference/linux-study-clean/drivers/input/misc/da9052_onkey.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/input/misc/da9052_onkey.c- Extension
.c- Size
- 3640 bytes
- Lines
- 154
- 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/input.hlinux/module.hlinux/platform_device.hlinux/workqueue.hlinux/mfd/da9052/da9052.hlinux/mfd/da9052/reg.h
Detected Declarations
struct da9052_onkeyfunction da9052_onkey_queryfunction da9052_onkey_workfunction da9052_onkey_irqfunction da9052_onkey_probefunction da9052_onkey_remove
Annotated Snippet
struct da9052_onkey {
struct da9052 *da9052;
struct input_dev *input;
struct delayed_work work;
};
static void da9052_onkey_query(struct da9052_onkey *onkey)
{
int ret;
ret = da9052_reg_read(onkey->da9052, DA9052_STATUS_A_REG);
if (ret < 0) {
dev_err(onkey->da9052->dev,
"Failed to read onkey event err=%d\n", ret);
} else {
/*
* Since interrupt for deassertion of ONKEY pin is not
* generated, onkey event state determines the onkey
* button state.
*/
bool pressed = !(ret & DA9052_STATUSA_NONKEY);
input_report_key(onkey->input, KEY_POWER, pressed);
input_sync(onkey->input);
/*
* Interrupt is generated only when the ONKEY pin
* is asserted. Hence the deassertion of the pin
* is simulated through work queue.
*/
if (pressed)
schedule_delayed_work(&onkey->work,
msecs_to_jiffies(50));
}
}
static void da9052_onkey_work(struct work_struct *work)
{
struct da9052_onkey *onkey = container_of(work, struct da9052_onkey,
work.work);
da9052_onkey_query(onkey);
}
static irqreturn_t da9052_onkey_irq(int irq, void *data)
{
struct da9052_onkey *onkey = data;
da9052_onkey_query(onkey);
return IRQ_HANDLED;
}
static int da9052_onkey_probe(struct platform_device *pdev)
{
struct da9052 *da9052 = dev_get_drvdata(pdev->dev.parent);
struct da9052_onkey *onkey;
struct input_dev *input_dev;
int error;
if (!da9052) {
dev_err(&pdev->dev, "Failed to get the driver's data\n");
return -EINVAL;
}
onkey = kzalloc_obj(*onkey);
input_dev = input_allocate_device();
if (!onkey || !input_dev) {
dev_err(&pdev->dev, "Failed to allocate memory\n");
error = -ENOMEM;
goto err_free_mem;
}
onkey->input = input_dev;
onkey->da9052 = da9052;
INIT_DELAYED_WORK(&onkey->work, da9052_onkey_work);
input_dev->name = "da9052-onkey";
input_dev->phys = "da9052-onkey/input0";
input_dev->dev.parent = &pdev->dev;
input_dev->evbit[0] = BIT_MASK(EV_KEY);
__set_bit(KEY_POWER, input_dev->keybit);
error = da9052_request_irq(onkey->da9052, DA9052_IRQ_NONKEY, "ONKEY",
da9052_onkey_irq, onkey);
if (error < 0) {
dev_err(onkey->da9052->dev,
"Failed to register ONKEY IRQ: %d\n", error);
goto err_free_mem;
Annotation
- Immediate include surface: `linux/input.h`, `linux/module.h`, `linux/platform_device.h`, `linux/workqueue.h`, `linux/mfd/da9052/da9052.h`, `linux/mfd/da9052/reg.h`.
- Detected declarations: `struct da9052_onkey`, `function da9052_onkey_query`, `function da9052_onkey_work`, `function da9052_onkey_irq`, `function da9052_onkey_probe`, `function da9052_onkey_remove`.
- 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.