drivers/hid/hid-winwing.c
Source file repositories/reference/linux-study-clean/drivers/hid/hid-winwing.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/hid-winwing.c- Extension
.c- Size
- 9053 bytes
- Lines
- 437
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- 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/device.hlinux/hid.hlinux/hidraw.hlinux/kernel.hlinux/module.hlinux/mutex.hlinux/workqueue.h
Detected Declarations
struct winwing_ledstruct winwing_led_infostruct winwing_drv_datafunction winwing_led_writefunction winwing_init_ledfunction winwing_map_buttonfunction winwing_input_mappingfunction convert_magnitudefunction winwing_haptic_rumblefunction winwing_haptic_rumble_cbfunction winwing_play_effectfunction winwing_init_fffunction winwing_probefunction winwing_removefunction winwing_input_configured
Annotated Snippet
struct winwing_led {
struct led_classdev cdev;
struct hid_device *hdev;
int number;
};
struct winwing_led_info {
int number;
int max_brightness;
const char *led_name;
};
static const struct winwing_led_info led_info[3] = {
{ 0, 255, "backlight" },
{ 1, 1, "a-a" },
{ 2, 1, "a-g" },
};
struct winwing_drv_data {
struct hid_device *hdev;
struct mutex lights_lock;
__u8 *report_lights;
__u8 *report_rumble;
struct work_struct rumble_work;
struct ff_rumble_effect rumble;
int rumble_left;
int rumble_right;
int has_grip15;
struct winwing_led leds[];
};
static int winwing_led_write(struct led_classdev *cdev,
enum led_brightness br)
{
struct winwing_led *led = (struct winwing_led *) cdev;
struct winwing_drv_data *data = hid_get_drvdata(led->hdev);
__u8 *buf = data->report_lights;
int ret;
mutex_lock(&data->lights_lock);
/*
* Mimicking requests captured by usbmon when LEDs
* are controlled by the vendor's app in a VM.
*/
buf[0] = 0x02;
buf[1] = 0x60;
buf[2] = 0xbe;
buf[3] = 0x00;
buf[4] = 0x00;
buf[5] = 0x03;
buf[6] = 0x49;
buf[7] = led->number;
buf[8] = br;
buf[9] = 0x00;
buf[10] = 0;
buf[11] = 0;
buf[12] = 0;
buf[13] = 0;
ret = hid_hw_output_report(led->hdev, buf, 14);
mutex_unlock(&data->lights_lock);
return ret;
}
static int winwing_init_led(struct hid_device *hdev,
struct input_dev *input)
{
struct winwing_drv_data *data;
struct winwing_led *led;
int ret;
int i;
data = hid_get_drvdata(hdev);
if (!data)
return -EINVAL;
data->report_lights = devm_kzalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
if (!data->report_lights)
return -ENOMEM;
for (i = 0; i < 3; i += 1) {
const struct winwing_led_info *info = &led_info[i];
led = &data->leds[i];
led->hdev = hdev;
Annotation
- Immediate include surface: `linux/device.h`, `linux/hid.h`, `linux/hidraw.h`, `linux/kernel.h`, `linux/module.h`, `linux/mutex.h`, `linux/workqueue.h`.
- Detected declarations: `struct winwing_led`, `struct winwing_led_info`, `struct winwing_drv_data`, `function winwing_led_write`, `function winwing_init_led`, `function winwing_map_button`, `function winwing_input_mapping`, `function convert_magnitude`, `function winwing_haptic_rumble`, `function winwing_haptic_rumble_cb`.
- Atlas domain: Driver Families / drivers/hid.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.