drivers/hid/hid-pl.c
Source file repositories/reference/linux-study-clean/drivers/hid/hid-pl.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/hid-pl.c- Extension
.c- Size
- 5651 bytes
- Lines
- 225
- Domain
- Driver Families
- Bucket
- drivers/hid
- 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/input.hlinux/slab.hlinux/module.hlinux/hid.hhid-ids.h
Detected Declarations
struct plff_devicefunction hid_plff_playfunction plff_initfunction Zeroplusfunction list_for_each_entryfunction plff_initfunction pl_probe
Annotated Snippet
struct plff_device {
struct hid_report *report;
s32 maxval;
s32 *strong;
s32 *weak;
};
static int hid_plff_play(struct input_dev *dev, void *data,
struct ff_effect *effect)
{
struct hid_device *hid = input_get_drvdata(dev);
struct plff_device *plff = data;
int left, right;
left = effect->u.rumble.strong_magnitude;
right = effect->u.rumble.weak_magnitude;
hid_dbg(dev, "called with 0x%04x 0x%04x", left, right);
left = left * plff->maxval / 0xffff;
right = right * plff->maxval / 0xffff;
*plff->strong = left;
*plff->weak = right;
hid_dbg(dev, "running with 0x%02x 0x%02x", left, right);
hid_hw_request(hid, plff->report, HID_REQ_SET_REPORT);
return 0;
}
static int plff_init(struct hid_device *hid)
{
struct plff_device *plff;
struct hid_report *report;
struct hid_input *hidinput;
struct list_head *report_list =
&hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct list_head *report_ptr = report_list;
struct input_dev *dev;
int error;
s32 maxval;
s32 *strong;
s32 *weak;
/* The device contains one output report per physical device, all
containing 1 field, which contains 4 ff00.0002 usages and 4 16bit
absolute values.
The input reports also contain a field which contains
8 ff00.0001 usages and 8 boolean values. Their meaning is
currently unknown.
A version of the 0e8f:0003 exists that has all the values in
separate fields and misses the extra input field, thus resembling
Zeroplus (hid-zpff) devices.
*/
if (list_empty(report_list)) {
hid_err(hid, "no output reports found\n");
return -ENODEV;
}
list_for_each_entry(hidinput, &hid->inputs, list) {
report_ptr = report_ptr->next;
if (report_ptr == report_list) {
hid_err(hid, "required output report is missing\n");
return -ENODEV;
}
report = list_entry(report_ptr, struct hid_report, list);
if (report->maxfield < 1) {
hid_err(hid, "no fields in the report\n");
return -ENODEV;
}
maxval = 0x7f;
if (report->field[0]->report_count >= 4) {
report->field[0]->value[0] = 0x00;
report->field[0]->value[1] = 0x00;
strong = &report->field[0]->value[2];
weak = &report->field[0]->value[3];
hid_dbg(hid, "detected single-field device");
} else if (report->field[0]->maxusage == 1 &&
report->field[0]->usage[0].hid ==
(HID_UP_LED | 0x43) &&
report->maxfield >= 4 &&
report->field[0]->report_count >= 1 &&
report->field[1]->report_count >= 1 &&
report->field[2]->report_count >= 1 &&
Annotation
- Immediate include surface: `linux/input.h`, `linux/slab.h`, `linux/module.h`, `linux/hid.h`, `hid-ids.h`.
- Detected declarations: `struct plff_device`, `function hid_plff_play`, `function plff_init`, `function Zeroplus`, `function list_for_each_entry`, `function plff_init`, `function pl_probe`.
- Atlas domain: Driver Families / drivers/hid.
- 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.