drivers/input/joystick/stinger.c
Source file repositories/reference/linux-study-clean/drivers/input/joystick/stinger.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/input/joystick/stinger.c- Extension
.c- Size
- 4638 bytes
- Lines
- 192
- 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/kernel.hlinux/module.hlinux/slab.hlinux/input.hlinux/serio.h
Detected Declarations
struct stingerfunction stinger_process_packetfunction stinger_interruptfunction stinger_disconnectfunction stinger_connect
Annotated Snippet
struct stinger {
struct input_dev *dev;
int idx;
unsigned char data[STINGER_MAX_LENGTH];
char phys[32];
};
/*
* stinger_process_packet() decodes packets the driver receives from the
* Stinger. It updates the data accordingly.
*/
static void stinger_process_packet(struct stinger *stinger)
{
struct input_dev *dev = stinger->dev;
unsigned char *data = stinger->data;
if (!stinger->idx) return;
input_report_key(dev, BTN_A, ((data[0] & 0x20) >> 5));
input_report_key(dev, BTN_B, ((data[0] & 0x10) >> 4));
input_report_key(dev, BTN_C, ((data[0] & 0x08) >> 3));
input_report_key(dev, BTN_X, ((data[0] & 0x04) >> 2));
input_report_key(dev, BTN_Y, ((data[3] & 0x20) >> 5));
input_report_key(dev, BTN_Z, ((data[3] & 0x10) >> 4));
input_report_key(dev, BTN_TL, ((data[3] & 0x08) >> 3));
input_report_key(dev, BTN_TR, ((data[3] & 0x04) >> 2));
input_report_key(dev, BTN_SELECT, ((data[3] & 0x02) >> 1));
input_report_key(dev, BTN_START, (data[3] & 0x01));
input_report_abs(dev, ABS_X, (data[1] & 0x3F) - ((data[0] & 0x01) << 6));
input_report_abs(dev, ABS_Y, ((data[0] & 0x02) << 5) - (data[2] & 0x3F));
input_sync(dev);
return;
}
/*
* stinger_interrupt() is called by the low level driver when characters
* are ready for us. We then buffer them for further processing, or call the
* packet processing routine.
*/
static irqreturn_t stinger_interrupt(struct serio *serio,
unsigned char data, unsigned int flags)
{
struct stinger *stinger = serio_get_drvdata(serio);
/* All Stinger packets are 4 bytes */
if (stinger->idx < STINGER_MAX_LENGTH)
stinger->data[stinger->idx++] = data;
if (stinger->idx == 4) {
stinger_process_packet(stinger);
stinger->idx = 0;
}
return IRQ_HANDLED;
}
/*
* stinger_disconnect() is the opposite of stinger_connect()
*/
static void stinger_disconnect(struct serio *serio)
{
struct stinger *stinger = serio_get_drvdata(serio);
serio_close(serio);
serio_set_drvdata(serio, NULL);
input_unregister_device(stinger->dev);
kfree(stinger);
}
/*
* stinger_connect() is the routine that is called when someone adds a
* new serio device that supports Stinger protocol and registers it as
* an input device.
*/
static int stinger_connect(struct serio *serio, struct serio_driver *drv)
{
struct stinger *stinger;
struct input_dev *input_dev;
int err = -ENOMEM;
stinger = kmalloc_obj(*stinger);
input_dev = input_allocate_device();
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/module.h`, `linux/slab.h`, `linux/input.h`, `linux/serio.h`.
- Detected declarations: `struct stinger`, `function stinger_process_packet`, `function stinger_interrupt`, `function stinger_disconnect`, `function stinger_connect`.
- 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.