* Re: [PATCH 04/10] dt-bindings: input: apple: Add DockChannel HID transport
From: sashiko-bot @ 2026-06-30 13:10 UTC (permalink / raw)
To: Michael Reeves via B4 Relay
Cc: conor+dt, linux-input, devicetree, robh, dmitry.torokhov
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-4-506d936a1707@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The custom property `hid-country-code` lacks a vendor prefix.
--
commit 0afec3dbb1ad0bf9e9d68a29699cf412f978e322
Author: Michael Reeves <michael.reeves077@gmail.com>
dt-bindings: input: apple: Add DockChannel HID transport
This commit adds the device tree binding schema for the Apple DockChannel HID
transport. It defines the required properties including mailboxes, IOMMUs,
and an optional keyboard child node for layout variants.
> diff --git a/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
> new file mode 100644
> index 0000000000000..dbba4fc389710
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
[ ... ]
> + keyboard:
> + type: object
> + properties:
> + hid-country-code:
[Severity: Low]
Should this custom property include a vendor prefix? Hardware-specific
properties not defined in a generic schema generally require a vendor prefix
(like apple,hid-country-code) to prevent future namespace collisions.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + HID country code for the keyboard layout variant.
> +
> + additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-apple-mtp-keyboard-final-v1-0-506d936a1707@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 08/10] HID: apple: Add DockChannel HID transport driver
From: Yureka Lilian @ 2026-06-30 13:21 UTC (permalink / raw)
To: michael.reeves077, Sven Peter, Janne Grunau, Neal Gompa,
Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hector Martin, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires
Cc: asahi, linux-arm-kernel, linux-kernel, devicetree, iommu,
linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-8-506d936a1707@gmail.com>
On 6/30/26 14:54, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> Apple MTP exposes internal keyboard and trackpad interfaces over a HID
> transport carried by DockChannel.
>
> Add a transport driver that boots the MTP RTKit coprocessor, exchanges
> HID packets through the DockChannel mailbox, and registers child HID
> interfaces from devicetree.
>
> Co-developed-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/hid/Kconfig | 2 +
> drivers/hid/Makefile | 2 +
> drivers/hid/dockchannel/Kconfig | 15 +
> drivers/hid/dockchannel/Makefile | 3 +
> drivers/hid/dockchannel/apple-hid.c | 1130 +++++++++++++++++++++++++++++++++++
> 6 files changed, 1153 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed68452c0ad6..0063276f0349 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2620,6 +2620,7 @@ F: drivers/clk/clk-apple-nco.c
> F: drivers/cpufreq/apple-soc-cpufreq.c
> F: drivers/dma/apple-admac.c
> F: drivers/gpio/gpio-macsmc.c
> +F: drivers/hid/dockchannel/
> F: drivers/hwmon/macsmc-hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index f9bcaeb66385..f27cda601ede 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1488,6 +1488,8 @@ source "drivers/hid/surface-hid/Kconfig"
>
> source "drivers/hid/intel-thc-hid/Kconfig"
>
> +source "drivers/hid/dockchannel/Kconfig"
> +
> endif # HID
>
> # USB support may be used with HID disabled
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 23e6e3dd0c56..c9b4b1aff247 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -182,3 +182,5 @@ obj-$(CONFIG_AMD_SFH_HID) += amd-sfh-hid/
> obj-$(CONFIG_SURFACE_HID_CORE) += surface-hid/
>
> obj-$(CONFIG_INTEL_THC_HID) += intel-thc-hid/
> +
> +obj-$(CONFIG_APPLE_DOCKCHANNEL_HID) += dockchannel/
> diff --git a/drivers/hid/dockchannel/Kconfig b/drivers/hid/dockchannel/Kconfig
> new file mode 100644
> index 000000000000..fca09ef74403
> --- /dev/null
> +++ b/drivers/hid/dockchannel/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR MIT
> +
> +config APPLE_DOCKCHANNEL_HID
> + tristate "HID over Apple DockChannel"
> + depends on APPLE_DOCKCHANNEL
> + depends on APPLE_RTKIT
> + depends on HID
> + depends on INPUT
> + depends on OF
> + help
> + This provides a HID transport layer over the Apple DockChannel
> + mailbox interface. It is required to support the internal keyboard
> + and trackpad on M2 and later MacBook models.
> +
> + Say Y here if you have an M2 or later Apple MacBook.
> diff --git a/drivers/hid/dockchannel/Makefile b/drivers/hid/dockchannel/Makefile
> new file mode 100644
> index 000000000000..d1a82aa57a69
> --- /dev/null
> +++ b/drivers/hid/dockchannel/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR MIT
> +
> +obj-$(CONFIG_APPLE_DOCKCHANNEL_HID) += apple-hid.o
> diff --git a/drivers/hid/dockchannel/apple-hid.c b/drivers/hid/dockchannel/apple-hid.c
> new file mode 100644
> index 000000000000..162fcfb5ab1c
> --- /dev/null
> +++ b/drivers/hid/dockchannel/apple-hid.c
> @@ -0,0 +1,1130 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple DockChannel HID transport driver
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/completion.h>
> +#include <linux/ctype.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/hid.h>
> +#include <linux/mailbox/apple-dockchannel.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/soc/apple/rtkit.h>
> +#include <linux/spinlock.h>
> +#include <linux/string.h>
> +#include <linux/unaligned.h>
> +#include <linux/workqueue.h>
> +
> +#define APPLE_ASC_CPU_CONTROL 0x44
> +#define APPLE_ASC_CPU_CONTROL_RUN BIT(4)
> +
> +#define COMMAND_TIMEOUT_MS 1000
> +#define START_TIMEOUT_MS 2000
> +
> +#define MAX_INTERFACES 16
> +
> +#define DCHID_MAX_PAYLOAD 0xffff
> +#define DCHID_CHECKSUM_LEN 4
> +#define DCHID_RX_BUF_SIZE (sizeof(struct dchid_hdr) + DCHID_MAX_PAYLOAD + \
> + DCHID_CHECKSUM_LEN)
> +
> +#define DCHID_CHANNEL_CMD 0x11
> +#define DCHID_CHANNEL_REPORT 0x12
> +#define DCHID_CHECKSUM_SEED 0xffffffff
> +
> +struct dchid_hdr {
> + u8 hdr_len;
> + u8 channel;
> + __le16 length;
> + u8 seq;
> + u8 iface;
> + __le16 pad;
> +} __packed;
> +
> +#define IFACE_COMM 0
> +
> +#define FLAGS_GROUP GENMASK(7, 6)
> +#define FLAGS_REQ GENMASK(5, 0)
> +
> +#define REQ_SET_REPORT 0
> +#define REQ_GET_REPORT 1
> +
> +struct dchid_subhdr {
> + u8 flags;
> + u8 unk;
> + __le16 length;
> + __le32 retcode;
> +} __packed;
> +
> +#define EVENT_INIT 0xf0
> +#define EVENT_READY 0xf1
> +
> +struct dchid_init_hdr {
> + u8 type;
> + u8 unk1;
> + u8 unk2;
> + u8 iface;
> + char name[16];
> + u8 more_packets;
> + u8 unkpad;
> +} __packed;
> +
> +#define INIT_HID_DESCRIPTOR 0
> +#define INIT_TERMINATOR 2
> +#define INIT_PRODUCT_NAME 7
> +
> +#define CMD_RESET_INTERFACE 0x40
> +#define CMD_RESET_INTERFACE_SUB 1
> +#define CMD_ENABLE_INTERFACE 0xb4
> +
> +struct dchid_init_block_hdr {
> + __le16 type;
> + __le16 length;
> +} __packed;
> +
> +#define STM_REPORT_ID 0x10
> +#define STM_REPORT_SERIAL 0x11
> +
> +struct dchid_stm_id {
> + u8 unk;
> + __le16 vendor_id;
> + __le16 product_id;
> + __le16 version_number;
> + u8 unk2;
> + u8 unk3;
> + u8 keyboard_type;
> + u8 serial_length;
> + /* Serial follows, but we grab it with a different report. */
> +} __packed;
> +
> +struct dchid_work {
> + struct work_struct work;
> + struct dchid_iface *iface;
> +
> + struct dchid_hdr hdr;
> + u8 data[];
> +};
> +
> +struct dchid_iface {
> + struct dchid_dev *dchid;
> + struct hid_device *hid;
> + struct workqueue_struct *wq;
> +
> + bool creating;
> + struct work_struct create_work;
> +
> + int index;
> + const char *name;
> + struct fwnode_handle *fwnode;
> +
> + u8 tx_seq;
> + bool deferred;
> + bool starting;
> + bool open;
> + struct completion ready;
> +
> + void *hid_desc;
> + size_t hid_desc_len;
> +
> + /* Lock for command submission state below */
> + spinlock_t out_lock;
> + u32 out_flags;
> + int out_report;
> + u32 retcode;
> + void *resp_buf;
> + size_t resp_size;
> + struct completion out_complete;
> +};
> +
> +struct dchid_dev {
> + struct device *dev;
> + struct mbox_client dc_mbox_client;
> + struct mbox_chan *dc_mbox;
> +
> + struct apple_rtkit *rtk;
> + void __iomem *asc_base;
> + void __iomem *sram_base;
> + struct resource sram_res;
> +
> + bool id_ready;
> + struct dchid_stm_id device_id;
> + char serial[64];
> +
> + u8 *rx_buf;
> + size_t rx_len;
> +
> + struct dchid_iface *comm;
> + struct mutex ifaces_lock; /* protects ifaces array */
> + struct dchid_iface *ifaces[MAX_INTERFACES];
> +
> + /* Workqueue to asynchronously create HID devices */
> + struct workqueue_struct *new_iface_wq;
> +};
> +
> +static void dchid_destroy_wq(void *data)
> +{
> + struct workqueue_struct *wq = data;
> +
> + destroy_workqueue(wq);
> +}
> +
> +static void dchid_fwnode_release(void *data)
> +{
> + fwnode_handle_put(data);
> +}
> +
> +static void dchid_free_mbox(void *data)
> +{
> + mbox_free_channel(data);
> +}
> +
> +static u32 dchid_checksum(const void *data, size_t len)
> +{
> + const u8 *p = data;
> + u32 sum = 0;
> + int i;
> +
> + while (len >= sizeof(u32)) {
> + sum += get_unaligned_le32(p);
> + p += sizeof(u32);
> + len -= sizeof(u32);
> + }
> +
> + if (len) {
> + u32 tmp = 0;
> +
> + for (i = 0; i < len; i++)
> + tmp |= p[i] << (i * 8);
> + sum += tmp;
> + }
> +
> + return sum;
> +}
> +
> +static struct dchid_iface *
> +dchid_get_interface(struct dchid_dev *dchid, int index, const char *name)
> +{
> + struct dchid_iface *iface;
> + struct fwnode_handle *fwnode;
> + int ret;
> +
> + if (index >= MAX_INTERFACES) {
> + dev_err(dchid->dev, "interface index %d out of range\n", index);
> + return NULL;
> + }
> +
> + mutex_lock(&dchid->ifaces_lock);
> + if (dchid->ifaces[index]) {
> + iface = dchid->ifaces[index];
> + mutex_unlock(&dchid->ifaces_lock);
> + return iface;
> + }
> +
> + iface = devm_kzalloc(dchid->dev, sizeof(*iface), GFP_KERNEL);
> + if (!iface) {
> + mutex_unlock(&dchid->ifaces_lock);
> + return NULL;
> + }
> +
> + iface->index = index;
> + iface->name = devm_kstrdup(dchid->dev, name, GFP_KERNEL);
> + if (!iface->name) {
> + mutex_unlock(&dchid->ifaces_lock);
> + return NULL;
> + }
> +
> + iface->dchid = dchid;
> + iface->out_report = -1;
> + init_completion(&iface->out_complete);
> + init_completion(&iface->ready);
> + spin_lock_init(&iface->out_lock);
> +
> + iface->wq = alloc_ordered_workqueue("dchid-%s", 0, iface->name);
> + if (!iface->wq) {
> + mutex_unlock(&dchid->ifaces_lock);
> + return NULL;
> + }
> +
> + ret = devm_add_action_or_reset(dchid->dev, dchid_destroy_wq, iface->wq);
> + if (ret) {
> + mutex_unlock(&dchid->ifaces_lock);
> + return NULL;
> + }
> +
> + if (!strcmp(name, "comm")) {
> + /* Comm is not a HID subdevice */
> + dchid->ifaces[index] = iface;
> + mutex_unlock(&dchid->ifaces_lock);
> + return iface;
> + }
> +
> + fwnode = device_get_named_child_node(dchid->dev, name);
> + if (fwnode) {
> + iface->fwnode = fwnode;
> + ret = devm_add_action_or_reset(dchid->dev, dchid_fwnode_release,
> + iface->fwnode);
> + if (ret) {
> + mutex_unlock(&dchid->ifaces_lock);
> + return NULL;
> + }
> + } else {
> + iface->fwnode = dev_fwnode(dchid->dev);
> + }
> +
> + dchid->ifaces[index] = iface;
> + mutex_unlock(&dchid->ifaces_lock);
> + return iface;
> +}
> +
> +static int dchid_send(struct dchid_iface *iface, u32 flags, const void *msg,
> + size_t size)
> +{
> + struct dchid_dev *dchid = iface->dchid;
> + size_t payload_padded = round_up(size, sizeof(u32));
> + size_t total_len = sizeof(struct dchid_hdr) + sizeof(struct dchid_subhdr) +
> + payload_padded + DCHID_CHECKSUM_LEN;
> + struct apple_dockchannel_msg dc_msg;
> + struct dchid_hdr *hdr;
> + struct dchid_subhdr *sub;
> + u32 *checksum_ptr;
> + u8 *buf;
> + int ret;
> +
> + if (total_len > DCHID_RX_BUF_SIZE)
> + return -EINVAL;
> +
> + buf = kzalloc(total_len, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + hdr = (struct dchid_hdr *)buf;
> + sub = (struct dchid_subhdr *)(buf + sizeof(*hdr));
> + checksum_ptr = (u32 *)(buf + total_len - DCHID_CHECKSUM_LEN);
> +
> + hdr->hdr_len = sizeof(*hdr);
> + hdr->channel = DCHID_CHANNEL_CMD;
> + hdr->length = cpu_to_le16(payload_padded + sizeof(*sub));
> + hdr->seq = iface->tx_seq;
> + hdr->iface = iface->index;
> +
> + sub->flags = (u8)flags;
> + sub->length = cpu_to_le16(size);
> +
> + memcpy(buf + sizeof(*hdr) + sizeof(*sub), msg, size);
> +
> + *checksum_ptr = 0xffffffff - dchid_checksum(buf, total_len - DCHID_CHECKSUM_LEN);
> +
> + dc_msg.data = buf;
> + dc_msg.len = total_len;
> + ret = mbox_send_message(dchid->dc_mbox, &dc_msg);
> + kfree(buf);
> +
> + return ret < 0 ? ret : 0;
> +}
> +
> +static int dchid_cmd(struct dchid_iface *iface, u32 type, u32 req,
> + void *data, size_t size, void *resp_buf, size_t resp_size)
> +{
> + unsigned long flags;
> + int ret;
> + int report_id;
> + bool timed_out = false;
> + u32 out_flags;
> +
> + if (size < 1)
> + return -EINVAL;
> +
> + report_id = *(u8 *)data;
> + out_flags = FIELD_PREP(FLAGS_GROUP, type) | FIELD_PREP(FLAGS_REQ, req);
> +
> + spin_lock_irqsave(&iface->out_lock, flags);
> +
> + /* Only one command can be in flight per interface */
> + if (WARN_ON(iface->out_report != -1)) {
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> + return -EBUSY;
> + }
> +
> + iface->out_report = report_id;
> + iface->out_flags = out_flags;
> + iface->retcode = 0;
> + iface->resp_buf = resp_buf;
> + iface->resp_size = resp_size;
> + reinit_completion(&iface->out_complete);
> +
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> +
> + ret = dchid_send(iface, out_flags, data, size);
> + if (ret < 0) {
> + spin_lock_irqsave(&iface->out_lock, flags);
> + iface->out_report = -1;
> + iface->resp_buf = NULL;
> + iface->resp_size = 0;
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> + return ret;
> + }
> +
> + if (!wait_for_completion_timeout(&iface->out_complete,
> + msecs_to_jiffies(COMMAND_TIMEOUT_MS))) {
> + dev_err(iface->dchid->dev, "command 0x%x to iface %d (%s) timed out\n",
> + report_id, iface->index, iface->name);
> + timed_out = true;
> + }
> +
> + spin_lock_irqsave(&iface->out_lock, flags);
> +
> + if (timed_out && iface->out_report == report_id) {
> + ret = -ETIMEDOUT;
> + } else if (iface->retcode) {
> + dev_err(iface->dchid->dev,
> + "command 0x%x to iface %d (%s) failed with err 0x%x\n",
> + report_id, iface->index, iface->name, iface->retcode);
> + ret = -EIO;
> + } else {
> + ret = iface->resp_size;
> + }
> +
> + iface->tx_seq++;
> + iface->out_report = -1;
> + iface->resp_buf = NULL;
> + iface->resp_size = 0;
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> +
> + return ret;
> +}
> +
> +static int dchid_comm_cmd(struct dchid_dev *dchid, void *cmd, size_t size)
> +{
> + return dchid_cmd(dchid->comm, HID_FEATURE_REPORT, REQ_SET_REPORT,
> + cmd, size, NULL, 0);
> +}
> +
> +static int dchid_enable_interface(struct dchid_iface *iface)
> +{
> + u8 cmd[] = { CMD_ENABLE_INTERFACE, iface->index };
> +
> + return dchid_comm_cmd(iface->dchid, cmd, sizeof(cmd));
> +}
> +
> +static int dchid_reset_interface(struct dchid_iface *iface, int state)
> +{
> + u8 cmd[] = { CMD_RESET_INTERFACE, CMD_RESET_INTERFACE_SUB, iface->index,
> + (u8)state };
> +
> + return dchid_comm_cmd(iface->dchid, cmd, sizeof(cmd));
> +}
> +
> +static int dchid_start_interface(struct dchid_iface *iface)
> +{
> + if (iface->starting)
> + return -EINPROGRESS;
> +
> + dev_dbg(iface->dchid->dev, "starting interface %s\n", iface->name);
> +
> + iface->starting = true;
> + dchid_reset_interface(iface, 0);
> + dchid_reset_interface(iface, 2);
> +
> + return 0;
> +}
> +
> +static int dchid_start(struct hid_device *hdev)
> +{
> + return 0;
> +}
> +
> +static int dchid_open(struct hid_device *hdev)
> +{
> + struct dchid_iface *iface = hdev->driver_data;
> + int ret;
> +
> + if (!completion_done(&iface->ready)) {
> + ret = dchid_start_interface(iface);
> + if (ret < 0)
> + return ret;
> +
> + if (!wait_for_completion_timeout(&iface->ready,
> + msecs_to_jiffies(START_TIMEOUT_MS))) {
> + dev_err(iface->dchid->dev, "iface %s start timed out\n",
> + iface->name);
> + return -ETIMEDOUT;
> + }
> + }
> +
> + iface->open = true;
> + return 0;
> +}
> +
> +static void dchid_close(struct hid_device *hdev)
> +{
> + struct dchid_iface *iface = hdev->driver_data;
> +
> + iface->open = false;
> +}
> +
> +static int dchid_parse(struct hid_device *hdev)
> +{
> + struct dchid_iface *iface = hdev->driver_data;
> +
> + return hid_parse_report(hdev, iface->hid_desc, iface->hid_desc_len);
> +}
> +
> +/* Note: buf excludes report number. */
> +static int dchid_get_report_cmd(struct dchid_iface *iface, u8 reportnum,
> + void *buf, size_t len)
> +{
> + int ret;
> +
> + ret = dchid_cmd(iface, HID_FEATURE_REPORT, REQ_GET_REPORT, &reportnum, 1,
> + buf, len);
> +
> + return ret <= 0 ? ret : ret - 1;
> +}
> +
> +/* Note: buf includes report number. */
> +static int dchid_set_report(struct dchid_iface *iface, void *buf, size_t len)
> +{
> + return dchid_cmd(iface, HID_OUTPUT_REPORT, REQ_SET_REPORT, buf, len,
> + NULL, 0);
> +}
> +
> +static int dchid_raw_request(struct hid_device *hdev, unsigned char reportnum,
> + __u8 *buf, size_t len, unsigned char rtype,
> + int reqtype)
> +{
> + struct dchid_iface *iface = hdev->driver_data;
> +
> + switch (reqtype) {
> + case HID_REQ_GET_REPORT:
> + if (len < 1)
> + return -EINVAL;
> +
> + buf[0] = reportnum;
> + return dchid_cmd(iface, rtype, REQ_GET_REPORT, &reportnum, 1,
> + buf + 1, len - 1);
> + case HID_REQ_SET_REPORT:
> + return dchid_set_report(iface, buf, len);
> + default:
> + return -EIO;
> + }
> +}
> +
> +static const struct hid_ll_driver dchid_ll = {
> + .start = dchid_start,
> + .open = dchid_open,
> + .close = dchid_close,
> + .parse = dchid_parse,
> + .raw_request = dchid_raw_request,
> +};
> +
> +static void dchid_create_interface_work(struct work_struct *ws)
> +{
> + struct dchid_iface *iface = container_of(ws, struct dchid_iface, create_work);
> + struct dchid_dev *dchid = iface->dchid;
> + struct hid_device *hid;
> + char cap_name[16];
> + int ret;
> +
> + if (iface->hid) {
> + dev_warn(dchid->dev, "interface %s already created\n", iface->name);
> + goto done;
> + }
> +
> + ret = dchid_enable_interface(iface);
> + if (ret < 0) {
> + dev_warn(dchid->dev, "failed to enable %s: %d\n", iface->name, ret);
> + goto done;
> + }
> +
> + iface->deferred = false;
> +
> + hid = hid_allocate_device();
> + if (IS_ERR(hid))
> + goto done;
> +
> + strscpy(cap_name, iface->name, sizeof(cap_name));
> + if (cap_name[0])
> + cap_name[0] = toupper(cap_name[0]);
> + snprintf(hid->name, sizeof(hid->name), "Apple DockChannel %s", cap_name);
> +
> + snprintf(hid->phys, sizeof(hid->phys), "%s.%d", dev_name(dchid->dev),
> + iface->index);
> + strscpy(hid->uniq, dchid->serial, sizeof(hid->uniq));
If the keyboard appeared before stm, dchip->serial might be uninitialized.
> +
> + hid->ll_driver = &dchid_ll;
> + hid->bus = BUS_HOST;
> + hid->vendor = le16_to_cpu(dchid->device_id.vendor_id);
> + hid->product = le16_to_cpu(dchid->device_id.product_id);
> + hid->version = le16_to_cpu(dchid->device_id.version_number);
> + hid->type = HID_TYPE_OTHER;
> + if (!strcmp(iface->name, "keyboard")) {
> + u32 country_code;
> +
> + hid->group = HID_GROUP_APPLE_DOCKCHANNEL;
> +
> + /*
> + * The device provides no reliable way to get the keyboard
> + * country code, so board devicetrees provide it instead,
> + * filled by the bootloader.
> + */
> + if (!fwnode_property_read_u32(iface->fwnode, "hid-country-code",
> + &country_code))
> + hid->country = country_code;
> + }
> +
> + hid->dev.parent = iface->dchid->dev;
> + hid->driver_data = iface;
> + iface->hid = hid;
> +
> + ret = hid_add_device(hid);
> + if (ret < 0) {
> + iface->hid = NULL;
> + hid_destroy_device(hid);
> + dev_warn(iface->dchid->dev, "failed to register HID device %s\n",
> + iface->name);
> + }
> +
> +done:
> + iface->creating = false;
> +}
> +
> +static int dchid_create_interface(struct dchid_iface *iface)
> +{
> + if (iface->creating)
> + return -EBUSY;
> +
> + iface->creating = true;
> + INIT_WORK(&iface->create_work, dchid_create_interface_work);
> + return queue_work(iface->dchid->new_iface_wq, &iface->create_work);
> +}
> +
> +static void dchid_handle_descriptor(struct dchid_iface *iface, void *hid_desc,
> + size_t desc_len)
> +{
> + u8 *rdesc;
> + int i;
> +
> + if (iface->hid)
> + return;
> +
> + rdesc = devm_kmemdup(iface->dchid->dev, hid_desc, desc_len,
> + GFP_KERNEL);
> + if (!rdesc)
> + return;
> +
> + /* Fix up oversized report sizes in DockChannel report descriptors */
> + if (desc_len >= 5) {
> + for (i = 0; i <= (int)desc_len - 5; i++) {
> + if (rdesc[i] == 0x76 && rdesc[i + 1] == 0x00 &&
> + rdesc[i + 2] == 0x40 && rdesc[i + 3] == 0x95) {
> + u8 count = rdesc[i + 4];
> +
> + if (count > 0 && count < 32) {
> + dev_info(iface->dchid->dev,
> + "fixing up interface %s (%d) report size\n",
> + iface->name, iface->index);
> + rdesc[i] = 0x75;
> + rdesc[i + 1] = 0x08;
> + rdesc[i + 2] = 0x96;
> + rdesc[i + 3] = 0x00;
> + rdesc[i + 4] = count * 8;
> + }
> + }
> + }
> + }
> +
> + iface->hid_desc = rdesc;
> + iface->hid_desc_len = desc_len;
> +}
> +
> +static void dchid_handle_ready(struct dchid_dev *dchid, void *data, size_t length)
> +{
> + struct dchid_iface *iface;
> + u8 *pkt = data;
> + u8 index;
> + int i;
> + int ret;
> +
> + if (length < 2)
> + return;
> +
> + index = pkt[1];
> + if (index >= MAX_INTERFACES)
> + return;
> +
> + iface = dchid->ifaces[index];
> + if (!iface)
> + return;
> +
> + dev_dbg(dchid->dev, "interface %s is now ready\n", iface->name);
> + complete_all(&iface->ready);
> +
> + /* When STM is ready, grab global device info */
> + if (!strcmp(iface->name, "stm")) {
> + ret = dchid_get_report_cmd(iface, STM_REPORT_ID, &dchid->device_id,
> + sizeof(dchid->device_id));
> + if (ret < (int)sizeof(dchid->device_id)) {
> + dev_warn(iface->dchid->dev, "failed to get device ID from STM\n");
> + /* Fake it and keep going. Things might still work. */
> + memset(&dchid->device_id, 0, sizeof(dchid->device_id));
> + }
> +
> + ret = dchid_get_report_cmd(iface, STM_REPORT_SERIAL, dchid->serial,
> + sizeof(dchid->serial) - 1);
> + if (ret < 0) {
> + dev_warn(iface->dchid->dev, "failed to get serial from STM\n");
> + dchid->serial[0] = 0;
> + }
> +
> + dchid->id_ready = true;
> + for (i = 0; i < MAX_INTERFACES; i++) {
> + if (!dchid->ifaces[i] || !dchid->ifaces[i]->deferred)
> + continue;
> + dchid_create_interface(dchid->ifaces[i]);
> + }
> + }
> +}
> +
> +static void dchid_handle_init(struct dchid_dev *dchid, void *data, size_t length)
> +{
> + struct dchid_init_hdr *hdr = data;
> + struct dchid_init_block_hdr *blk;
> + struct dchid_iface *iface;
> + u8 *p = data;
> +
> + if (length < sizeof(*hdr))
> + return;
> +
> + iface = dchid_get_interface(dchid, hdr->iface, hdr->name);
> + if (!iface)
> + return;
> +
> + p += sizeof(*hdr);
> + length -= sizeof(*hdr);
> +
> + while (length >= sizeof(*blk)) {
> + u16 blk_len;
> +
> + blk = (struct dchid_init_block_hdr *)p;
> + p += sizeof(*blk);
> + length -= sizeof(*blk);
> +
> + blk_len = le16_to_cpu(blk->length);
> + if (blk_len > length)
> + break;
> +
> + switch (le16_to_cpu(blk->type)) {
> + case INIT_HID_DESCRIPTOR:
> + dchid_handle_descriptor(iface, p, blk_len);
> + break;
> + case INIT_PRODUCT_NAME:
> + if (blk_len > 0 && p[blk_len - 1] != 0)
> + dev_warn(dchid->dev, "unterminated product name for %s\n",
> + iface->name);
> + break;
> + }
> +
> + p += blk_len;
> + length -= blk_len;
> +
> + if (le16_to_cpu(blk->type) == INIT_TERMINATOR)
> + break;
> + }
> +
> + if (hdr->more_packets)
> + return;
> +
> + /*
> + * Prefer to enable STM first, since it provides device IDs. Some
> + * firmware versions do not expose STM, so let the keyboard start
> + * without it.
> + */
> + if (iface->dchid->id_ready || !strcmp(iface->name, "stm") ||
> + !strcmp(iface->name, "keyboard"))
I specifically asked for a mechanism to let the keyboard probe even on
devices which do not expose/have stm. Thanks for adding that!
However, I think this might need some more sophisticated mechanism to
decide whether the stm is still going to appear after the keyboard, or
not at all. I'm not sure if there is a way to tell this at this point,
or we need to add a timeout for the stm to appearing, which needs to
expire before we create the other interfaces with fake serials.
> + dchid_create_interface(iface);
> + else
> + iface->deferred = true;
> +}
> +
> +static void dchid_handle_event(struct dchid_dev *dchid, void *data, size_t length)
> +{
> + u8 *p = data;
> +
> + if (!length)
> + return;
> +
> + switch (*p) {
> + case EVENT_INIT:
> + dchid_handle_init(dchid, data, length);
> + break;
> + case EVENT_READY:
> + dchid_handle_ready(dchid, data, length);
> + break;
> + }
> +}
> +
> +static void dchid_handle_report(struct dchid_iface *iface, void *data, size_t length)
> +{
> + if (!iface->hid || !iface->open)
> + return;
> +
> + hid_input_report(iface->hid, HID_INPUT_REPORT, data, length, 1);
> +}
> +
> +static void dchid_packet_work(struct work_struct *ws)
> +{
> + struct dchid_work *work = container_of(ws, struct dchid_work, work);
> + struct dchid_subhdr *shdr = (void *)work->data;
> + struct dchid_dev *dchid = work->iface->dchid;
> + u16 hdr_len = le16_to_cpu(work->hdr.length);
> + u16 sub_len;
> + int type;
> + u8 *payload;
> +
> + if (hdr_len < sizeof(*shdr)) {
> + dev_err(dchid->dev, "bad subheader length\n");
> + goto done;
> + }
> +
> + sub_len = le16_to_cpu(shdr->length);
> + if (sub_len > hdr_len - sizeof(*shdr)) {
> + dev_err(dchid->dev, "bad subheader length\n");
> + goto done;
> + }
> +
> + type = FIELD_GET(FLAGS_GROUP, shdr->flags);
> + payload = work->data + sizeof(*shdr);
> +
> + switch (type) {
> + case HID_INPUT_REPORT:
> + if (work->hdr.iface == IFACE_COMM)
> + dchid_handle_event(dchid, payload, sub_len);
> + else
> + dchid_handle_report(work->iface, payload, sub_len);
> + break;
> + }
> +
> +done:
> + kfree(work);
> +}
> +
> +static void dchid_handle_ack(struct dchid_iface *iface, struct dchid_hdr *hdr,
> + void *data)
> +{
> + struct dchid_subhdr *shdr = data;
> + u8 *payload = data + sizeof(*shdr);
> + u16 hdr_len = le16_to_cpu(hdr->length);
> + u16 sub_len = le16_to_cpu(shdr->length);
> + unsigned long flags;
> + bool complete_cmd = false;
> +
> + if (hdr_len < sizeof(*shdr) || sub_len > hdr_len - sizeof(*shdr) ||
> + sub_len < 1)
> + return;
> +
> + spin_lock_irqsave(&iface->out_lock, flags);
> +
> + if (shdr->flags == iface->out_flags && iface->tx_seq == hdr->seq &&
> + iface->out_report == payload[0]) {
> + if (iface->resp_buf && iface->resp_size)
> + memcpy(iface->resp_buf, payload + 1,
> + min_t(size_t, sub_len - 1, iface->resp_size));
> +
> + iface->resp_size = sub_len;
> + iface->out_report = -1;
> + iface->retcode = le32_to_cpu(shdr->retcode);
> + complete_cmd = true;
> + }
> +
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> +
> + if (complete_cmd)
> + complete(&iface->out_complete);
> +}
> +
> +static void dchid_process_packet(struct dchid_dev *dchid, struct dchid_hdr *hdr,
> + u8 *payload, size_t payload_len, u8 *packet,
> + size_t packet_len)
> +{
> + struct dchid_work *work;
> +
> + if (dchid_checksum(packet, packet_len) != DCHID_CHECKSUM_SEED) {
> + dev_err_ratelimited(dchid->dev, "checksum error\n");
> + return;
> + }
> +
> + if (payload_len < sizeof(struct dchid_subhdr))
> + return;
> +
> + if (hdr->iface >= MAX_INTERFACES || !dchid->ifaces[hdr->iface])
> + return;
> +
> + if (hdr->channel == DCHID_CHANNEL_CMD) {
> + dchid_handle_ack(dchid->ifaces[hdr->iface], hdr, payload);
> + return;
> + }
> +
> + if (hdr->channel != DCHID_CHANNEL_REPORT)
> + return;
> +
> + work = kzalloc(sizeof(*work) + payload_len, GFP_ATOMIC);
> + if (!work)
> + return;
> +
> + work->hdr = *hdr;
> + work->iface = dchid->ifaces[hdr->iface];
> + memcpy(work->data, payload, payload_len);
> + INIT_WORK(&work->work, dchid_packet_work);
> +
> + queue_work(work->iface->wq, &work->work);
> +}
> +
> +static void dchid_consume_rx(struct dchid_dev *dchid)
> +{
> + while (dchid->rx_len >= sizeof(struct dchid_hdr)) {
> + struct dchid_hdr *hdr = (struct dchid_hdr *)dchid->rx_buf;
> + size_t payload_len;
> + size_t packet_len;
> +
> + if (hdr->hdr_len != sizeof(*hdr)) {
> + dev_err_ratelimited(dchid->dev, "bad header length %u\n",
> + hdr->hdr_len);
> + dchid->rx_len = 0;
> + return;
> + }
> +
> + payload_len = le16_to_cpu(hdr->length);
> + packet_len = sizeof(*hdr) + payload_len + DCHID_CHECKSUM_LEN;
> + if (packet_len > DCHID_RX_BUF_SIZE) {
> + dev_err_ratelimited(dchid->dev, "oversized packet %zu\n",
> + packet_len);
> + dchid->rx_len = 0;
> + return;
> + }
> +
> + if (dchid->rx_len < packet_len)
> + return;
> +
> + dchid_process_packet(dchid, hdr, dchid->rx_buf + sizeof(*hdr),
> + payload_len, dchid->rx_buf, packet_len);
> +
> + dchid->rx_len -= packet_len;
> + memmove(dchid->rx_buf, dchid->rx_buf + packet_len, dchid->rx_len);
> + }
> +}
> +
> +static void dchid_rx_callback(struct mbox_client *cl, void *mssg)
> +{
> + struct dchid_dev *dchid = container_of(cl, struct dchid_dev, dc_mbox_client);
> + struct apple_dockchannel_msg *msg = mssg;
> +
> + if (!msg || !msg->data || !msg->len)
> + return;
> +
> + if (msg->len > DCHID_RX_BUF_SIZE - dchid->rx_len) {
> + dev_err_ratelimited(dchid->dev, "RX buffer overflow\n");
> + dchid->rx_len = 0;
> + return;
> + }
> +
> + memcpy(dchid->rx_buf + dchid->rx_len, msg->data, msg->len);
> + dchid->rx_len += msg->len;
> +
> + dchid_consume_rx(dchid);
> +}
> +
> +static int dchid_rtkit_shmem_setup(void *cookie, struct apple_rtkit_shmem *bfr)
> +{
> + struct dchid_dev *dchid = cookie;
> + struct resource res = {
> + .start = bfr->iova,
> + .end = bfr->iova + bfr->size - 1,
> + .name = "rtkit_map",
> + };
> +
> + if (!bfr->iova) {
> + bfr->buffer = dma_alloc_coherent(dchid->dev, bfr->size,
> + &bfr->iova, GFP_KERNEL);
> + if (!bfr->buffer)
> + return -ENOMEM;
> + return 0;
> + }
> +
> + if (!dchid->sram_res.start)
> + return -EFAULT;
> +
> + res.flags = dchid->sram_res.flags;
> + if (res.end < res.start || !resource_contains(&dchid->sram_res, &res))
> + return -EFAULT;
> +
> + bfr->iomem = dchid->sram_base + (res.start - dchid->sram_res.start);
> + bfr->is_mapped = true;
> +
> + return 0;
> +}
> +
> +static void dchid_rtkit_shmem_destroy(void *cookie, struct apple_rtkit_shmem *bfr)
> +{
> + struct dchid_dev *dchid = cookie;
> +
> + if (bfr->buffer)
> + dma_free_coherent(dchid->dev, bfr->size, bfr->buffer, bfr->iova);
> +}
> +
> +static const struct apple_rtkit_ops dchid_rtkit_ops = {
> + .shmem_setup = dchid_rtkit_shmem_setup,
> + .shmem_destroy = dchid_rtkit_shmem_destroy,
> +};
> +
> +static int dchid_map_helper_cpu(struct platform_device *pdev, struct dchid_dev *dchid)
> +{
> + struct resource *res;
> +
> + dchid->asc_base = devm_platform_ioremap_resource_byname(pdev, "coproc-asc");
> + if (IS_ERR(dchid->asc_base))
> + return PTR_ERR(dchid->asc_base);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "coproc-sram");
> + if (!res)
> + return -EINVAL;
> +
> + dchid->sram_res = *res;
> +
> + dchid->sram_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(dchid->sram_base))
> + return PTR_ERR(dchid->sram_base);
> +
> + return 0;
> +}
> +
> +static int dchid_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct dchid_dev *dchid;
> + int ret;
> +
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(44));
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to set DMA mask\n");
> +
> + dchid = devm_kzalloc(dev, sizeof(*dchid), GFP_KERNEL);
> + if (!dchid)
> + return -ENOMEM;
> +
> + dchid->rx_buf = devm_kmalloc(dev, DCHID_RX_BUF_SIZE, GFP_KERNEL);
> + if (!dchid->rx_buf)
> + return -ENOMEM;
> +
> + dchid->dev = dev;
> + mutex_init(&dchid->ifaces_lock);
> + platform_set_drvdata(pdev, dchid);
> +
> + ret = dchid_map_helper_cpu(pdev, dchid);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to map helper CPU\n");
> +
> + dchid->dc_mbox_client.dev = dev;
> + dchid->dc_mbox_client.tx_block = true;
> + dchid->dc_mbox_client.rx_callback = dchid_rx_callback;
> +
> + dchid->dc_mbox = mbox_request_channel_byname(&dchid->dc_mbox_client,
> + "dockchannel");
> + if (IS_ERR(dchid->dc_mbox))
> + return dev_err_probe(dev, PTR_ERR(dchid->dc_mbox),
> + "failed to request DockChannel mailbox\n");
> +
> + ret = devm_add_action_or_reset(dev, dchid_free_mbox, dchid->dc_mbox);
> + if (ret)
> + return ret;
> +
> + dchid->rtk = devm_apple_rtkit_init(dev, dchid, "asc", 0, &dchid_rtkit_ops);
> + if (IS_ERR(dchid->rtk))
> + return dev_err_probe(dev, PTR_ERR(dchid->rtk), "failed to init RTKit\n");
> +
> + writel_relaxed(APPLE_ASC_CPU_CONTROL_RUN,
> + dchid->asc_base + APPLE_ASC_CPU_CONTROL);
> +
> + ret = apple_rtkit_wake(dchid->rtk);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to wake coprocessor\n");
> +
> + dchid->new_iface_wq = alloc_ordered_workqueue("dchid-new", 0);
> + if (!dchid->new_iface_wq)
> + return dev_err_probe(dev, -ENOMEM, "failed to allocate workqueue\n");
> +
> + ret = devm_add_action_or_reset(dev, dchid_destroy_wq, dchid->new_iface_wq);
> + if (ret)
> + return ret;
> +
> + dchid->comm = dchid_get_interface(dchid, IFACE_COMM, "comm");
> + if (!dchid->comm)
> + return dev_err_probe(dev, -EIO, "failed to init comm interface\n");
> +
> + return 0;
> +}
> +
> +static void dchid_remove(struct platform_device *pdev)
> +{
> + struct dchid_dev *dchid = platform_get_drvdata(pdev);
> + int i;
> +
> + if (dchid->dc_mbox) {
> + devm_release_action(&pdev->dev, dchid_free_mbox, dchid->dc_mbox);
> + dchid->dc_mbox = NULL;
> + }
> +
> + if (dchid->rtk && apple_rtkit_is_running(dchid->rtk))
> + apple_rtkit_quiesce(dchid->rtk);
> +
> + if (dchid->asc_base)
> + writel_relaxed(0, dchid->asc_base + APPLE_ASC_CPU_CONTROL);
> +
> + for (i = 0; i < MAX_INTERFACES; i++) {
> + struct dchid_iface *iface = dchid->ifaces[i];
> +
> + if (!iface)
> + continue;
> +
> + cancel_work_sync(&iface->create_work);
> + flush_workqueue(iface->wq);
> +
> + if (iface->hid)
> + hid_destroy_device(iface->hid);
> + }
> +
> + if (dchid->new_iface_wq)
> + flush_workqueue(dchid->new_iface_wq);
> +}
> +
> +static const struct of_device_id dchid_of_match[] = {
> + { .compatible = "apple,t8122-dockchannel-hid" },
> + { .compatible = "apple,t8112-dockchannel-hid" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dchid_of_match);
> +
> +static struct platform_driver dchid_platform_driver = {
> + .driver = {
> + .name = "dockchannel-hid",
> + .of_match_table = dchid_of_match,
> + },
> + .probe = dchid_probe,
> + .remove = dchid_remove,
> +};
> +module_platform_driver(dchid_platform_driver);
> +
> +MODULE_DESCRIPTION("Apple DockChannel HID transport driver");
> +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
> +MODULE_AUTHOR("Michael Reeves <michael.reeves077@gmail.com>");
> +MODULE_LICENSE("Dual MIT/GPL");
>
^ permalink raw reply
* Re: [PATCH 05/13] mfd: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, dmitry.torokhov, linux-input, vkoul,
neil.armstrong, linux-sunxi
In-Reply-To: <20260629132633.1300009-6-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a duplicate `#include <linux/gpio/consumer.h>` in `include/linux/mfd/ti-lmu.h`.
--
commit 19751af1f4af7549cf9f140e38427847c8babbd4
Author: Arnd Bergmann <arnd@arndb.de>
mfd: replace linux/gpio.h inclusions
This commit replaces the deprecated linux/gpio.h inclusion across various MFD
drivers and headers, converting them to use either linux/gpio/consumer.h or
linux/gpio/legacy.h as needed.
[ ... ]
> diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
> index 0bc0e81997987..5040c7d1e1b92 100644
> --- a/include/linux/mfd/ti-lmu.h
> +++ b/include/linux/mfd/ti-lmu.h
> @@ -10,7 +10,7 @@
> #ifndef __MFD_TI_LMU_H__
> #define __MFD_TI_LMU_H__
>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/notifier.h>
> #include <linux/regmap.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but <linux/gpio/consumer.h> is now included twice. Would it
be better to just drop the replaced include here since the consumer header is
already present a few lines below?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=5
^ permalink raw reply
* Re: [PATCH 07/13] ASoC: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-sunxi, linux-phy, linux-input, olteanv, vkoul,
neil.armstrong, dmitry.torokhov
In-Reply-To: <20260629132633.1300009-8-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces duplicate `#include <linux/gpio/consumer.h>` directives in `cs42l84.c` and `dmic.c`.
--
commit 5e88ad9a5863dbafbe414c688b31a85827de20da
Author: Arnd Bergmann <arnd@arndb.de>
ASoC: replace linux/gpio.h inclusions
This commit updates multiple ASoC codecs to use linux/gpio/consumer.h instead
of the deprecated linux/gpio.h header.
> diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
> index f2a58163de0ed..36c3abc21fedc 100644
> --- a/sound/soc/codecs/cs42l84.c
> +++ b/sound/soc/codecs/cs42l84.c
> @@ -16,7 +16,7 @@
> #include <linux/init.h>
> #include <linux/delay.h>
> #include <linux/i2c.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but does this create a duplicate include? It appears
linux/gpio/consumer.h is already included further down in this file. Could we
simply drop the linux/gpio.h include entirely?
> #include <linux/regmap.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
[ ... ]
> diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
> index 61e1bf1b3c9e6..8b05d6f9b429b 100644
> --- a/sound/soc/codecs/dmic.c
> +++ b/sound/soc/codecs/dmic.c
> @@ -6,7 +6,7 @@
> */
>
> #include <linux/delay.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but should we just delete the old include line? Replacing
it leaves two identical includes back-to-back.
> #include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=7
^ permalink raw reply
* Re: [PATCH 08/13] pcmcia: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, linux-sunxi, vkoul, dmitry.torokhov,
linux-input, neil.armstrong
In-Reply-To: <20260629132633.1300009-9-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Invalid resource cleanup on error path leading to potential double-free of a devres-managed GPIO descriptor.
--
commit a1a20647914d78d6a15655dea889e9d53c734136
Author: Arnd Bergmann <arnd@arndb.de>
pcmcia: replace linux/gpio.h inclusions
The pcmcia drivers all use the legacy interfaces, so convert to
include linux/gpio/legacy.h instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[ ... ]
> diff --git a/drivers/pcmcia/sa1100_h3600.c b/drivers/pcmcia/sa1100_h3600.c
> index 10cb99c20a7f5..6c52d90795eb4 100644
> --- a/drivers/pcmcia/sa1100_h3600.c
> +++ b/drivers/pcmcia/sa1100_h3600.c
> @@ -11,7 +11,7 @@
> #include <linux/interrupt.h>
> #include <linux/init.h>
> #include <linux/delay.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
issue while reviewing the GPIO include changes.
Does the error path in h3600_pcmcia_hw_init() cause a double-free of a
devres-managed GPIO descriptor?
If gpio_request(H3XXX_EGPIO_OPT_NVRAM_ON) or subsequent legacy GPIO requests
fail, the code jumps to or falls through to the err01 label:
drivers/pcmcia/sa1100_h3600.c:h3600_pcmcia_hw_init() {
...
err06: gpio_free(H3XXX_EGPIO_CARD_RESET);
err05: gpio_free(H3XXX_EGPIO_OPT_RESET);
err04: gpio_free(H3XXX_EGPIO_OPT_ON);
err03: gpio_free(H3XXX_EGPIO_OPT_NVRAM_ON);
err01: gpio_free(H3XXX_GPIO_PCMCIA_IRQ0);
return err;
}
The err01 label incorrectly frees H3XXX_GPIO_PCMCIA_IRQ0. This GPIO is
managed by devres and was not explicitly requested using gpio_request() in
this function.
When devres cleans up the failed probe, it will attempt to free the GPIO
again. This could lead to a double-free, gpiolib state corruption, kernel
warnings, or accidentally freeing a GPIO acquired by a concurrent driver.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=8
^ permalink raw reply
* Re: [PATCH 11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, linux-sunxi, dmitry.torokhov, vkoul,
neil.armstrong, linux-input
In-Reply-To: <20260629132633.1300009-12-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Redundant header inclusion of <linux/gpio/consumer.h>
--
commit b60f4c5bf1d6c83cc34b3ab6030725489bd7c3e5
Author: Arnd Bergmann <arnd@arndb.de>
Input: matrix_keyboard - replace linux/gpio.h inclusion
This commit replaces the inclusion of the deprecated linux/gpio.h header
with linux/gpio/consumer.h in the matrix keypad driver. It prepares the
code for the removal of linux/gpio.h.
> diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
> index e50a6fea9a602..98d0269a978fe 100644
> --- a/drivers/input/keyboard/matrix_keypad.c
> +++ b/drivers/input/keyboard/matrix_keypad.c
> @@ -16,7 +16,7 @@
> #include <linux/interrupt.h>
> #include <linux/jiffies.h>
> #include <linux/module.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
Does this result in a redundant inclusion? Looking at matrix_keypad.c,
<linux/gpio/consumer.h> is already included earlier in the file:
#include <linux/types.h>
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
Could the old <linux/gpio.h> inclusion just be removed entirely instead of
being replaced?
> #include <linux/input/matrix_keypad.h>
> #include <linux/slab.h>
> #include <linux/of.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=11
^ permalink raw reply
* Re: [PATCH 12/13] gpib: gpio: replace linux/gpio.h inclusion
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-phy, linux-sunxi, neil.armstrong, vkoul, linux-input,
dmitry.torokhov, olteanv
In-Reply-To: <20260629132633.1300009-13-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The patch introduces redundant duplicate `#include <linux/gpio/consumer.h>` statements in multiple files.
Pre-existing issues:
- [High] Missing bounds check on `priv->count` in `bb_DAV_interrupt()` can lead to a buffer overflow.
--
commit 198cff3fadd8f7ab5db98a0ff2a666f4ac7f1bf0
Author: Arnd Bergmann <arnd@arndb.de>
gpib: gpio: replace linux/gpio.h inclusion
linux/gpio.h is going away, so use linux/gpio/consumer.h instead.
> diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
> index 0e227980b493a..2e8d895db06a5 100644
> --- a/drivers/gpib/gpio/gpib_bitbang.c
> +++ b/drivers/gpib/gpio/gpib_bitbang.c
> @@ -64,7 +64,7 @@
> #include <linux/gpio/consumer.h>
> #include <linux/gpio/driver.h>
> #include <linux/gpio/machine.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but does this introduce a duplicate include of
linux/gpio/consumer.h? It appears to already be included a few lines above.
Similar duplicate includes might have been added to other files like
drivers/input/keyboard/matrix_keypad.c and drivers/net/phy/mdio_device.c
if they were also part of this series.
> #include <linux/irq.h>
>
> static int sn7516x_used = 1, sn7516x;
While reviewing this file, I noticed a separate issue in bb_DAV_interrupt().
[Severity: High]
This is a pre-existing issue, but does this lack of a bounds check on
priv->count lead to a buffer overflow?
drivers/gpib/gpio/gpib_bitbang.c:bb_DAV_interrupt() {
...
priv->rbuf[priv->count++] = get_data_lines();
priv->end = !gpiod_get_value(EOI);
...
}
If the hardware line DAV goes low multiple times while priv->r_busy is set
without waiting for the normal NRFD/NDAC handshake, could priv->count exceed
the allocated buffer size and corrupt memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=12
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-sunxi, dmitry.torokhov, neil.armstrong, olteanv, vkoul,
linux-phy, linux-input
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Removing `include/linux/gpio.h` breaks the build for multiple drivers across the kernel tree that still include it and rely on it for legacy GPIO declarations.
- [Low] Typographical error in `drivers/gpio/TODO` where `legacy.h` is misspelled as `lagacy.h`.
--
commit eb8b9c8709d4fc96f518f3578deb6f0d05993604
Author: Arnd Bergmann <arnd@arndb.de>
gpiolib: remove linux/gpio.h
This commit removes the include/linux/gpio.h header entirely, cleaning up
leftover bits under the assumption that all drivers have been converted to
consumer.h or legacy.h. It also updates internal gpiolib includes and a
TODO file accordingly.
> diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
> index 7ce80fde1f17e..894c7e1af252a 100644
> --- a/drivers/gpio/TODO
> +++ b/drivers/gpio/TODO
> @@ -52,9 +52,7 @@ Work items:
> base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled.
>
> - When this work is complete (will require some of the items in the
> - following ongoing work as well) we can delete the old global
> - numberspace accessors from <linux/gpio.h> and eventually delete
> - <linux/gpio.h> altogether.
> + following ongoing work as well) we can delete <linux/gpio/lagacy.h>.
^^^^^^^^
[Severity: Low]
This isn't a bug, but there is a typo here (lagacy.h instead of legacy.h).
[ ... ]
> diff --git a/include/linux/gpio.h b/include/linux/gpio.h
> deleted file mode 100644
> index b0d4942a65de2..0000000000000
> --- a/include/linux/gpio.h
> +++ /dev/null
> @@ -1,22 +0,0 @@
[ ... ]
> -#ifdef CONFIG_GPIOLIB_LEGACY
> -#include <linux/gpio/legacy.h>
> -#endif /* CONFIG_GPIOLIB_LEGACY */
> -
> -#endif /* __LINUX_GPIO_H */
[Severity: Low]
Does removing this header break the build for remaining unconverted legacy
GPIO consumers?
For example, drivers/input/keyboard/gpio_keys.c:gpio_keys_setup_key() still
appears to rely on this header for devm_gpio_request_one():
error = devm_gpio_request_one(dev, button->gpio, GPIOF_IN, desc);
Similarly, drivers/leds/leds-gpio.c:gpio_led_get_gpiod() also relies on it:
ret = devm_gpio_request_one(dev, template->gpio, GPIOF_OUT_INIT_LOW,
template->name);
And arch/x86/platform/olpc/olpc-xo1-sci.c:setup_ec_sci() still uses
gpio_request():
r = gpio_request(OLPC_GPIO_ECSCI, "OLPC-ECSCI");
Will these drivers fail to compile since functions like devm_gpio_request_one()
and gpio_request() will now be missing or implicitly declared?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=13
^ permalink raw reply
* Re: [PATCH 06/13] [net-next] net: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: vkoul, dmitry.torokhov, linux-input, linux-sunxi, neil.armstrong,
olteanv, linux-phy
In-Reply-To: <20260629132633.1300009-7-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Duplicate inclusion of `<linux/gpio/consumer.h>` caused by an unchecked find-and-replace.
--
commit cb55ce48e23e6753d04ac5f664585feb999f1fcd
Author: Arnd Bergmann <arnd@arndb.de>
net: replace linux/gpio.h inclusions
This commit replaces obsolete linux/gpio.h includes with linux/gpio/consumer.h
or linux/gpio/legacy.h across various network drivers where possible.
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> index 48b94ce774906..88c5c52e0e381 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> @@ -16,7 +16,7 @@
> #include <linux/net_tstamp.h>
> #include <linux/ptp_classify.h>
> #include <linux/ptp_pch.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
Does this create a duplicate include in pch_gbe_main.c?
Since linux/gpio/consumer.h is already included earlier in the file alongside
linux/gpio/machine.h, changing this include results in it being included
twice. Can this replaced include simply be removed?
>
> #define PCH_GBE_MAR_ENTRIES 16
[ ... ]
> diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
> index 56080d3d2d25e..a18263d5bb029 100644
> --- a/drivers/net/phy/mdio_device.c
> +++ b/drivers/net/phy/mdio_device.c
> @@ -8,7 +8,7 @@
>
> #include <linux/delay.h>
> #include <linux/errno.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
Did the automated replacement result in consecutive duplicate includes here?
It looks like mdio_device.c already included linux/gpio/consumer.h right below
the old linux/gpio.h include. Should we just drop the old include entirely
instead of replacing it?
> #include <linux/init.h>
> #include <linux/interrupt.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=6
^ permalink raw reply
* Re: [PATCH 09/13] phy: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: neil.armstrong, linux-input, dmitry.torokhov, linux-sunxi, vkoul,
linux-phy, olteanv
In-Reply-To: <20260629132633.1300009-10-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Replacing `#include <linux/gpio.h>` with `#include <linux/gpio/consumer.h>` results in duplicate include directives.
--
commit 172e670e08c06c1b704f9f5d80187a66ba9bb20c
Author: Arnd Bergmann <arnd@arndb.de>
phy: replace linux/gpio.h inclusions
linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
> diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> index 8473fa5745296..d9c06129ed23e 100644
> --- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> +++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> @@ -3,7 +3,7 @@
>
> #include <linux/delay.h>
> #include <linux/extcon-provider.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but the replacement leaves us with consecutive duplicate
linux/gpio/consumer.h inclusions. Could the redundant include be removed?
[ ... ]
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 7531a8a049123..2233babc00781 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -11,7 +11,7 @@
> #include <linux/slab.h>
> #include <linux/clk.h>
> #include <linux/clk-provider.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but similar to the broadcom phy driver, this creates
duplicate linux/gpio/consumer.h inclusions here as well. Should the second
one be dropped?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=9
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Arnd Bergmann @ 2026-06-30 13:31 UTC (permalink / raw)
To: sashiko-reviews
Cc: linux-sunxi, Dmitry Torokhov, Neil Armstrong, Vladimir Oltean,
Vinod Koul, linux-phy, linux-input
In-Reply-To: <20260630132838.113F91F00A3A@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
>> - When this work is complete (will require some of the items in the
>> - following ongoing work as well) we can delete the old global
>> - numberspace accessors from <linux/gpio.h> and eventually delete
>> - <linux/gpio.h> altogether.
>> + following ongoing work as well) we can delete <linux/gpio/lagacy.h>.
> ^^^^^^^^
> [Severity: Low]
> This isn't a bug, but there is a typo here (lagacy.h instead of legacy.h).
Fixed now for v2.
>> -#ifdef CONFIG_GPIOLIB_LEGACY
>> -#include <linux/gpio/legacy.h>
>> -#endif /* CONFIG_GPIOLIB_LEGACY */
>> -
>> -#endif /* __LINUX_GPIO_H */
>
> [Severity: Low]
> Does removing this header break the build for remaining unconverted legacy
> GPIO consumers?
There are a few more patches in flight that all have to be applied
before this one.
Arnd
^ permalink raw reply
* Re: [PATCH 08/13] pcmcia: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-06-30 13:36 UTC (permalink / raw)
To: sashiko-reviews
Cc: Vladimir Oltean, linux-phy, linux-sunxi, Vinod Koul,
Dmitry Torokhov, linux-input, Neil Armstrong
In-Reply-To: <20260630132833.450051F00A3A@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but I noticed a pre-existing
> issue while reviewing the GPIO include changes.
>
> Does the error path in h3600_pcmcia_hw_init() cause a double-free of a
> devres-managed GPIO descriptor?
Yes, there are many bugs in the old pcmcia drivers. I expect that
we will remove these soon, as I plan to drop all the sa1100 and pxa
board files early next year.
Arnd
^ permalink raw reply
* Re: [PATCH 09/13] phy: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-06-30 13:37 UTC (permalink / raw)
To: sashiko-reviews
Cc: Neil Armstrong, linux-input, Dmitry Torokhov, linux-sunxi,
Vinod Koul, linux-phy, Vladimir Oltean
In-Reply-To: <20260630132842.39AF01F000E9@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
>
> [Severity: Low]
> This isn't a bug, but the replacement leaves us with consecutive duplicate
> linux/gpio/consumer.h inclusions. Could the redundant include be removed?
This was already reported and fixed earlier, all of these will
be addressed in v2.
Arnd
^ permalink raw reply
* Re: [PATCH 07/10] HID: apple: Add support for DockChannel HID keyboards
From: Sasha Finkelstein @ 2026-06-30 13:41 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-7-506d936a1707@gmail.com>
> On Jun 30, 2026, at 14:54, Michael Reeves via B4 Relay <devnull+michael.reeves077.gmail.com@kernel.org> wrote:
>
> @@ -659,6 +669,7 @@ static void apple_battery_timer_tick(struct timer_list *t)
> /*
> * MacBook JIS keyboard has wrong logical maximum
> * Magic Keyboard JIS has wrong logical maximum
> + * Internal DockChannel keyboards can advertise oversized report sizes
> */
> static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> unsigned int *rsize)
> @@ -699,6 +710,27 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> rdesc[3] = 0x06;
> }
>
> + if (apple_is_dockchannel_keyboard(hdev) && *rsize >= 5) {
> + int i;
> +
> + for (i = 0; i <= *rsize - 5; i++) {
> + if (rdesc[i] == 0x76 && rdesc[i + 1] == 0x00 &&
> + rdesc[i + 2] == 0x40 && rdesc[i + 3] == 0x95) {
> + u8 count = rdesc[i + 4];
> +
> + if (count > 0 && count < 32) {
> + hid_info(hdev,
> + "fixing up DockChannel report size\n");
> + rdesc[i] = 0x75;
> + rdesc[i + 1] = 0x08;
> + rdesc[i + 2] = 0x96;
> + rdesc[i + 3] = 0x00;
> + rdesc[i + 4] = count * 8;
> + }
> + }
> + }
> + }
> +
> return rdesc;
> }
>
It looks like this section is duplicated in the following commit (8).
Is that correct?
^ permalink raw reply
* Re: [PATCH 07/10] HID: apple: Add support for DockChannel HID keyboards
From: sashiko-bot @ 2026-06-30 13:43 UTC (permalink / raw)
To: Michael Reeves via B4 Relay
Cc: dmitry.torokhov, devicetree, robh, linux-input, conor+dt
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-7-506d936a1707@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The custom `apple_match` callback fails to check for the `HID_QUIRK_IGNORE_SPECIAL_DRIVER` quirk, bypassing system or BPF-driven overrides that force the generic HID driver.
--
commit 28e52ea5c163ab3459cd9d8d4a75ee76a37b6489
Author: Michael Reeves <michael.reeves077@gmail.com>
HID: apple: Add support for DockChannel HID keyboards
This commit registers DockChannel keyboards as host-bus Apple HID devices.
It updates hid-apple to match these devices, applies the Magic Keyboard
function-key table, and fixes their oversized report-size descriptors before
parsing.
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index bf7dd0fbf2496..47c6ec09d5fae 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
[ ... ]
> @@ -1003,6 +1035,17 @@ static void apple_remove(struct hid_device *hdev)
> hid_hw_stop(hdev);
> }
>
> +static bool apple_match(struct hid_device *hdev, bool ignore_special_driver)
> +{
> + if (ignore_special_driver)
> + return false;
> +
[Severity: Medium]
Does this custom match function bypass the HID_QUIRK_IGNORE_SPECIAL_DRIVER
quirk?
It checks the ignore_special_driver parameter, but it looks like it omits
checking if hdev->quirks has the HID_QUIRK_IGNORE_SPECIAL_DRIVER bit set.
By unconditionally returning true for standard Apple devices further down,
this might allow hid-apple to bind even when a user or BPF program explicitly
requested to ignore special drivers and use hid-generic instead.
Should this also check for (hdev->quirks & HID_QUIRK_IGNORE_SPECIAL_DRIVER)
before allowing the match?
> + if (hdev->group == HID_GROUP_APPLE_DOCKCHANNEL)
> + return apple_is_dockchannel_keyboard(hdev);
> +
> + return true;
> +}
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-apple-mtp-keyboard-final-v1-0-506d936a1707@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH 08/10] HID: apple: Add DockChannel HID transport driver
From: sashiko-bot @ 2026-06-30 13:58 UTC (permalink / raw)
To: Michael Reeves via B4 Relay
Cc: dmitry.torokhov, devicetree, robh, conor+dt, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-8-506d936a1707@gmail.com>
Thank you for your contribution! Sashiko AI review found 9 potential issue(s) to consider:
- [High] Flawed teardown ordering in dchid_remove leads to Use-After-Free of HID devices and transport channel.
- [High] dchid_raw_request returns an unvalidated length from the device, leading to a heap out-of-bounds read in hidraw.
- [High] Missing null-termination enforcement on hardware-provided interface name leads to an out-of-bounds read.
- [High] Concurrency flaws in dchid_cmd lead to kernel log spam and state corruption.
- [High] Unbounded devres memory allocation in dchid_handle_descriptor allows device to exhaust kernel memory.
- [High] Missing memory barriers when publishing and reading dchid->ifaces array causes a potential crash on weakly ordered architectures.
- [Medium] dchid_raw_request returns incorrect length for HID_REQ_SET_REPORT, causing false short write errors.
- [Medium] Missing cleanup for the ASC coprocessor and RTKit on probe error paths.
- [Low] Native pointer assignment writes the checksum in host byte order, causing failures on Big-Endian systems.
--
commit 73972b8194e713fd30c0d82321eb7f0553221fd5
Author: Michael Reeves <michael.reeves077@gmail.com>
HID: apple: Add DockChannel HID transport driver
This commit adds a transport driver that boots the MTP RTKit coprocessor,
exchanges HID packets through the DockChannel mailbox, and registers child
HID interfaces from devicetree.
> diff --git a/drivers/hid/dockchannel/apple-hid.c b/drivers/hid/dockchannel/apple-hid.c
> index 0000000000000..162fcfb5ab1ce
> --- /dev/null
> +++ b/drivers/hid/dockchannel/apple-hid.c
[ ... ]
> +static struct dchid_iface *
> +dchid_get_interface(struct dchid_dev *dchid, int index, const char *name)
> +{
[ ... ]
> + iface->index = index;
> + iface->name = devm_kstrdup(dchid->dev, name, GFP_KERNEL);
[Severity: High]
Can this cause an out-of-bounds read if the hardware sends a name that is
exactly 16 characters and not null-terminated? In dchid_handle_init(), the
device provides a fixed 16-byte character array for hdr->name. If it lacks a
null terminator, devm_kstrdup() will read past the end of the array into
adjacent fields. Should this use devm_kstrndup(..., 16, ...) instead?
[ ... ]
> + dchid->ifaces[index] = iface;
> + mutex_unlock(&dchid->ifaces_lock);
> + return iface;
> +}
[Severity: High]
Does the absence of a memory barrier here allow the reader to observe an
uninitialized interface? The interface is published to the array here and
the mutex is unlocked, but dchid_process_packet() reads this array locklessly.
The mutex_unlock() does not prevent the compiler or CPU from reordering the
initialization of the structure (like iface->wq) to after the pointer becomes
visible. Should smp_store_release() be used when publishing to the array?
[ ... ]
> +static int dchid_send(struct dchid_iface *iface, u32 flags, const void *msg,
> + size_t size)
> +{
[ ... ]
> + *checksum_ptr = 0xffffffff - dchid_checksum(buf, total_len - DCHID_CHECKSUM_LEN);
[Severity: Low]
Does this write the checksum in the CPU's native byte order rather than
the expected little-endian format? Since other fields like hdr->length use
__le16, it appears the hardware expects little-endian, which could cause
packets to be dropped on big-endian architectures. Should this use
put_unaligned_le32() instead?
[ ... ]
> +static int dchid_cmd(struct dchid_iface *iface, u32 type, u32 req,
> + void *data, size_t size, void *resp_buf, size_t resp_size)
> +{
[ ... ]
> + /* Only one command can be in flight per interface */
> + if (WARN_ON(iface->out_report != -1)) {
> + spin_unlock_irqrestore(&iface->out_lock, flags);
> + return -EBUSY;
> + }
[Severity: High]
Can userspace easily trigger this WARN_ON and spam the kernel log by issuing
concurrent hidraw ioctls? Furthermore, is there a race window here? In
dchid_handle_ack(), iface->out_report is cleared before the waiting thread
completes its cleanup. This could allow a second concurrent thread to bypass
this check and set up its own command, only to have its state clobbered when
the first thread finally wakes up.
[ ... ]
> +static int dchid_set_report(struct dchid_iface *iface, void *buf, size_t len)
> +{
> + return dchid_cmd(iface, HID_OUTPUT_REPORT, REQ_SET_REPORT, buf, len,
> + NULL, 0);
> +}
[Severity: Medium]
Does returning the result of dchid_cmd() here cause false short-write errors
for userspace? The HID core expects the raw_request function for a SET_REPORT
call to return the number of bytes written (the requested length). However,
dchid_cmd() returns the length of the device's ACK payload, which is typically
just 1 byte.
[ ... ]
> +static int dchid_raw_request(struct hid_device *hdev, unsigned char reportnum,
> + __u8 *buf, size_t len, unsigned char rtype,
> + int reqtype)
> +{
> + struct dchid_iface *iface = hdev->driver_data;
> +
> + switch (reqtype) {
> + case HID_REQ_GET_REPORT:
> + if (len < 1)
> + return -EINVAL;
> +
> + buf[0] = reportnum;
> + return dchid_cmd(iface, rtype, REQ_GET_REPORT, &reportnum, 1,
> + buf + 1, len - 1);
[Severity: High]
Could this return an unvalidated length from the device and lead to an
out-of-bounds heap read? In dchid_handle_ack(), iface->resp_size is
overwritten with the hardware-supplied sub_len. If the device sends a
response larger than the requested length, dchid_cmd() returns that larger
value, and hidraw_ioctl() will use it as the count for copy_to_user(),
reading past the end of the allocated buffer.
[ ... ]
> +static void dchid_handle_descriptor(struct dchid_iface *iface, void *hid_desc,
> + size_t desc_len)
> +{
> + u8 *rdesc;
> + int i;
> +
> + if (iface->hid)
> + return;
> +
> + rdesc = devm_kmemdup(iface->dchid->dev, hid_desc, desc_len,
> + GFP_KERNEL);
> + if (!rdesc)
> + return;
[Severity: High]
Can a misbehaving device exhaust kernel memory by flooding the host with
descriptor packets? The devm_kmemdup() allocation is performed without checking
if iface->hid_desc is already allocated or freeing the previous pointer. Since
the check for iface->hid only bypasses this once asynchronous registration
completes, a rapid stream of packets before that point could leak memory.
[ ... ]
> +static void dchid_handle_ack(struct dchid_iface *iface, struct dchid_hdr *hdr,
> + void *data)
> +{
[ ... ]
> + if (shdr->flags == iface->out_flags && iface->tx_seq == hdr->seq &&
> + iface->out_report == payload[0]) {
> + if (iface->resp_buf && iface->resp_size)
> + memcpy(iface->resp_buf, payload + 1,
> + min_t(size_t, sub_len - 1, iface->resp_size));
> +
> + iface->resp_size = sub_len;
[Severity: High]
Is it safe to unconditionally overwrite iface->resp_size with the unvalidated
sub_len from the device here? This causes the calling function to believe more
bytes were read than actually requested, setting up the info leak mentioned
earlier in dchid_raw_request().
[ ... ]
> +static void dchid_process_packet(struct dchid_dev *dchid, struct dchid_hdr *hdr,
> + u8 *payload, size_t payload_len, u8 *packet,
> + size_t packet_len)
> +{
> + struct dchid_work *work;
> +
> + if (dchid_checksum(packet, packet_len) != DCHID_CHECKSUM_SEED) {
> + dev_err_ratelimited(dchid->dev, "checksum error\n");
> + return;
> + }
> +
> + if (payload_len < sizeof(struct dchid_subhdr))
> + return;
> +
> + if (hdr->iface >= MAX_INTERFACES || !dchid->ifaces[hdr->iface])
> + return;
[Severity: High]
Does reading the dchid->ifaces array locklessly in the RX interrupt context
require an acquire barrier? Without READ_ONCE() and corresponding release
semantics on the writer side, a weakly ordered architecture could see a
non-NULL pointer but read uninitialized memory for fields like the workqueue,
leading to a crash.
[ ... ]
> +static int dchid_probe(struct platform_device *pdev)
> +{
[ ... ]
> + dchid->new_iface_wq = alloc_ordered_workqueue("dchid-new", 0);
> + if (!dchid->new_iface_wq)
> + return dev_err_probe(dev, -ENOMEM, "failed to allocate workqueue\n");
[Severity: Medium]
Will this error path leave the ASC coprocessor running and RTKit awake? If
probe fails here after the hardware is started, it returns without calling
apple_rtkit_quiesce() or writing 0 to the control register, which could leak
resources or drain power.
[ ... ]
> +static void dchid_remove(struct platform_device *pdev)
> +{
> + struct dchid_dev *dchid = platform_get_drvdata(pdev);
> + int i;
> +
> + if (dchid->dc_mbox) {
> + devm_release_action(&pdev->dev, dchid_free_mbox, dchid->dc_mbox);
> + dchid->dc_mbox = NULL;
> + }
[Severity: High]
Does freeing the mailbox channel early here introduce a use-after-free risk?
The HID devices and workqueues are still active at this point. If a userspace
process continues to access the HID device concurrently, or if a pending work
item executes and calls dchid_send(), they will attempt to dereference the
freed mailbox channel. Should the teardown order be reversed to destroy
consumers first?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-apple-mtp-keyboard-final-v1-0-506d936a1707@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v5 0/6] gpiolib: fence off legacy interfaces
From: Bartosz Golaszewski @ 2026-06-30 14:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds,
linux-gpio
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
On Mon, 29 Jun 2026 15:03:23 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This is the remainder of the series previously posted as v2
> in [1]. I've changed the version to v5 for all patches to
> not confuse b4 too much, but the patches are mostly unchanged.
>
> The patch "Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY"
> was not part of the series last time, but the build bots reported
> this as a regression since I had dropped that since v1.
>
> I hope that all that remains now can just get merged through the
> gpio tree. The gpio-keys patch needs a bit coordination with
> another patch addressing the same issue that is already in
> flight, so I expect that I'll rebase my series once more when
> that is in a stable branch, but the state I have here should
> just work as-is on top of v7.2-rc1.
>
> Arnd
>
> [1] https://lore.kernel.org/all/20260520183815.2510387-1-arnd@kernel.org/
>
> Arnd Bergmann (6):
> [v5] sh: select legacy gpiolib interface
> [v5] x86/olpc: select GPIOLIB_LEGACY
> [v5] Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY
> [v5] Input: gpio-keys: make legacy gpiolib optional
> [v5] leds: gpio: make legacy gpiolib interface optional
> [v5] gpiolib: turn off legacy interface by default
Why this weird formatting?
Anyway, for the series:
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] HID: cleanup help indentation in kconfig
From: Julian Braha @ 2026-06-30 14:20 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-input, linux-kernel, Julian Braha
The indentation in this kconfig was all over the place:
Half of the 'help' texts were not indented, while the other
half indented by the more standard 2 spaces shown in the
kconfig documentation.
Let's standardize to 2 spaces.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/hid/Kconfig | 660 ++++++++++++++++++++++----------------------
1 file changed, 330 insertions(+), 330 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f9bcaeb66385..9b04ef19a4d2 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -38,77 +38,77 @@ config HID_BATTERY_STRENGTH
select POWER_SUPPLY
default n
help
- This option adds support of reporting battery strength (for HID devices
- that support this feature) through power_supply class so that userspace
- tools, such as upower, can display it.
+ This option adds support of reporting battery strength (for HID devices
+ that support this feature) through power_supply class so that userspace
+ tools, such as upower, can display it.
config HIDRAW
bool "/dev/hidraw raw HID device support"
help
- Say Y here if you want to support HID devices (from the USB
- specification standpoint) that aren't strictly user interface
- devices, like monitor controls and Uninterruptible Power Supplies.
+ Say Y here if you want to support HID devices (from the USB
+ specification standpoint) that aren't strictly user interface
+ devices, like monitor controls and Uninterruptible Power Supplies.
- This module supports these devices separately using a separate
- event interface on /dev/hidraw.
+ This module supports these devices separately using a separate
+ event interface on /dev/hidraw.
- There is also a /dev/hiddev configuration option in the USB HID
- configuration menu. In comparison to hiddev, this device does not process
- the hid events at all (no parsing, no lookups). This lets applications
- to work on raw hid events when they want to, and avoid using transport-specific
- userspace libhid/libusb libraries.
+ There is also a /dev/hiddev configuration option in the USB HID
+ configuration menu. In comparison to hiddev, this device does not process
+ the hid events at all (no parsing, no lookups). This lets applications
+ to work on raw hid events when they want to, and avoid using transport-specific
+ userspace libhid/libusb libraries.
- If unsure, say Y.
+ If unsure, say Y.
config UHID
tristate "User-space I/O driver support for HID subsystem"
default n
help
- Say Y here if you want to provide HID I/O Drivers from user-space.
- This allows to write I/O drivers in user-space and feed the data from
- the device into the kernel. The kernel parses the HID reports, loads the
- corresponding HID Device Driver or provides input devices on top of your
- user-space device.
+ Say Y here if you want to provide HID I/O Drivers from user-space.
+ This allows to write I/O drivers in user-space and feed the data from
+ the device into the kernel. The kernel parses the HID reports, loads the
+ corresponding HID Device Driver or provides input devices on top of your
+ user-space device.
- This driver cannot be used to parse HID-reports in user-space and write
- special HID-drivers. You should use hidraw for that.
- Instead, this driver allows to write the transport-layer driver in
- user-space like USB-HID and Bluetooth-HID do in kernel-space.
+ This driver cannot be used to parse HID-reports in user-space and write
+ special HID-drivers. You should use hidraw for that.
+ Instead, this driver allows to write the transport-layer driver in
+ user-space like USB-HID and Bluetooth-HID do in kernel-space.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called uhid.
+ To compile this driver as a module, choose M here: the
+ module will be called uhid.
config HID_GENERIC
tristate "Generic HID driver"
default HID
help
- Support for generic devices on the HID bus. This includes most
- keyboards and mice, joysticks, tablets and digitizers.
+ Support for generic devices on the HID bus. This includes most
+ keyboards and mice, joysticks, tablets and digitizers.
- To compile this driver as a module, choose M here: the module
- will be called hid-generic.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-generic.
- If unsure, say Y.
+ If unsure, say Y.
config HID_HAPTIC
bool "Haptic touchpad support"
default n
help
- Support for touchpads with force sensors and haptic actuators instead of a
- traditional button.
- Adds extra parsing and FF device for the hid multitouch driver.
- It can be used for Elan 2703 haptic touchpad.
+ Support for touchpads with force sensors and haptic actuators instead of a
+ traditional button.
+ Adds extra parsing and FF device for the hid multitouch driver.
+ It can be used for Elan 2703 haptic touchpad.
- If unsure, say N.
+ If unsure, say N.
menu "Special HID drivers"
config HID_A4TECH
tristate "A4TECH mice"
help
- Support for some A4TECH mice with two scroll wheels.
+ Support for some A4TECH mice with two scroll wheels.
config HID_ACCUTOUCH
tristate "Accutouch touch device"
@@ -118,44 +118,44 @@ config HID_ACCUTOUCH
The driver works around a problem in the reported device capabilities
which causes userspace to detect the device as a mouse rather than
- a touchscreen.
+ a touchscreen.
Say Y here if you have a Accutouch 2216 touch controller.
config HID_ACRUX
tristate "ACRUX game controller support"
help
- Say Y here if you want to enable support for ACRUX game controllers.
+ Say Y here if you want to enable support for ACRUX game controllers.
config HID_ACRUX_FF
bool "ACRUX force feedback support"
depends on HID_ACRUX
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for ACRUX
- game controllers.
+ Say Y here if you want to enable force feedback support for ACRUX
+ game controllers.
config HID_APPLE
tristate "Apple {i,Power,Mac}Books"
depends on LEDS_CLASS
depends on NEW_LEDS
help
- Support for some Apple devices which less or more break
- HID specification.
+ Support for some Apple devices which less or more break
+ HID specification.
- Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
- MacBooks, MacBook Pros and Apple Aluminum.
+ Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
+ MacBooks, MacBook Pros and Apple Aluminum.
config HID_APPLEIR
tristate "Apple infrared receiver"
depends on (USB_HID)
help
- Support for Apple infrared remote control. All the Apple computers from
+ Support for Apple infrared remote control. All the Apple computers from
2005 onwards include such a port, except the unibody Macbook (2009),
and Mac Pros. This receiver is also used in the Apple TV set-top box
prior to the 2010 model.
- Say Y here if you want support for Apple infrared remote control.
+ Say Y here if you want support for Apple infrared remote control.
config HID_APPLETB_BL
tristate "Apple Touch Bar Backlight"
@@ -191,34 +191,34 @@ config HID_ASUS
depends on ASUS_WMI || ASUS_WMI=n
select POWER_SUPPLY
help
- Support for Asus notebook built-in keyboard and touchpad via i2c, and
- the Asus Republic of Gamers laptop keyboard special keys.
+ Support for Asus notebook built-in keyboard and touchpad via i2c, and
+ the Asus Republic of Gamers laptop keyboard special keys.
- Supported devices:
- - EeeBook X205TA
- - VivoBook E200HA
- - GL553V series
- - GL753V series
+ Supported devices:
+ - EeeBook X205TA
+ - VivoBook E200HA
+ - GL553V series
+ - GL753V series
config HID_AUREAL
tristate "Aureal"
help
- Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
+ Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
config HID_BELKIN
tristate "Belkin Flip KVM and Wireless keyboard"
help
- Support for Belkin Flip KVM and Wireless keyboard.
+ Support for Belkin Flip KVM and Wireless keyboard.
config HID_BETOP_FF
tristate "Betop Production Inc. force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- BETOP Production Ltd.
- Currently the following devices are known to be supported:
- - BETOP 2185 PC & BFM MODE
+ Say Y here if you want to enable force feedback support for devices by
+ BETOP Production Ltd.
+ Currently the following devices are known to be supported:
+ - BETOP 2185 PC & BFM MODE
config HID_BIGBEN_FF
tristate "BigBen Interactive Kids' gamepad support"
@@ -235,54 +235,54 @@ config HID_BIGBEN_FF
config HID_CHERRY
tristate "Cherry Cymotion keyboard"
help
- Support for Cherry Cymotion keyboard.
+ Support for Cherry Cymotion keyboard.
config HID_CHICONY
tristate "Chicony devices"
depends on USB_HID
help
- Support for Chicony Tactical pad and special keys on Chicony keyboards.
+ Support for Chicony Tactical pad and special keys on Chicony keyboards.
config HID_CORSAIR
tristate "Corsair devices"
depends on USB_HID && LEDS_CLASS
select POWER_SUPPLY
help
- Support for Corsair devices that are not fully compliant with the
- HID standard.
- Support for Corsair Void headsets.
+ Support for Corsair devices that are not fully compliant with the
+ HID standard.
+ Support for Corsair Void headsets.
- Supported devices:
- - Vengeance K90
- - Scimitar PRO RGB
- - Corsair Void headsets
+ Supported devices:
+ - Vengeance K90
+ - Scimitar PRO RGB
+ - Corsair Void headsets
config HID_COUGAR
tristate "Cougar devices"
help
- Support for Cougar devices that are not fully compliant with the
- HID standard.
+ Support for Cougar devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - Cougar 500k Gaming Keyboard
+ Supported devices:
+ - Cougar 500k Gaming Keyboard
config HID_MACALLY
tristate "Macally devices"
help
- Support for Macally devices that are not fully compliant with the
- HID standard.
+ Support for Macally devices that are not fully compliant with the
+ HID standard.
- supported devices:
- - Macally ikey keyboard
+ supported devices:
+ - Macally ikey keyboard
config HID_PRODIKEYS
tristate "Prodikeys PC-MIDI Keyboard support"
depends on USB_HID && SND
select SND_RAWMIDI
help
- Support for Prodikeys PC-MIDI Keyboard device support.
- Say Y here to enable support for this device.
- - Prodikeys PC-MIDI keyboard.
+ Support for Prodikeys PC-MIDI Keyboard device support.
+ Say Y here to enable support for this device.
+ - Prodikeys PC-MIDI keyboard.
The Prodikeys PC-MIDI acts as a USB Audio device, with one MIDI
input and one MIDI output. These MIDI jacks appear as
a sound "card" in the ALSA sound system.
@@ -293,97 +293,97 @@ config HID_PRODIKEYS
config HID_CMEDIA
tristate "CMedia audio chips"
help
- Support for CMedia CM6533 HID audio jack controls
- and HS100B mute buttons.
+ Support for CMedia CM6533 HID audio jack controls
+ and HS100B mute buttons.
config HID_CP2112
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
depends on USB_HID && HIDRAW && I2C && GPIOLIB
select GPIOLIB_IRQCHIP
help
- Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
- This is a HID device driver which registers as an i2c adapter
- and gpiochip to expose these functions of the CP2112. The
- customizable USB descriptor fields are exposed as sysfs attributes.
+ Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
+ This is a HID device driver which registers as an i2c adapter
+ and gpiochip to expose these functions of the CP2112. The
+ customizable USB descriptor fields are exposed as sysfs attributes.
config HID_CREATIVE_SB0540
tristate "Creative SB0540 infrared receiver"
depends on USB_HID
help
- Support for Creative infrared SB0540-compatible remote controls, such
- as the RM-1500 and RM-1800 remotes.
+ Support for Creative infrared SB0540-compatible remote controls, such
+ as the RM-1500 and RM-1800 remotes.
- Say Y here if you want support for Creative SB0540 infrared receiver.
+ Say Y here if you want support for Creative SB0540 infrared receiver.
config HID_CYPRESS
tristate "Cypress mouse and barcode readers"
help
- Support for cypress mouse and barcode readers.
+ Support for cypress mouse and barcode readers.
config HID_DRAGONRISE
tristate "DragonRise Inc. game controller"
help
- Say Y here if you have DragonRise Inc. game controllers.
- These might be branded as:
- - Tesun USB-703
- - Media-tech MT1504 "Rogue"
- - DVTech JS19 "Gear"
- - Defender Game Master
+ Say Y here if you have DragonRise Inc. game controllers.
+ These might be branded as:
+ - Tesun USB-703
+ - Media-tech MT1504 "Rogue"
+ - DVTech JS19 "Gear"
+ - Defender Game Master
config DRAGONRISE_FF
bool "DragonRise Inc. force feedback"
depends on HID_DRAGONRISE
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for DragonRise Inc.
- game controllers.
+ Say Y here if you want to enable force feedback support for DragonRise Inc.
+ game controllers.
config HID_EMS_FF
tristate "EMS Production Inc. force feedback support"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- EMS Production Ltd.
- Currently the following devices are known to be supported:
- - Trio Linker Plus II
+ Say Y here if you want to enable force feedback support for devices by
+ EMS Production Ltd.
+ Currently the following devices are known to be supported:
+ - Trio Linker Plus II
config HID_ELAN
tristate "ELAN USB Touchpad Support"
depends on LEDS_CLASS && USB_HID
help
- Say Y to enable support for the USB ELAN touchpad
- Currently the following devices are known to be supported:
- - HP Pavilion X2 10-p0XX.
+ Say Y to enable support for the USB ELAN touchpad
+ Currently the following devices are known to be supported:
+ - HP Pavilion X2 10-p0XX.
config HID_ELECOM
tristate "ELECOM HID devices"
help
- Support for ELECOM devices:
- - BM084 Bluetooth Mouse
- - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
- - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
- - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
- - HUGE Plus Trackball (M-HT1MRBK)
+ Support for ELECOM devices:
+ - BM084 Bluetooth Mouse
+ - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
+ - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
+ - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
+ - HUGE Plus Trackball (M-HT1MRBK)
config HID_ELO
tristate "ELO USB 4000/4500 touchscreen"
depends on USB_HID
help
- Support for the ELO USB 4000/4500 touchscreens. Note that this is for
- different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
+ Support for the ELO USB 4000/4500 touchscreens. Note that this is for
+ different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
config HID_EVISION
tristate "EVision Keyboards Support"
depends on HID
help
- Support for some EVision keyboards. Note that this is needed only when
- applying customization using userspace programs.
- Support for some EVision devices requiring report descriptor fixups.
+ Support for some EVision keyboards. Note that this is needed only when
+ applying customization using userspace programs.
+ Support for some EVision devices requiring report descriptor fixups.
config HID_EZKEY
tristate "Ezkey BTC 8193 keyboard"
help
- Support for Ezkey BTC 8193 keyboard.
+ Support for Ezkey BTC 8193 keyboard.
config HID_FT260
tristate "FTDI FT260 USB HID to I2C host support"
@@ -399,12 +399,12 @@ config HID_FT260
config HID_GEMBIRD
tristate "Gembird Joypad"
help
- Support for Gembird JPD-DualForce 2.
+ Support for Gembird JPD-DualForce 2.
config HID_GFRM
tristate "Google Fiber TV Box remote control support"
help
- Support for Google Fiber TV Box remote controls
+ Support for Google Fiber TV Box remote controls
config HID_GLORIOUS
tristate "Glorious PC Gaming Race mice"
@@ -416,14 +416,14 @@ config HID_HOLTEK
tristate "Holtek HID devices"
depends on USB_HID
help
- Support for Holtek based devices:
- - Holtek On Line Grip based game controller
- - Trust GXT 18 Gaming Keyboard
- - Sharkoon Drakonia / Perixx MX-2000 gaming mice
- - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
- Zalman ZM-GM1
- - SHARKOON DarkGlider Gaming mouse
- - LEETGION Hellion Gaming Mouse
+ Support for Holtek based devices:
+ - Holtek On Line Grip based game controller
+ - Trust GXT 18 Gaming Keyboard
+ - Sharkoon Drakonia / Perixx MX-2000 gaming mice
+ - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
+ Zalman ZM-GM1
+ - SHARKOON DarkGlider Gaming mouse
+ - LEETGION Hellion Gaming Mouse
config HOLTEK_FF
bool "Holtek On Line Grip force feedback support"
@@ -452,14 +452,14 @@ config HID_GOOGLE_HAMMER
select INPUT_VIVALDIFMAP
depends on USB_HID && LEDS_CLASS && CROS_EC
help
- Say Y here if you have a Google Hammer device.
+ Say Y here if you have a Google Hammer device.
config HID_GOOGLE_STADIA_FF
tristate "Google Stadia force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Google
- Stadia controller.
+ Say Y here if you want to enable force feedback support for the Google
+ Stadia controller.
config HID_VIVALDI
tristate "Vivaldi Keyboard"
@@ -475,51 +475,51 @@ config HID_GT683R
tristate "MSI GT68xR LED support"
depends on LEDS_CLASS && USB_HID
help
- Say Y here if you want to enable support for the three MSI GT68xR LEDs
+ Say Y here if you want to enable support for the three MSI GT68xR LEDs
- This driver support following modes:
- - Normal: LEDs are fully on when enabled
- - Audio: LEDs brightness depends on sound level
- - Breathing: LEDs brightness varies at human breathing rate
+ This driver support following modes:
+ - Normal: LEDs are fully on when enabled
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
- Currently the following devices are know to be supported:
- - MSI GT683R
+ Currently the following devices are know to be supported:
+ - MSI GT683R
config HID_KEYTOUCH
tristate "Keytouch HID devices"
help
- Support for Keytouch HID devices not fully compliant with
- the specification. Currently supported:
+ Support for Keytouch HID devices not fully compliant with
+ the specification. Currently supported:
- Keytouch IEC 60945
config HID_KYE
tristate "KYE/Genius devices"
help
- Support for KYE/Genius devices not fully compliant with HID standard:
- - Ergo Mouse
- - EasyPen i405X tablet
- - MousePen i608X tablet
- - EasyPen M610X tablet
+ Support for KYE/Genius devices not fully compliant with HID standard:
+ - Ergo Mouse
+ - EasyPen i405X tablet
+ - MousePen i608X tablet
+ - EasyPen M610X tablet
config HID_KYSONA
tristate "Kysona devices"
depends on USB_HID
help
- Support for Kysona mice.
+ Support for Kysona mice.
- Say Y here if you have a Kysona M600 mouse
- and want to be able to read its battery capacity.
+ Say Y here if you have a Kysona M600 mouse
+ and want to be able to read its battery capacity.
config HID_UCLOGIC
tristate "UC-Logic"
depends on USB_HID
help
- Support for UC-Logic and Huion tablets.
+ Support for UC-Logic and Huion tablets.
config HID_WALTOP
tristate "Waltop"
help
- Support for Waltop tablets.
+ Support for Waltop tablets.
config HID_VIEWSONIC
tristate "ViewSonic/Signotec"
@@ -530,11 +530,11 @@ config HID_VRC2
tristate "VRC-2 Car Controller"
depends on HID
help
- Support for VRC-2 which is a 2-axis controller often used in
- car simulators.
+ Support for VRC-2 which is a 2-axis controller often used in
+ car simulators.
- To compile this driver as a module, choose M here: the
- module will be called hid-vrc2.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-vrc2.
config HID_XIAOMI
tristate "Xiaomi"
@@ -545,95 +545,95 @@ config HID_XIAOMI
config HID_GYRATION
tristate "Gyration remote control"
help
- Support for Gyration remote control.
+ Support for Gyration remote control.
config HID_ICADE
tristate "ION iCade arcade controller"
help
- Support for the ION iCade arcade controller to work as a joystick.
+ Support for the ION iCade arcade controller to work as a joystick.
- To compile this driver as a module, choose M here: the
- module will be called hid-icade.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-icade.
config HID_ITE
tristate "ITE devices"
help
- Support for ITE devices not fully compliant with HID standard.
+ Support for ITE devices not fully compliant with HID standard.
config HID_JABRA
tristate "Jabra USB HID Driver"
help
- Support for Jabra USB HID devices.
+ Support for Jabra USB HID devices.
- Prevents mapping of vendor defined HID usages to input events. Without
- this driver HID reports from Jabra devices may incorrectly be seen as
- mouse button events.
- Say M here if you may ever plug in a Jabra USB device.
+ Prevents mapping of vendor defined HID usages to input events. Without
+ this driver HID reports from Jabra devices may incorrectly be seen as
+ mouse button events.
+ Say M here if you may ever plug in a Jabra USB device.
config HID_TWINHAN
tristate "Twinhan IR remote control"
help
- Support for Twinhan IR remote control.
+ Support for Twinhan IR remote control.
config HID_KENSINGTON
tristate "Kensington Slimblade Trackball"
help
- Support for Kensington Slimblade Trackball.
+ Support for Kensington Slimblade Trackball.
config HID_LCPOWER
tristate "LC-Power"
help
- Support for LC-Power RC1000MCE RF remote control.
+ Support for LC-Power RC1000MCE RF remote control.
config HID_LED
tristate "Simple RGB LED support"
depends on LEDS_CLASS
help
- Support for simple RGB LED devices. Currently supported are:
- - Riso Kagaku Webmail Notifier
- - Dream Cheeky Webmail Notifier and Friends Alert
- - ThingM blink(1)
- - Delcom Visual Signal Indicator Generation 2
- - Greynut Luxafor
+ Support for simple RGB LED devices. Currently supported are:
+ - Riso Kagaku Webmail Notifier
+ - Dream Cheeky Webmail Notifier and Friends Alert
+ - ThingM blink(1)
+ - Delcom Visual Signal Indicator Generation 2
+ - Greynut Luxafor
- To compile this driver as a module, choose M here: the
- module will be called hid-led.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-led.
config HID_LENOVO
tristate "Lenovo / Thinkpad devices"
depends on LEDS_CLASS
help
- Support for IBM/Lenovo devices that are not fully compliant with HID standard.
+ Support for IBM/Lenovo devices that are not fully compliant with HID standard.
- Say Y if you want support for horizontal scrolling of the IBM/Lenovo
- Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
- standalone keyboards, e.g:
- - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
- configuration)
- - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
- - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
+ Say Y if you want support for horizontal scrolling of the IBM/Lenovo
+ Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
+ standalone keyboards, e.g:
+ - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
+ configuration)
+ - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
+ - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
config HID_LENOVO_GO
tristate "HID Driver for Lenovo Legion Go Series Controllers"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go devices with detachable controllers.
+ Support for Lenovo Legion Go devices with detachable controllers.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- and Legion Go 2 Handheld Console Controllers. Say M here to compile this
- driver as a module. The module will be called hid-lenovo-go.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ and Legion Go 2 Handheld Console Controllers. Say M here to compile this
+ driver as a module. The module will be called hid-lenovo-go.
config HID_LENOVO_GO_S
tristate "HID Driver for Lenovo Legion Go S Controller"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go S Handheld Console Controller.
+ Support for Lenovo Legion Go S Handheld Console Controller.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- S. Say M here to compile this driver as a module. The module will be called
- hid-lenovo-go-s.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ S. Say M here to compile this driver as a module. The module will be called
+ hid-lenovo-go-s.
config HID_LETSKETCH
tristate "Letsketch WP9620N tablets"
@@ -655,7 +655,7 @@ config HID_LOGITECH
depends on LEDS_CLASS
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Logitech devices that are not fully compliant with HID standard.
+ Support for Logitech devices that are not fully compliant with HID standard.
config HID_LOGITECH_DJ
tristate "Logitech receivers full support"
@@ -664,23 +664,23 @@ config HID_LOGITECH_DJ
depends on HID_LOGITECH
select HID_LOGITECH_HIDPP
help
- Say Y if you want support for Logitech receivers and devices.
- Logitech receivers are capable of pairing multiple Logitech compliant
- devices to the same receiver. Without this driver it will be handled by
- generic USB_HID driver and all incoming events will be multiplexed
- into a single mouse and a single keyboard device.
+ Say Y if you want support for Logitech receivers and devices.
+ Logitech receivers are capable of pairing multiple Logitech compliant
+ devices to the same receiver. Without this driver it will be handled by
+ generic USB_HID driver and all incoming events will be multiplexed
+ into a single mouse and a single keyboard device.
config HID_LOGITECH_HIDPP
tristate "Logitech HID++ devices support"
depends on HID_LOGITECH
select POWER_SUPPLY
help
- Support for Logitech devices relying on the HID++ Logitech specification
+ Support for Logitech devices relying on the HID++ Logitech specification
- Say Y if you want support for Logitech devices relying on the HID++
- specification. Such devices are the various Logitech Touchpads (T650,
- T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
- Keyboard).
+ Say Y if you want support for Logitech devices relying on the HID++
+ specification. Such devices are the various Logitech Touchpads (T650,
+ T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
+ Keyboard).
config LOGITECH_FF
bool "Logitech force feedback support"
@@ -740,31 +740,31 @@ config LOGIWHEELS_FF
config HID_MAGICMOUSE
tristate "Apple Magic Mouse/Trackpad multi-touch support"
help
- Support for the Apple Magic Mouse/Trackpad multi-touch.
+ Support for the Apple Magic Mouse/Trackpad multi-touch.
- Say Y here if you want support for the multi-touch features of the
- Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
+ Say Y here if you want support for the multi-touch features of the
+ Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
config HID_MALTRON
tristate "Maltron L90 keyboard"
help
- Adds support for the volume up, volume down, mute, and play/pause buttons
- of the Maltron L90 keyboard.
+ Adds support for the volume up, volume down, mute, and play/pause buttons
+ of the Maltron L90 keyboard.
config HID_MAYFLASH
tristate "Mayflash game controller adapter force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you have HJZ Mayflash PS3 game controller adapters
- and want to enable force feedback support.
+ Say Y here if you have HJZ Mayflash PS3 game controller adapters
+ and want to enable force feedback support.
config HID_MEGAWORLD_FF
tristate "Mega World based game controller force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Mega World based game controller and want
- to have force feedback support for it.
+ Say Y here if you have a Mega World based game controller and want
+ to have force feedback support for it.
config HID_RAKK
tristate "Rakk support"
@@ -778,18 +778,18 @@ config HID_RAKK
config HID_REDRAGON
tristate "Redragon keyboards"
help
- Support for Redragon keyboards that need fix-ups to work properly.
+ Support for Redragon keyboards that need fix-ups to work properly.
config HID_MICROSOFT
tristate "Microsoft non-fully HID-compliant devices"
select INPUT_FF_MEMLESS
help
- Support for Microsoft devices that are not fully compliant with HID standard.
+ Support for Microsoft devices that are not fully compliant with HID standard.
config HID_MONTEREY
tristate "Monterey Genius KB29E keyboard"
help
- Support for Monterey Genius KB29E.
+ Support for Monterey Genius KB29E.
config HID_MULTITOUCH
tristate "HID Multitouch panels"
@@ -843,35 +843,35 @@ config HID_NINTENDO
depends on LEDS_CLASS
select POWER_SUPPLY
help
- Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
- All controllers support bluetooth, and the Pro Controller also supports
- its USB mode. This also includes support for the Nintendo Switch Online
- Controllers which include the NES, Genesis, SNES, and N64 controllers.
+ Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
+ All controllers support bluetooth, and the Pro Controller also supports
+ its USB mode. This also includes support for the Nintendo Switch Online
+ Controllers which include the NES, Genesis, SNES, and N64 controllers.
- To compile this driver as a module, choose M here: the
- module will be called hid-nintendo.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-nintendo.
config NINTENDO_FF
bool "Nintendo Switch controller force feedback support"
depends on HID_NINTENDO
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Nintendo Switch controller and want to enable
- force feedback support for it. This works for both joy-cons, the pro
- controller, and the NSO N64 controller. For the pro controller, both
- rumble motors can be controlled individually.
+ Say Y here if you have a Nintendo Switch controller and want to enable
+ force feedback support for it. This works for both joy-cons, the pro
+ controller, and the NSO N64 controller. For the pro controller, both
+ rumble motors can be controlled individually.
config HID_NTI
tristate "NTI keyboard adapters"
help
- Support for the "extra" Sun keyboard keys on keyboards attached
- through Network Technologies USB-SUN keyboard adapters.
+ Support for the "extra" Sun keyboard keys on keyboards attached
+ through Network Technologies USB-SUN keyboard adapters.
config HID_NTRIG
tristate "N-Trig touch screen"
depends on USB_HID
help
- Support for N-Trig touch screen.
+ Support for N-Trig touch screen.
config HID_NVIDIA_SHIELD
tristate "NVIDIA SHIELD devices"
@@ -896,14 +896,14 @@ config NVIDIA_SHIELD_FF
config HID_ORTEK
tristate "Ortek PKB-1700/WKB-2000/Skycable wireless keyboard and mouse trackpad"
help
- There are certain devices which have LogicalMaximum wrong in the keyboard
- usage page of their report descriptor. The most prevailing ones so far
- are manufactured by Ortek, thus the name of the driver. Currently
- supported devices by this driver are
+ There are certain devices which have LogicalMaximum wrong in the keyboard
+ usage page of their report descriptor. The most prevailing ones so far
+ are manufactured by Ortek, thus the name of the driver. Currently
+ supported devices by this driver are
- - Ortek PKB-1700
- - Ortek WKB-2000
- - Skycable wireless presenter
+ - Ortek PKB-1700
+ - Ortek WKB-2000
+ - Skycable wireless presenter
config HID_OXP
tristate "OneXPlayer handheld controller configuration support"
@@ -946,7 +946,7 @@ config HID_PENMOUNT
config HID_PETALYNX
tristate "Petalynx Maxter remote control"
help
- Support for Petalynx Maxter remote control.
+ Support for Petalynx Maxter remote control.
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
@@ -1038,77 +1038,77 @@ config PLAYSTATION_FF
PlayStation game controllers.
config HID_PXRC
- tristate "PhoenixRC HID Flight Controller"
- depends on HID
- help
- Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
+ tristate "PhoenixRC HID Flight Controller"
+ depends on HID
+ help
+ Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
- To compile this driver as a module, choose M here: the
- module will be called hid-pxrc.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-pxrc.
config HID_RAPOO
tristate "Rapoo non-fully HID-compliant devices"
help
- Support for Rapoo devices that are not fully compliant with the
- HID standard.
+ Support for Rapoo devices that are not fully compliant with the
+ HID standard.
config HID_RAZER
tristate "Razer non-fully HID-compliant devices"
help
- Support for Razer devices that are not fully compliant with the
- HID standard.
+ Support for Razer devices that are not fully compliant with the
+ HID standard.
config HID_PRIMAX
tristate "Primax non-fully HID-compliant devices"
help
- Support for Primax devices that are not fully compliant with the
- HID standard.
+ Support for Primax devices that are not fully compliant with the
+ HID standard.
config HID_RETRODE
tristate "Retrode 2 USB adapter for vintage video games"
depends on USB_HID
help
- Support for
- * Retrode 2 cartridge and controller adapter
+ Support for
+ * Retrode 2 cartridge and controller adapter
config HID_ROCCAT
tristate "Roccat device support"
depends on USB_HID
help
- Support for Roccat devices.
- Say Y here if you have a Roccat mouse or keyboard and want
- support for its special functionalities.
+ Support for Roccat devices.
+ Say Y here if you have a Roccat mouse or keyboard and want
+ support for its special functionalities.
config HID_SAITEK
tristate "Saitek (Mad Catz) non-fully HID-compliant devices"
help
- Support for Saitek devices that are not fully compliant with the
- HID standard.
+ Support for Saitek devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - PS1000 Dual Analog Pad
- - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
- - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
+ Supported devices:
+ - PS1000 Dual Analog Pad
+ - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
+ - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
config HID_SAMSUNG
tristate "Samsung InfraRed remote control or keyboards"
depends on USB_HID
help
- Support for Samsung InfraRed remote control or keyboards.
+ Support for Samsung InfraRed remote control or keyboards.
config HID_SEMITEK
tristate "Semitek USB keyboards"
help
- Support for Semitek USB keyboards that are not fully compliant
- with the HID standard.
+ Support for Semitek USB keyboards that are not fully compliant
+ with the HID standard.
- There are many variants, including:
- - GK61, GK64, GK68, GK84, GK96, etc.
- - SK61, SK64, SK68, SK84, SK96, etc.
- - Dierya DK61/DK66
- - Tronsmart TK09R
- - Woo-dy
- - X-Bows Nature/Knight
+ There are many variants, including:
+ - GK61, GK64, GK68, GK84, GK96, etc.
+ - SK61, SK64, SK68, SK84, SK96, etc.
+ - Dierya DK61/DK66
+ - Tronsmart TK09R
+ - Woo-dy
+ - X-Bows Nature/Knight
config HID_SIGMAMICRO
tristate "SiGma Micro-based keyboards"
@@ -1128,58 +1128,58 @@ config HID_SONY
select POWER_SUPPLY
select CRC32
help
- Support for
+ Support for
- * Sixaxis controllers for PS3
- * Buzz controllers
- * Blu-ray Disc Remote Control for PS3
- * Logitech Harmony adapter for PS3
- * Guitar Hero Live PS3, Wii U and PS4 guitars
- * Guitar Hero PS3 and PC guitars
- * Rock Band 1, 2 and 3 PS3 and Wii instruments
- * Rock Band 4 PS4 and PS5 guitars
- * DJ Hero Turntable for PS3
+ * Sixaxis controllers for PS3
+ * Buzz controllers
+ * Blu-ray Disc Remote Control for PS3
+ * Logitech Harmony adapter for PS3
+ * Guitar Hero Live PS3, Wii U and PS4 guitars
+ * Guitar Hero PS3 and PC guitars
+ * Rock Band 1, 2 and 3 PS3 and Wii instruments
+ * Rock Band 4 PS4 and PS5 guitars
+ * DJ Hero Turntable for PS3
config SONY_FF
bool "Sony PS2/3/4 accessories force feedback support"
depends on HID_SONY
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Sony PS2/3/4 accessory and want to enable
- force feedback support for it.
+ Say Y here if you have a Sony PS2/3/4 accessory and want to enable
+ force feedback support for it.
config HID_SPEEDLINK
tristate "Speedlink VAD Cezanne mouse support"
help
- Support for Speedlink Vicious and Divine Cezanne mouse.
+ Support for Speedlink Vicious and Divine Cezanne mouse.
config HID_STEAM
tristate "Steam Controller/Deck support"
select POWER_SUPPLY
help
- Say Y here if you have a Steam Controller or Deck if you want to use it
- without running the Steam Client. It supports both the wired and
- the wireless adaptor.
+ Say Y here if you have a Steam Controller or Deck if you want to use it
+ without running the Steam Client. It supports both the wired and
+ the wireless adaptor.
config STEAM_FF
bool "Steam Deck force feedback support"
depends on HID_STEAM
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Steam
- Deck.
+ Say Y here if you want to enable force feedback support for the Steam
+ Deck.
config HID_STEELSERIES
tristate "Steelseries devices support"
depends on USB_HID
help
- Support for Steelseries SRW-S1 steering wheel, and the Steelseries
- Arctis 1 Wireless for XBox headset.
+ Support for Steelseries SRW-S1 steering wheel, and the Steelseries
+ Arctis 1 Wireless for XBox headset.
config HID_SUNPLUS
tristate "Sunplus wireless desktop"
help
- Support for Sunplus wireless desktop.
+ Support for Sunplus wireless desktop.
config HID_RMI
tristate "Synaptics RMI4 device support"
@@ -1190,9 +1190,9 @@ config HID_RMI
select RMI4_F30
select RMI4_F3A
help
- Support for Synaptics RMI4 touchpads.
- Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Synaptics RMI4 touchpads.
+ Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_GREENASIA
tristate "GreenAsia (Product ID 0x12) game controller support"
@@ -1205,43 +1205,43 @@ config GREENASIA_FF
depends on HID_GREENASIA
select INPUT_FF_MEMLESS
help
- Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
- (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
- and want to enable force feedback support for it.
+ Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
+ (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
+ and want to enable force feedback support for it.
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
depends on HYPERV_VMBUS
help
- Select this option to enable the Hyper-V mouse driver.
+ Select this option to enable the Hyper-V mouse driver.
config HID_SMARTJOYPLUS
tristate "SmartJoy PLUS PS2/USB adapter support"
help
- Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
- Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
+ Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
+ Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
- Note that DDR (Dance Dance Revolution) mode is not supported, nor
- is pressure sensitive buttons on the pro models.
+ Note that DDR (Dance Dance Revolution) mode is not supported, nor
+ is pressure sensitive buttons on the pro models.
config SMARTJOYPLUS_FF
bool "SmartJoy PLUS PS2/USB adapter force feedback support"
depends on HID_SMARTJOYPLUS
select INPUT_FF_MEMLESS
help
- Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
- enable force feedback support for it.
+ Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
+ enable force feedback support for it.
config HID_TIVO
tristate "TiVo Slide Bluetooth remote control support"
help
- Say Y if you have a TiVo Slide Bluetooth remote control.
+ Say Y if you have a TiVo Slide Bluetooth remote control.
config HID_TOPSEED
tristate "TopSeed Cyberlink, BTC Emprex, Conceptronic remote control support"
help
- Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
- CLLRCMCE remote control.
+ Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
+ CLLRCMCE remote control.
config HID_TOPRE
tristate "Topre REALFORCE keyboards"
@@ -1255,9 +1255,9 @@ config HID_THINGM
depends on LEDS_CLASS
select HID_LED
help
- Support for the ThingM blink(1) USB RGB LED. This driver has been
- merged into the generic hid led driver. Config symbol HID_THINGM
- just selects HID_LED and will be removed soon.
+ Support for the ThingM blink(1) USB RGB LED. This driver has been
+ merged into the generic hid led driver. Config symbol HID_THINGM
+ just selects HID_LED and will be removed soon.
config HID_THRUSTMASTER
tristate "ThrustMaster devices support"
@@ -1332,23 +1332,23 @@ config HID_WIIMOTE
select POWER_SUPPLY
select INPUT_FF_MEMLESS
help
- Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
- devices are the Wii Remote and its extension devices, but also devices
- based on the Wii Remote like the Wii U Pro Controller or the
- Wii Balance Board.
+ Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
+ devices are the Wii Remote and its extension devices, but also devices
+ based on the Wii Remote like the Wii U Pro Controller or the
+ Wii Balance Board.
- Support for all official Nintendo extensions is available, however, 3rd
- party extensions might not be supported. Please report these devices to:
+ Support for all official Nintendo extensions is available, however, 3rd
+ party extensions might not be supported. Please report these devices to:
http://github.com/dvdhrm/xwiimote/issues
- Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
- the Wii U Gamepad) might be supported in the future. But currently
- support is limited to Bluetooth based devices.
+ Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
+ the Wii U Gamepad) might be supported in the future. But currently
+ support is limited to Bluetooth based devices.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called hid-wiimote.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-wiimote.
config HID_WINWING
tristate "WinWing Orion2 throttle support"
@@ -1371,9 +1371,9 @@ config HID_WINWING
config HID_XINMO
tristate "Xin-Mo non-fully compliant devices"
help
- Support for Xin-Mo devices that are not fully compliant with the HID
- standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
- if you have a Xin-Mo Dual Arcade controller.
+ Support for Xin-Mo devices that are not fully compliant with the HID
+ standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
+ if you have a Xin-Mo Dual Arcade controller.
config HID_ZEROPLUS
tristate "Zeroplus based game controller support"
@@ -1391,7 +1391,7 @@ config ZEROPLUS_FF
config HID_ZYDACRON
tristate "Zydacron remote control support"
help
- Support for Zydacron remote control.
+ Support for Zydacron remote control.
config HID_SENSOR_HUB
tristate "HID Sensors framework support"
@@ -1425,9 +1425,9 @@ config HID_SENSOR_CUSTOM_SENSOR
config HID_ALPS
tristate "Alps HID device support"
help
- Support for Alps I2C HID touchpads and StickPointer.
- Say Y here if you have a Alps touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Alps I2C HID touchpads and StickPointer.
+ Say Y here if you have a Alps touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_MCP2200
tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
@@ -1444,11 +1444,11 @@ config HID_MCP2221
imply GPIOLIB
imply IIO
help
- Provides I2C and SMBUS host adapter functionality over USB-HID
- through MCP2221 device.
+ Provides I2C and SMBUS host adapter functionality over USB-HID
+ through MCP2221 device.
- To compile this driver as a module, choose M here: the module
- will be called hid-mcp2221.ko.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-mcp2221.ko.
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] HID: cleanup help indentation in kconfig
From: sashiko-bot @ 2026-06-30 14:33 UTC (permalink / raw)
To: Julian Braha; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260630142043.496559-1-julianbraha@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Malformed Kconfig help text indentation in `config HID_LENOVO` introduces a syntax error that breaks the kernel configuration process.
--
commit a32d9e3aafce015a8cfc25d49c3d96d9d8d186de
Author: Julian Braha <julianbraha@gmail.com>
HID: cleanup help indentation in kconfig
This commit standardizes the Kconfig help text indentation in the HID
subsystem to 2 spaces.
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index f9bcaeb66385b..9b04ef19a4d24 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
[ ... ]
> @@ -608,12 +608,12 @@ config HID_LENOVO
> tristate "Lenovo / Thinkpad devices"
> depends on LEDS_CLASS
> help
> - Support for IBM/Lenovo devices that are not fully compliant with HID standard.
> + Support for IBM/Lenovo devices that are not fully compliant with HID standard.
>
> - Say Y if you want support for horizontal scrolling of the IBM/Lenovo
> - Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
> - standalone keyboards, e.g:
> - - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
> - configuration)
> - - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
> - - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
> + Say Y if you want support for horizontal scrolling of the IBM/Lenovo
> + Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
> + standalone keyboards, e.g:
> + - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
> + configuration)
> + - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
> + - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
[Severity: Low]
Does this indentation cause a Kconfig syntax error?
These last two lines in the config HID_LENOVO block appear to be indented
with 6 spaces instead of matching the preceding lines. Because 6 spaces is
less than the indentation of the first line of the help text, the Kconfig
lexer will prematurely terminate the help block here.
Will this cause the parser to treat these lines as top-level Kconfig
statements and result in a syntax error when trying to build or configure
the kernel?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630142043.496559-1-julianbraha@gmail.com?part=1
^ permalink raw reply
* [PATCH v2] HID: cleanup help indentation in kconfig
From: Julian Braha @ 2026-06-30 15:01 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-kernel, linux-input, Julian Braha
The indentation in this kconfig was all over the place:
Half of the 'help' texts were not indented, while the other
half indented by the more standard 2 spaces shown in the
kconfig documentation.
Let's standardize to 2 spaces.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
v2: fix 2 more lines' indentation, thanks sashiko
drivers/hid/Kconfig | 660 ++++++++++++++++++++++----------------------
1 file changed, 330 insertions(+), 330 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f9bcaeb66385..9b55a38b9864 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -38,77 +38,77 @@ config HID_BATTERY_STRENGTH
select POWER_SUPPLY
default n
help
- This option adds support of reporting battery strength (for HID devices
- that support this feature) through power_supply class so that userspace
- tools, such as upower, can display it.
+ This option adds support of reporting battery strength (for HID devices
+ that support this feature) through power_supply class so that userspace
+ tools, such as upower, can display it.
config HIDRAW
bool "/dev/hidraw raw HID device support"
help
- Say Y here if you want to support HID devices (from the USB
- specification standpoint) that aren't strictly user interface
- devices, like monitor controls and Uninterruptible Power Supplies.
+ Say Y here if you want to support HID devices (from the USB
+ specification standpoint) that aren't strictly user interface
+ devices, like monitor controls and Uninterruptible Power Supplies.
- This module supports these devices separately using a separate
- event interface on /dev/hidraw.
+ This module supports these devices separately using a separate
+ event interface on /dev/hidraw.
- There is also a /dev/hiddev configuration option in the USB HID
- configuration menu. In comparison to hiddev, this device does not process
- the hid events at all (no parsing, no lookups). This lets applications
- to work on raw hid events when they want to, and avoid using transport-specific
- userspace libhid/libusb libraries.
+ There is also a /dev/hiddev configuration option in the USB HID
+ configuration menu. In comparison to hiddev, this device does not process
+ the hid events at all (no parsing, no lookups). This lets applications
+ to work on raw hid events when they want to, and avoid using transport-specific
+ userspace libhid/libusb libraries.
- If unsure, say Y.
+ If unsure, say Y.
config UHID
tristate "User-space I/O driver support for HID subsystem"
default n
help
- Say Y here if you want to provide HID I/O Drivers from user-space.
- This allows to write I/O drivers in user-space and feed the data from
- the device into the kernel. The kernel parses the HID reports, loads the
- corresponding HID Device Driver or provides input devices on top of your
- user-space device.
+ Say Y here if you want to provide HID I/O Drivers from user-space.
+ This allows to write I/O drivers in user-space and feed the data from
+ the device into the kernel. The kernel parses the HID reports, loads the
+ corresponding HID Device Driver or provides input devices on top of your
+ user-space device.
- This driver cannot be used to parse HID-reports in user-space and write
- special HID-drivers. You should use hidraw for that.
- Instead, this driver allows to write the transport-layer driver in
- user-space like USB-HID and Bluetooth-HID do in kernel-space.
+ This driver cannot be used to parse HID-reports in user-space and write
+ special HID-drivers. You should use hidraw for that.
+ Instead, this driver allows to write the transport-layer driver in
+ user-space like USB-HID and Bluetooth-HID do in kernel-space.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called uhid.
+ To compile this driver as a module, choose M here: the
+ module will be called uhid.
config HID_GENERIC
tristate "Generic HID driver"
default HID
help
- Support for generic devices on the HID bus. This includes most
- keyboards and mice, joysticks, tablets and digitizers.
+ Support for generic devices on the HID bus. This includes most
+ keyboards and mice, joysticks, tablets and digitizers.
- To compile this driver as a module, choose M here: the module
- will be called hid-generic.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-generic.
- If unsure, say Y.
+ If unsure, say Y.
config HID_HAPTIC
bool "Haptic touchpad support"
default n
help
- Support for touchpads with force sensors and haptic actuators instead of a
- traditional button.
- Adds extra parsing and FF device for the hid multitouch driver.
- It can be used for Elan 2703 haptic touchpad.
+ Support for touchpads with force sensors and haptic actuators instead of a
+ traditional button.
+ Adds extra parsing and FF device for the hid multitouch driver.
+ It can be used for Elan 2703 haptic touchpad.
- If unsure, say N.
+ If unsure, say N.
menu "Special HID drivers"
config HID_A4TECH
tristate "A4TECH mice"
help
- Support for some A4TECH mice with two scroll wheels.
+ Support for some A4TECH mice with two scroll wheels.
config HID_ACCUTOUCH
tristate "Accutouch touch device"
@@ -118,44 +118,44 @@ config HID_ACCUTOUCH
The driver works around a problem in the reported device capabilities
which causes userspace to detect the device as a mouse rather than
- a touchscreen.
+ a touchscreen.
Say Y here if you have a Accutouch 2216 touch controller.
config HID_ACRUX
tristate "ACRUX game controller support"
help
- Say Y here if you want to enable support for ACRUX game controllers.
+ Say Y here if you want to enable support for ACRUX game controllers.
config HID_ACRUX_FF
bool "ACRUX force feedback support"
depends on HID_ACRUX
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for ACRUX
- game controllers.
+ Say Y here if you want to enable force feedback support for ACRUX
+ game controllers.
config HID_APPLE
tristate "Apple {i,Power,Mac}Books"
depends on LEDS_CLASS
depends on NEW_LEDS
help
- Support for some Apple devices which less or more break
- HID specification.
+ Support for some Apple devices which less or more break
+ HID specification.
- Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
- MacBooks, MacBook Pros and Apple Aluminum.
+ Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
+ MacBooks, MacBook Pros and Apple Aluminum.
config HID_APPLEIR
tristate "Apple infrared receiver"
depends on (USB_HID)
help
- Support for Apple infrared remote control. All the Apple computers from
+ Support for Apple infrared remote control. All the Apple computers from
2005 onwards include such a port, except the unibody Macbook (2009),
and Mac Pros. This receiver is also used in the Apple TV set-top box
prior to the 2010 model.
- Say Y here if you want support for Apple infrared remote control.
+ Say Y here if you want support for Apple infrared remote control.
config HID_APPLETB_BL
tristate "Apple Touch Bar Backlight"
@@ -191,34 +191,34 @@ config HID_ASUS
depends on ASUS_WMI || ASUS_WMI=n
select POWER_SUPPLY
help
- Support for Asus notebook built-in keyboard and touchpad via i2c, and
- the Asus Republic of Gamers laptop keyboard special keys.
+ Support for Asus notebook built-in keyboard and touchpad via i2c, and
+ the Asus Republic of Gamers laptop keyboard special keys.
- Supported devices:
- - EeeBook X205TA
- - VivoBook E200HA
- - GL553V series
- - GL753V series
+ Supported devices:
+ - EeeBook X205TA
+ - VivoBook E200HA
+ - GL553V series
+ - GL753V series
config HID_AUREAL
tristate "Aureal"
help
- Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
+ Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
config HID_BELKIN
tristate "Belkin Flip KVM and Wireless keyboard"
help
- Support for Belkin Flip KVM and Wireless keyboard.
+ Support for Belkin Flip KVM and Wireless keyboard.
config HID_BETOP_FF
tristate "Betop Production Inc. force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- BETOP Production Ltd.
- Currently the following devices are known to be supported:
- - BETOP 2185 PC & BFM MODE
+ Say Y here if you want to enable force feedback support for devices by
+ BETOP Production Ltd.
+ Currently the following devices are known to be supported:
+ - BETOP 2185 PC & BFM MODE
config HID_BIGBEN_FF
tristate "BigBen Interactive Kids' gamepad support"
@@ -235,54 +235,54 @@ config HID_BIGBEN_FF
config HID_CHERRY
tristate "Cherry Cymotion keyboard"
help
- Support for Cherry Cymotion keyboard.
+ Support for Cherry Cymotion keyboard.
config HID_CHICONY
tristate "Chicony devices"
depends on USB_HID
help
- Support for Chicony Tactical pad and special keys on Chicony keyboards.
+ Support for Chicony Tactical pad and special keys on Chicony keyboards.
config HID_CORSAIR
tristate "Corsair devices"
depends on USB_HID && LEDS_CLASS
select POWER_SUPPLY
help
- Support for Corsair devices that are not fully compliant with the
- HID standard.
- Support for Corsair Void headsets.
+ Support for Corsair devices that are not fully compliant with the
+ HID standard.
+ Support for Corsair Void headsets.
- Supported devices:
- - Vengeance K90
- - Scimitar PRO RGB
- - Corsair Void headsets
+ Supported devices:
+ - Vengeance K90
+ - Scimitar PRO RGB
+ - Corsair Void headsets
config HID_COUGAR
tristate "Cougar devices"
help
- Support for Cougar devices that are not fully compliant with the
- HID standard.
+ Support for Cougar devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - Cougar 500k Gaming Keyboard
+ Supported devices:
+ - Cougar 500k Gaming Keyboard
config HID_MACALLY
tristate "Macally devices"
help
- Support for Macally devices that are not fully compliant with the
- HID standard.
+ Support for Macally devices that are not fully compliant with the
+ HID standard.
- supported devices:
- - Macally ikey keyboard
+ supported devices:
+ - Macally ikey keyboard
config HID_PRODIKEYS
tristate "Prodikeys PC-MIDI Keyboard support"
depends on USB_HID && SND
select SND_RAWMIDI
help
- Support for Prodikeys PC-MIDI Keyboard device support.
- Say Y here to enable support for this device.
- - Prodikeys PC-MIDI keyboard.
+ Support for Prodikeys PC-MIDI Keyboard device support.
+ Say Y here to enable support for this device.
+ - Prodikeys PC-MIDI keyboard.
The Prodikeys PC-MIDI acts as a USB Audio device, with one MIDI
input and one MIDI output. These MIDI jacks appear as
a sound "card" in the ALSA sound system.
@@ -293,97 +293,97 @@ config HID_PRODIKEYS
config HID_CMEDIA
tristate "CMedia audio chips"
help
- Support for CMedia CM6533 HID audio jack controls
- and HS100B mute buttons.
+ Support for CMedia CM6533 HID audio jack controls
+ and HS100B mute buttons.
config HID_CP2112
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
depends on USB_HID && HIDRAW && I2C && GPIOLIB
select GPIOLIB_IRQCHIP
help
- Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
- This is a HID device driver which registers as an i2c adapter
- and gpiochip to expose these functions of the CP2112. The
- customizable USB descriptor fields are exposed as sysfs attributes.
+ Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
+ This is a HID device driver which registers as an i2c adapter
+ and gpiochip to expose these functions of the CP2112. The
+ customizable USB descriptor fields are exposed as sysfs attributes.
config HID_CREATIVE_SB0540
tristate "Creative SB0540 infrared receiver"
depends on USB_HID
help
- Support for Creative infrared SB0540-compatible remote controls, such
- as the RM-1500 and RM-1800 remotes.
+ Support for Creative infrared SB0540-compatible remote controls, such
+ as the RM-1500 and RM-1800 remotes.
- Say Y here if you want support for Creative SB0540 infrared receiver.
+ Say Y here if you want support for Creative SB0540 infrared receiver.
config HID_CYPRESS
tristate "Cypress mouse and barcode readers"
help
- Support for cypress mouse and barcode readers.
+ Support for cypress mouse and barcode readers.
config HID_DRAGONRISE
tristate "DragonRise Inc. game controller"
help
- Say Y here if you have DragonRise Inc. game controllers.
- These might be branded as:
- - Tesun USB-703
- - Media-tech MT1504 "Rogue"
- - DVTech JS19 "Gear"
- - Defender Game Master
+ Say Y here if you have DragonRise Inc. game controllers.
+ These might be branded as:
+ - Tesun USB-703
+ - Media-tech MT1504 "Rogue"
+ - DVTech JS19 "Gear"
+ - Defender Game Master
config DRAGONRISE_FF
bool "DragonRise Inc. force feedback"
depends on HID_DRAGONRISE
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for DragonRise Inc.
- game controllers.
+ Say Y here if you want to enable force feedback support for DragonRise Inc.
+ game controllers.
config HID_EMS_FF
tristate "EMS Production Inc. force feedback support"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- EMS Production Ltd.
- Currently the following devices are known to be supported:
- - Trio Linker Plus II
+ Say Y here if you want to enable force feedback support for devices by
+ EMS Production Ltd.
+ Currently the following devices are known to be supported:
+ - Trio Linker Plus II
config HID_ELAN
tristate "ELAN USB Touchpad Support"
depends on LEDS_CLASS && USB_HID
help
- Say Y to enable support for the USB ELAN touchpad
- Currently the following devices are known to be supported:
- - HP Pavilion X2 10-p0XX.
+ Say Y to enable support for the USB ELAN touchpad
+ Currently the following devices are known to be supported:
+ - HP Pavilion X2 10-p0XX.
config HID_ELECOM
tristate "ELECOM HID devices"
help
- Support for ELECOM devices:
- - BM084 Bluetooth Mouse
- - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
- - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
- - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
- - HUGE Plus Trackball (M-HT1MRBK)
+ Support for ELECOM devices:
+ - BM084 Bluetooth Mouse
+ - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
+ - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
+ - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
+ - HUGE Plus Trackball (M-HT1MRBK)
config HID_ELO
tristate "ELO USB 4000/4500 touchscreen"
depends on USB_HID
help
- Support for the ELO USB 4000/4500 touchscreens. Note that this is for
- different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
+ Support for the ELO USB 4000/4500 touchscreens. Note that this is for
+ different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
config HID_EVISION
tristate "EVision Keyboards Support"
depends on HID
help
- Support for some EVision keyboards. Note that this is needed only when
- applying customization using userspace programs.
- Support for some EVision devices requiring report descriptor fixups.
+ Support for some EVision keyboards. Note that this is needed only when
+ applying customization using userspace programs.
+ Support for some EVision devices requiring report descriptor fixups.
config HID_EZKEY
tristate "Ezkey BTC 8193 keyboard"
help
- Support for Ezkey BTC 8193 keyboard.
+ Support for Ezkey BTC 8193 keyboard.
config HID_FT260
tristate "FTDI FT260 USB HID to I2C host support"
@@ -399,12 +399,12 @@ config HID_FT260
config HID_GEMBIRD
tristate "Gembird Joypad"
help
- Support for Gembird JPD-DualForce 2.
+ Support for Gembird JPD-DualForce 2.
config HID_GFRM
tristate "Google Fiber TV Box remote control support"
help
- Support for Google Fiber TV Box remote controls
+ Support for Google Fiber TV Box remote controls
config HID_GLORIOUS
tristate "Glorious PC Gaming Race mice"
@@ -416,14 +416,14 @@ config HID_HOLTEK
tristate "Holtek HID devices"
depends on USB_HID
help
- Support for Holtek based devices:
- - Holtek On Line Grip based game controller
- - Trust GXT 18 Gaming Keyboard
- - Sharkoon Drakonia / Perixx MX-2000 gaming mice
- - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
- Zalman ZM-GM1
- - SHARKOON DarkGlider Gaming mouse
- - LEETGION Hellion Gaming Mouse
+ Support for Holtek based devices:
+ - Holtek On Line Grip based game controller
+ - Trust GXT 18 Gaming Keyboard
+ - Sharkoon Drakonia / Perixx MX-2000 gaming mice
+ - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
+ Zalman ZM-GM1
+ - SHARKOON DarkGlider Gaming mouse
+ - LEETGION Hellion Gaming Mouse
config HOLTEK_FF
bool "Holtek On Line Grip force feedback support"
@@ -452,14 +452,14 @@ config HID_GOOGLE_HAMMER
select INPUT_VIVALDIFMAP
depends on USB_HID && LEDS_CLASS && CROS_EC
help
- Say Y here if you have a Google Hammer device.
+ Say Y here if you have a Google Hammer device.
config HID_GOOGLE_STADIA_FF
tristate "Google Stadia force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Google
- Stadia controller.
+ Say Y here if you want to enable force feedback support for the Google
+ Stadia controller.
config HID_VIVALDI
tristate "Vivaldi Keyboard"
@@ -475,51 +475,51 @@ config HID_GT683R
tristate "MSI GT68xR LED support"
depends on LEDS_CLASS && USB_HID
help
- Say Y here if you want to enable support for the three MSI GT68xR LEDs
+ Say Y here if you want to enable support for the three MSI GT68xR LEDs
- This driver support following modes:
- - Normal: LEDs are fully on when enabled
- - Audio: LEDs brightness depends on sound level
- - Breathing: LEDs brightness varies at human breathing rate
+ This driver support following modes:
+ - Normal: LEDs are fully on when enabled
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
- Currently the following devices are know to be supported:
- - MSI GT683R
+ Currently the following devices are know to be supported:
+ - MSI GT683R
config HID_KEYTOUCH
tristate "Keytouch HID devices"
help
- Support for Keytouch HID devices not fully compliant with
- the specification. Currently supported:
+ Support for Keytouch HID devices not fully compliant with
+ the specification. Currently supported:
- Keytouch IEC 60945
config HID_KYE
tristate "KYE/Genius devices"
help
- Support for KYE/Genius devices not fully compliant with HID standard:
- - Ergo Mouse
- - EasyPen i405X tablet
- - MousePen i608X tablet
- - EasyPen M610X tablet
+ Support for KYE/Genius devices not fully compliant with HID standard:
+ - Ergo Mouse
+ - EasyPen i405X tablet
+ - MousePen i608X tablet
+ - EasyPen M610X tablet
config HID_KYSONA
tristate "Kysona devices"
depends on USB_HID
help
- Support for Kysona mice.
+ Support for Kysona mice.
- Say Y here if you have a Kysona M600 mouse
- and want to be able to read its battery capacity.
+ Say Y here if you have a Kysona M600 mouse
+ and want to be able to read its battery capacity.
config HID_UCLOGIC
tristate "UC-Logic"
depends on USB_HID
help
- Support for UC-Logic and Huion tablets.
+ Support for UC-Logic and Huion tablets.
config HID_WALTOP
tristate "Waltop"
help
- Support for Waltop tablets.
+ Support for Waltop tablets.
config HID_VIEWSONIC
tristate "ViewSonic/Signotec"
@@ -530,11 +530,11 @@ config HID_VRC2
tristate "VRC-2 Car Controller"
depends on HID
help
- Support for VRC-2 which is a 2-axis controller often used in
- car simulators.
+ Support for VRC-2 which is a 2-axis controller often used in
+ car simulators.
- To compile this driver as a module, choose M here: the
- module will be called hid-vrc2.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-vrc2.
config HID_XIAOMI
tristate "Xiaomi"
@@ -545,95 +545,95 @@ config HID_XIAOMI
config HID_GYRATION
tristate "Gyration remote control"
help
- Support for Gyration remote control.
+ Support for Gyration remote control.
config HID_ICADE
tristate "ION iCade arcade controller"
help
- Support for the ION iCade arcade controller to work as a joystick.
+ Support for the ION iCade arcade controller to work as a joystick.
- To compile this driver as a module, choose M here: the
- module will be called hid-icade.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-icade.
config HID_ITE
tristate "ITE devices"
help
- Support for ITE devices not fully compliant with HID standard.
+ Support for ITE devices not fully compliant with HID standard.
config HID_JABRA
tristate "Jabra USB HID Driver"
help
- Support for Jabra USB HID devices.
+ Support for Jabra USB HID devices.
- Prevents mapping of vendor defined HID usages to input events. Without
- this driver HID reports from Jabra devices may incorrectly be seen as
- mouse button events.
- Say M here if you may ever plug in a Jabra USB device.
+ Prevents mapping of vendor defined HID usages to input events. Without
+ this driver HID reports from Jabra devices may incorrectly be seen as
+ mouse button events.
+ Say M here if you may ever plug in a Jabra USB device.
config HID_TWINHAN
tristate "Twinhan IR remote control"
help
- Support for Twinhan IR remote control.
+ Support for Twinhan IR remote control.
config HID_KENSINGTON
tristate "Kensington Slimblade Trackball"
help
- Support for Kensington Slimblade Trackball.
+ Support for Kensington Slimblade Trackball.
config HID_LCPOWER
tristate "LC-Power"
help
- Support for LC-Power RC1000MCE RF remote control.
+ Support for LC-Power RC1000MCE RF remote control.
config HID_LED
tristate "Simple RGB LED support"
depends on LEDS_CLASS
help
- Support for simple RGB LED devices. Currently supported are:
- - Riso Kagaku Webmail Notifier
- - Dream Cheeky Webmail Notifier and Friends Alert
- - ThingM blink(1)
- - Delcom Visual Signal Indicator Generation 2
- - Greynut Luxafor
+ Support for simple RGB LED devices. Currently supported are:
+ - Riso Kagaku Webmail Notifier
+ - Dream Cheeky Webmail Notifier and Friends Alert
+ - ThingM blink(1)
+ - Delcom Visual Signal Indicator Generation 2
+ - Greynut Luxafor
- To compile this driver as a module, choose M here: the
- module will be called hid-led.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-led.
config HID_LENOVO
tristate "Lenovo / Thinkpad devices"
depends on LEDS_CLASS
help
- Support for IBM/Lenovo devices that are not fully compliant with HID standard.
+ Support for IBM/Lenovo devices that are not fully compliant with HID standard.
- Say Y if you want support for horizontal scrolling of the IBM/Lenovo
- Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
- standalone keyboards, e.g:
- - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
- configuration)
- - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
- - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
+ Say Y if you want support for horizontal scrolling of the IBM/Lenovo
+ Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
+ standalone keyboards, e.g:
+ - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
+ configuration)
+ - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
+ - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
config HID_LENOVO_GO
tristate "HID Driver for Lenovo Legion Go Series Controllers"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go devices with detachable controllers.
+ Support for Lenovo Legion Go devices with detachable controllers.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- and Legion Go 2 Handheld Console Controllers. Say M here to compile this
- driver as a module. The module will be called hid-lenovo-go.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ and Legion Go 2 Handheld Console Controllers. Say M here to compile this
+ driver as a module. The module will be called hid-lenovo-go.
config HID_LENOVO_GO_S
tristate "HID Driver for Lenovo Legion Go S Controller"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go S Handheld Console Controller.
+ Support for Lenovo Legion Go S Handheld Console Controller.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- S. Say M here to compile this driver as a module. The module will be called
- hid-lenovo-go-s.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ S. Say M here to compile this driver as a module. The module will be called
+ hid-lenovo-go-s.
config HID_LETSKETCH
tristate "Letsketch WP9620N tablets"
@@ -655,7 +655,7 @@ config HID_LOGITECH
depends on LEDS_CLASS
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Logitech devices that are not fully compliant with HID standard.
+ Support for Logitech devices that are not fully compliant with HID standard.
config HID_LOGITECH_DJ
tristate "Logitech receivers full support"
@@ -664,23 +664,23 @@ config HID_LOGITECH_DJ
depends on HID_LOGITECH
select HID_LOGITECH_HIDPP
help
- Say Y if you want support for Logitech receivers and devices.
- Logitech receivers are capable of pairing multiple Logitech compliant
- devices to the same receiver. Without this driver it will be handled by
- generic USB_HID driver and all incoming events will be multiplexed
- into a single mouse and a single keyboard device.
+ Say Y if you want support for Logitech receivers and devices.
+ Logitech receivers are capable of pairing multiple Logitech compliant
+ devices to the same receiver. Without this driver it will be handled by
+ generic USB_HID driver and all incoming events will be multiplexed
+ into a single mouse and a single keyboard device.
config HID_LOGITECH_HIDPP
tristate "Logitech HID++ devices support"
depends on HID_LOGITECH
select POWER_SUPPLY
help
- Support for Logitech devices relying on the HID++ Logitech specification
+ Support for Logitech devices relying on the HID++ Logitech specification
- Say Y if you want support for Logitech devices relying on the HID++
- specification. Such devices are the various Logitech Touchpads (T650,
- T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
- Keyboard).
+ Say Y if you want support for Logitech devices relying on the HID++
+ specification. Such devices are the various Logitech Touchpads (T650,
+ T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
+ Keyboard).
config LOGITECH_FF
bool "Logitech force feedback support"
@@ -740,31 +740,31 @@ config LOGIWHEELS_FF
config HID_MAGICMOUSE
tristate "Apple Magic Mouse/Trackpad multi-touch support"
help
- Support for the Apple Magic Mouse/Trackpad multi-touch.
+ Support for the Apple Magic Mouse/Trackpad multi-touch.
- Say Y here if you want support for the multi-touch features of the
- Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
+ Say Y here if you want support for the multi-touch features of the
+ Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
config HID_MALTRON
tristate "Maltron L90 keyboard"
help
- Adds support for the volume up, volume down, mute, and play/pause buttons
- of the Maltron L90 keyboard.
+ Adds support for the volume up, volume down, mute, and play/pause buttons
+ of the Maltron L90 keyboard.
config HID_MAYFLASH
tristate "Mayflash game controller adapter force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you have HJZ Mayflash PS3 game controller adapters
- and want to enable force feedback support.
+ Say Y here if you have HJZ Mayflash PS3 game controller adapters
+ and want to enable force feedback support.
config HID_MEGAWORLD_FF
tristate "Mega World based game controller force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Mega World based game controller and want
- to have force feedback support for it.
+ Say Y here if you have a Mega World based game controller and want
+ to have force feedback support for it.
config HID_RAKK
tristate "Rakk support"
@@ -778,18 +778,18 @@ config HID_RAKK
config HID_REDRAGON
tristate "Redragon keyboards"
help
- Support for Redragon keyboards that need fix-ups to work properly.
+ Support for Redragon keyboards that need fix-ups to work properly.
config HID_MICROSOFT
tristate "Microsoft non-fully HID-compliant devices"
select INPUT_FF_MEMLESS
help
- Support for Microsoft devices that are not fully compliant with HID standard.
+ Support for Microsoft devices that are not fully compliant with HID standard.
config HID_MONTEREY
tristate "Monterey Genius KB29E keyboard"
help
- Support for Monterey Genius KB29E.
+ Support for Monterey Genius KB29E.
config HID_MULTITOUCH
tristate "HID Multitouch panels"
@@ -843,35 +843,35 @@ config HID_NINTENDO
depends on LEDS_CLASS
select POWER_SUPPLY
help
- Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
- All controllers support bluetooth, and the Pro Controller also supports
- its USB mode. This also includes support for the Nintendo Switch Online
- Controllers which include the NES, Genesis, SNES, and N64 controllers.
+ Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
+ All controllers support bluetooth, and the Pro Controller also supports
+ its USB mode. This also includes support for the Nintendo Switch Online
+ Controllers which include the NES, Genesis, SNES, and N64 controllers.
- To compile this driver as a module, choose M here: the
- module will be called hid-nintendo.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-nintendo.
config NINTENDO_FF
bool "Nintendo Switch controller force feedback support"
depends on HID_NINTENDO
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Nintendo Switch controller and want to enable
- force feedback support for it. This works for both joy-cons, the pro
- controller, and the NSO N64 controller. For the pro controller, both
- rumble motors can be controlled individually.
+ Say Y here if you have a Nintendo Switch controller and want to enable
+ force feedback support for it. This works for both joy-cons, the pro
+ controller, and the NSO N64 controller. For the pro controller, both
+ rumble motors can be controlled individually.
config HID_NTI
tristate "NTI keyboard adapters"
help
- Support for the "extra" Sun keyboard keys on keyboards attached
- through Network Technologies USB-SUN keyboard adapters.
+ Support for the "extra" Sun keyboard keys on keyboards attached
+ through Network Technologies USB-SUN keyboard adapters.
config HID_NTRIG
tristate "N-Trig touch screen"
depends on USB_HID
help
- Support for N-Trig touch screen.
+ Support for N-Trig touch screen.
config HID_NVIDIA_SHIELD
tristate "NVIDIA SHIELD devices"
@@ -896,14 +896,14 @@ config NVIDIA_SHIELD_FF
config HID_ORTEK
tristate "Ortek PKB-1700/WKB-2000/Skycable wireless keyboard and mouse trackpad"
help
- There are certain devices which have LogicalMaximum wrong in the keyboard
- usage page of their report descriptor. The most prevailing ones so far
- are manufactured by Ortek, thus the name of the driver. Currently
- supported devices by this driver are
+ There are certain devices which have LogicalMaximum wrong in the keyboard
+ usage page of their report descriptor. The most prevailing ones so far
+ are manufactured by Ortek, thus the name of the driver. Currently
+ supported devices by this driver are
- - Ortek PKB-1700
- - Ortek WKB-2000
- - Skycable wireless presenter
+ - Ortek PKB-1700
+ - Ortek WKB-2000
+ - Skycable wireless presenter
config HID_OXP
tristate "OneXPlayer handheld controller configuration support"
@@ -946,7 +946,7 @@ config HID_PENMOUNT
config HID_PETALYNX
tristate "Petalynx Maxter remote control"
help
- Support for Petalynx Maxter remote control.
+ Support for Petalynx Maxter remote control.
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
@@ -1038,77 +1038,77 @@ config PLAYSTATION_FF
PlayStation game controllers.
config HID_PXRC
- tristate "PhoenixRC HID Flight Controller"
- depends on HID
- help
- Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
+ tristate "PhoenixRC HID Flight Controller"
+ depends on HID
+ help
+ Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
- To compile this driver as a module, choose M here: the
- module will be called hid-pxrc.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-pxrc.
config HID_RAPOO
tristate "Rapoo non-fully HID-compliant devices"
help
- Support for Rapoo devices that are not fully compliant with the
- HID standard.
+ Support for Rapoo devices that are not fully compliant with the
+ HID standard.
config HID_RAZER
tristate "Razer non-fully HID-compliant devices"
help
- Support for Razer devices that are not fully compliant with the
- HID standard.
+ Support for Razer devices that are not fully compliant with the
+ HID standard.
config HID_PRIMAX
tristate "Primax non-fully HID-compliant devices"
help
- Support for Primax devices that are not fully compliant with the
- HID standard.
+ Support for Primax devices that are not fully compliant with the
+ HID standard.
config HID_RETRODE
tristate "Retrode 2 USB adapter for vintage video games"
depends on USB_HID
help
- Support for
- * Retrode 2 cartridge and controller adapter
+ Support for
+ * Retrode 2 cartridge and controller adapter
config HID_ROCCAT
tristate "Roccat device support"
depends on USB_HID
help
- Support for Roccat devices.
- Say Y here if you have a Roccat mouse or keyboard and want
- support for its special functionalities.
+ Support for Roccat devices.
+ Say Y here if you have a Roccat mouse or keyboard and want
+ support for its special functionalities.
config HID_SAITEK
tristate "Saitek (Mad Catz) non-fully HID-compliant devices"
help
- Support for Saitek devices that are not fully compliant with the
- HID standard.
+ Support for Saitek devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - PS1000 Dual Analog Pad
- - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
- - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
+ Supported devices:
+ - PS1000 Dual Analog Pad
+ - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
+ - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
config HID_SAMSUNG
tristate "Samsung InfraRed remote control or keyboards"
depends on USB_HID
help
- Support for Samsung InfraRed remote control or keyboards.
+ Support for Samsung InfraRed remote control or keyboards.
config HID_SEMITEK
tristate "Semitek USB keyboards"
help
- Support for Semitek USB keyboards that are not fully compliant
- with the HID standard.
+ Support for Semitek USB keyboards that are not fully compliant
+ with the HID standard.
- There are many variants, including:
- - GK61, GK64, GK68, GK84, GK96, etc.
- - SK61, SK64, SK68, SK84, SK96, etc.
- - Dierya DK61/DK66
- - Tronsmart TK09R
- - Woo-dy
- - X-Bows Nature/Knight
+ There are many variants, including:
+ - GK61, GK64, GK68, GK84, GK96, etc.
+ - SK61, SK64, SK68, SK84, SK96, etc.
+ - Dierya DK61/DK66
+ - Tronsmart TK09R
+ - Woo-dy
+ - X-Bows Nature/Knight
config HID_SIGMAMICRO
tristate "SiGma Micro-based keyboards"
@@ -1128,58 +1128,58 @@ config HID_SONY
select POWER_SUPPLY
select CRC32
help
- Support for
+ Support for
- * Sixaxis controllers for PS3
- * Buzz controllers
- * Blu-ray Disc Remote Control for PS3
- * Logitech Harmony adapter for PS3
- * Guitar Hero Live PS3, Wii U and PS4 guitars
- * Guitar Hero PS3 and PC guitars
- * Rock Band 1, 2 and 3 PS3 and Wii instruments
- * Rock Band 4 PS4 and PS5 guitars
- * DJ Hero Turntable for PS3
+ * Sixaxis controllers for PS3
+ * Buzz controllers
+ * Blu-ray Disc Remote Control for PS3
+ * Logitech Harmony adapter for PS3
+ * Guitar Hero Live PS3, Wii U and PS4 guitars
+ * Guitar Hero PS3 and PC guitars
+ * Rock Band 1, 2 and 3 PS3 and Wii instruments
+ * Rock Band 4 PS4 and PS5 guitars
+ * DJ Hero Turntable for PS3
config SONY_FF
bool "Sony PS2/3/4 accessories force feedback support"
depends on HID_SONY
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Sony PS2/3/4 accessory and want to enable
- force feedback support for it.
+ Say Y here if you have a Sony PS2/3/4 accessory and want to enable
+ force feedback support for it.
config HID_SPEEDLINK
tristate "Speedlink VAD Cezanne mouse support"
help
- Support for Speedlink Vicious and Divine Cezanne mouse.
+ Support for Speedlink Vicious and Divine Cezanne mouse.
config HID_STEAM
tristate "Steam Controller/Deck support"
select POWER_SUPPLY
help
- Say Y here if you have a Steam Controller or Deck if you want to use it
- without running the Steam Client. It supports both the wired and
- the wireless adaptor.
+ Say Y here if you have a Steam Controller or Deck if you want to use it
+ without running the Steam Client. It supports both the wired and
+ the wireless adaptor.
config STEAM_FF
bool "Steam Deck force feedback support"
depends on HID_STEAM
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Steam
- Deck.
+ Say Y here if you want to enable force feedback support for the Steam
+ Deck.
config HID_STEELSERIES
tristate "Steelseries devices support"
depends on USB_HID
help
- Support for Steelseries SRW-S1 steering wheel, and the Steelseries
- Arctis 1 Wireless for XBox headset.
+ Support for Steelseries SRW-S1 steering wheel, and the Steelseries
+ Arctis 1 Wireless for XBox headset.
config HID_SUNPLUS
tristate "Sunplus wireless desktop"
help
- Support for Sunplus wireless desktop.
+ Support for Sunplus wireless desktop.
config HID_RMI
tristate "Synaptics RMI4 device support"
@@ -1190,9 +1190,9 @@ config HID_RMI
select RMI4_F30
select RMI4_F3A
help
- Support for Synaptics RMI4 touchpads.
- Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Synaptics RMI4 touchpads.
+ Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_GREENASIA
tristate "GreenAsia (Product ID 0x12) game controller support"
@@ -1205,43 +1205,43 @@ config GREENASIA_FF
depends on HID_GREENASIA
select INPUT_FF_MEMLESS
help
- Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
- (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
- and want to enable force feedback support for it.
+ Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
+ (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
+ and want to enable force feedback support for it.
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
depends on HYPERV_VMBUS
help
- Select this option to enable the Hyper-V mouse driver.
+ Select this option to enable the Hyper-V mouse driver.
config HID_SMARTJOYPLUS
tristate "SmartJoy PLUS PS2/USB adapter support"
help
- Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
- Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
+ Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
+ Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
- Note that DDR (Dance Dance Revolution) mode is not supported, nor
- is pressure sensitive buttons on the pro models.
+ Note that DDR (Dance Dance Revolution) mode is not supported, nor
+ is pressure sensitive buttons on the pro models.
config SMARTJOYPLUS_FF
bool "SmartJoy PLUS PS2/USB adapter force feedback support"
depends on HID_SMARTJOYPLUS
select INPUT_FF_MEMLESS
help
- Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
- enable force feedback support for it.
+ Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
+ enable force feedback support for it.
config HID_TIVO
tristate "TiVo Slide Bluetooth remote control support"
help
- Say Y if you have a TiVo Slide Bluetooth remote control.
+ Say Y if you have a TiVo Slide Bluetooth remote control.
config HID_TOPSEED
tristate "TopSeed Cyberlink, BTC Emprex, Conceptronic remote control support"
help
- Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
- CLLRCMCE remote control.
+ Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
+ CLLRCMCE remote control.
config HID_TOPRE
tristate "Topre REALFORCE keyboards"
@@ -1255,9 +1255,9 @@ config HID_THINGM
depends on LEDS_CLASS
select HID_LED
help
- Support for the ThingM blink(1) USB RGB LED. This driver has been
- merged into the generic hid led driver. Config symbol HID_THINGM
- just selects HID_LED and will be removed soon.
+ Support for the ThingM blink(1) USB RGB LED. This driver has been
+ merged into the generic hid led driver. Config symbol HID_THINGM
+ just selects HID_LED and will be removed soon.
config HID_THRUSTMASTER
tristate "ThrustMaster devices support"
@@ -1332,23 +1332,23 @@ config HID_WIIMOTE
select POWER_SUPPLY
select INPUT_FF_MEMLESS
help
- Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
- devices are the Wii Remote and its extension devices, but also devices
- based on the Wii Remote like the Wii U Pro Controller or the
- Wii Balance Board.
+ Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
+ devices are the Wii Remote and its extension devices, but also devices
+ based on the Wii Remote like the Wii U Pro Controller or the
+ Wii Balance Board.
- Support for all official Nintendo extensions is available, however, 3rd
- party extensions might not be supported. Please report these devices to:
+ Support for all official Nintendo extensions is available, however, 3rd
+ party extensions might not be supported. Please report these devices to:
http://github.com/dvdhrm/xwiimote/issues
- Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
- the Wii U Gamepad) might be supported in the future. But currently
- support is limited to Bluetooth based devices.
+ Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
+ the Wii U Gamepad) might be supported in the future. But currently
+ support is limited to Bluetooth based devices.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called hid-wiimote.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-wiimote.
config HID_WINWING
tristate "WinWing Orion2 throttle support"
@@ -1371,9 +1371,9 @@ config HID_WINWING
config HID_XINMO
tristate "Xin-Mo non-fully compliant devices"
help
- Support for Xin-Mo devices that are not fully compliant with the HID
- standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
- if you have a Xin-Mo Dual Arcade controller.
+ Support for Xin-Mo devices that are not fully compliant with the HID
+ standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
+ if you have a Xin-Mo Dual Arcade controller.
config HID_ZEROPLUS
tristate "Zeroplus based game controller support"
@@ -1391,7 +1391,7 @@ config ZEROPLUS_FF
config HID_ZYDACRON
tristate "Zydacron remote control support"
help
- Support for Zydacron remote control.
+ Support for Zydacron remote control.
config HID_SENSOR_HUB
tristate "HID Sensors framework support"
@@ -1425,9 +1425,9 @@ config HID_SENSOR_CUSTOM_SENSOR
config HID_ALPS
tristate "Alps HID device support"
help
- Support for Alps I2C HID touchpads and StickPointer.
- Say Y here if you have a Alps touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Alps I2C HID touchpads and StickPointer.
+ Say Y here if you have a Alps touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_MCP2200
tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
@@ -1444,11 +1444,11 @@ config HID_MCP2221
imply GPIOLIB
imply IIO
help
- Provides I2C and SMBUS host adapter functionality over USB-HID
- through MCP2221 device.
+ Provides I2C and SMBUS host adapter functionality over USB-HID
+ through MCP2221 device.
- To compile this driver as a module, choose M here: the module
- will be called hid-mcp2221.ko.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-mcp2221.ko.
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] HID: cleanup help indentation in kconfig
From: sashiko-bot @ 2026-06-30 15:10 UTC (permalink / raw)
To: Julian Braha; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260630150134.514348-1-julianbraha@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The help text for HID_VRC2 is incorrectly indented with 6 spaces instead of the standard Kconfig indentation.
--
commit 175ea4114d8a3fc5eba72e7a349e9cf65a9b45bd
Author: Julian Braha <julianbraha@gmail.com>
HID: cleanup help indentation in kconfig
This commit standardizes the indentation of help text across the HID Kconfig
file to use 2 spaces, resolving inconsistencies where some texts were not
indented at all.
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
[ ... ]
> @@ -530,11 +530,11 @@ config HID_VRC2
> tristate "VRC-2 Car Controller"
> depends on HID
> help
> - Support for VRC-2 which is a 2-axis controller often used in
> - car simulators.
> + Support for VRC-2 which is a 2-axis controller often used in
> + car simulators.
[Severity: Low]
This isn't a bug, but did the indentation for HID_VRC2 accidentally get set
to 6 spaces here? The standard Kconfig convention expects 1 tab plus 2 spaces,
but this new text appears to be indented less than the help keyword itself,
which contrasts with the commit's stated goal of standardizing indentation.
>
> - To compile this driver as a module, choose M here: the
> - module will be called hid-vrc2.
> + To compile this driver as a module, choose M here: the
> + module will be called hid-vrc2.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630150134.514348-1-julianbraha@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-30 16:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, open list:GPIO SUBSYSTEM, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc @ vger . kernel . org,
linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <ff4d7043-1929-4fa1-ba5e-f28403ad6fcc@app.fastmail.com>
Hi Arnd,
On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> > On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Most remaining users of desc_to_gpio() only call it for printing debug
> >> information.
> >>
> >> Replace this with a new gpiod_name() helper that returns the
> >> gpio_desc->name string after checking the gpio_desc pointer.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> --- a/drivers/gpio/gpio-aggregator.c
> >> +++ b/drivers/gpio/gpio-aggregator.c
> >> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
> >>
> >> fwd->descs[offset] = desc;
> >>
> >> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> >> - desc_to_gpio(desc), gpiod_to_irq(desc));
> >> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> >> + gpiod_name(desc), gpiod_to_irq(desc));
> >>
> >> return 0;
> >> }
> >
> > Before, this printed:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
> >
> > After, this prints:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
> >
> > Same results for instantiation using sysfs or configfs[1], although
> > the latter does have optional support for specifying the name.
>
> I wonder how many of the other instances have the same problem
> then. Would it be appropriate for gpiochip_fwd_desc_add() to set
> a name itself to address this one?
I don't think it would be appropriate for the GPIO aggregator to set
that name. What we want to print here (for debugging) is the physical
GPIO that an aggregator's GPIO is mapped to, not some consumer or line
name (which is not guaranteed to be unique).
E.g. "<chip-name>.<offset>" would be fine. As gpiod_name() can only
return a fixed string or an existing string, it can't return such a
formatted string, though. And consumers don't have access to chip info?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Uwe Kleine-König @ 2026-06-30 17:05 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, linux-input, devicetree, linux-kernel,
linux-leds
In-Reply-To: <20260625081812.33474-6-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
Hello,
On Thu, Jun 25, 2026 at 11:18:11AM +0300, Svyatoslav Ryhel wrote:
> -static const struct of_device_id cpcap_of_match[] = {
> - { .compatible = "motorola,cpcap", },
> - { .compatible = "st,6556002", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> -
> -static const struct spi_device_id cpcap_spi_ids[] = {
> - { .name = "cpcap", },
> - { .name = "6556002", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> [...]
> +static const struct of_device_id cpcap_of_match[] = {
> + { .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
> + { .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, cpcap_of_match);
> +
> +static const struct spi_device_id cpcap_spi_ids[] = {
> + { "cpcap", CPCAP_DEFAULT },
> + { "mapphone-cpcap", CPCAP_MAPPHONE },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
Please keep the named initializers for cpcap_spi_ids[].
See https://lore.kernel.org/lkml/20260515103150.164887-2-u.kleine-koenig@baylibre.com/
for a rationale.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] dt-bindings: mailbox: Add Apple t8122 ASC mailbox
From: Conor Dooley @ 2026-06-30 17:05 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-1-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: mailbox: apple: Add DockChannel mailbox
From: Conor Dooley @ 2026-06-30 17:07 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-2-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
On Tue, Jun 30, 2026 at 10:54:30PM +1000, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> DockChannel is a FIFO and interrupt block used by Apple coprocessors
> to exchange byte-stream traffic with the AP.
>
> Describe it as a mailbox provider so HID and future serial clients can
> use the common mailbox API.
>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> .../bindings/mailbox/apple,dockchannel.yaml | 75 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
> new file mode 100644
> index 000000000000..4f326d8f3d5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
Please name this file matching the t8112 compatible (since that's your
fallback).
Otherwise, this looks good.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox