drivers/hid/hid-vivaldi-common.c
Source file repositories/reference/linux-study-clean/drivers/hid/hid-vivaldi-common.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/hid-vivaldi-common.c- Extension
.c- Size
- 3750 bytes
- Lines
- 143
- Domain
- Driver Families
- Bucket
- drivers/hid
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration 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.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/export.hlinux/hid.hlinux/input/vivaldi-fmap.hlinux/kernel.hlinux/module.hlinux/types.hhid-vivaldi-common.h
Detected Declarations
function Copyrightfunction function_row_physmap_showfunction vivaldi_is_visibleexport vivaldi_feature_mappingexport vivaldi_attribute_groups
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0
/*
* Helpers for ChromeOS HID Vivaldi keyboards
*
* Copyright (C) 2022 Google, Inc
*/
#include <linux/export.h>
#include <linux/hid.h>
#include <linux/input/vivaldi-fmap.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
#include "hid-vivaldi-common.h"
#define MIN_FN_ROW_KEY 1
#define MAX_FN_ROW_KEY VIVALDI_MAX_FUNCTION_ROW_KEYS
#define HID_VD_FN_ROW_PHYSMAP 0x00000001
#define HID_USAGE_FN_ROW_PHYSMAP (HID_UP_GOOGLEVENDOR | HID_VD_FN_ROW_PHYSMAP)
/**
* vivaldi_feature_mapping - Fill out vivaldi keymap data exposed via HID
* @hdev: HID device to parse
* @field: HID field to parse
* @usage: HID usage to parse
*
* Note: this function assumes that driver data attached to @hdev contains an
* instance of &struct vivaldi_data at the very beginning.
*/
void vivaldi_feature_mapping(struct hid_device *hdev,
struct hid_field *field, struct hid_usage *usage)
{
struct vivaldi_data *data = hid_get_drvdata(hdev);
struct hid_report *report = field->report;
u8 *report_data, *buf;
u32 report_len;
unsigned int fn_key;
int ret;
if (field->logical != HID_USAGE_FN_ROW_PHYSMAP ||
(usage->hid & HID_USAGE_PAGE) != HID_UP_ORDINAL)
return;
fn_key = usage->hid & HID_USAGE;
if (fn_key < MIN_FN_ROW_KEY || fn_key > MAX_FN_ROW_KEY)
return;
if (fn_key > data->num_function_row_keys)
data->num_function_row_keys = fn_key;
report_data = buf = hid_alloc_report_buf(report, GFP_KERNEL);
if (!report_data)
return;
report_len = hid_report_len(report);
if (!report->id) {
/*
* hid_hw_raw_request() will stuff report ID (which will be 0)
* into the first byte of the buffer even for unnumbered
* reports, so we need to account for this to avoid getting
* -EOVERFLOW in return.
* Note that hid_alloc_report_buf() adds 7 bytes to the size
* so we can safely say that we have space for an extra byte.
*/
report_len++;
}
ret = hid_hw_raw_request(hdev, report->id, report_data,
report_len, HID_FEATURE_REPORT,
HID_REQ_GET_REPORT);
if (ret < 0) {
dev_warn(&hdev->dev, "failed to fetch feature %d\n",
field->report->id);
goto out;
}
if (!report->id) {
/*
* Undo the damage from hid_hw_raw_request() for unnumbered
* reports.
*/
report_data++;
report_len--;
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, report_data,
report_len, report_len, 0);
if (ret) {
dev_warn(&hdev->dev, "failed to report feature %d\n",
Annotation
- Immediate include surface: `linux/export.h`, `linux/hid.h`, `linux/input/vivaldi-fmap.h`, `linux/kernel.h`, `linux/module.h`, `linux/types.h`, `hid-vivaldi-common.h`.
- Detected declarations: `function Copyright`, `function function_row_physmap_show`, `function vivaldi_is_visible`, `export vivaldi_feature_mapping`, `export vivaldi_attribute_groups`.
- Atlas domain: Driver Families / drivers/hid.
- Implementation status: integration 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.