diff options
29 files changed, 3022 insertions, 658 deletions
diff --git a/Documentation/hid/hid-transport.txt b/Documentation/hid/hid-transport.txt new file mode 100644 index 000000000000..3dcba9fd4a3a --- /dev/null +++ b/Documentation/hid/hid-transport.txt @@ -0,0 +1,317 @@ + HID I/O Transport Drivers + =========================== + +The HID subsystem is independent of the underlying transport driver. Initially, +only USB was supported, but other specifications adopted the HID design and +provided new transport drivers. The kernel includes at least support for USB, +Bluetooth, I2C and user-space I/O drivers. + +1) HID Bus +========== + +The HID subsystem is designed as a bus. Any I/O subsystem may provide HID +devices and register them with the HID bus. HID core then loads generic device +drivers on top of it. The transport drivers are responsible of raw data +transport and device setup/management. HID core is responsible of +report-parsing, report interpretation and the user-space API. Device specifics +and quirks are handled by all layers depending on the quirk. + + +-----------+ +-----------+ +-----------+ +-----------+ + | Device #1 | | Device #i | | Device #j | | Device #k | + +-----------+ +-----------+ +-----------+ +-----------+ + \\ // \\ // + +------------+ +------------+ + | I/O Driver | | I/O Driver | + +------------+ +------------+ + || || + +------------------+ +------------------+ + | Transport Driver | | Transport Driver | + +------------------+ +------------------+ + \___ ___/ + \ / + +----------------+ + | HID Core | + +----------------+ + / | | \ + / | | \ + ____________/ | | \_________________ + / | | \ + / | | \ + +----------------+ +-----------+ +------------------+ +------------------+ + | Generic Driver | | MT Driver | | Custom Driver #1 | | Custom Driver #2 | + +----------------+ +-----------+ +------------------+ +------------------+ + +Example Drivers: + I/O: USB, I2C, Bluetooth-l2cap + Transport: USB-HID, I2C-HID, BT-HIDP + +Everything below "HID Core" is simplified in this graph as it is only of +interest to HID device drivers. Transport drivers do not need to know the +specifics. + +1.1) Device Setup +----------------- + +I/O drivers normally provide hotplug detection or device enumeration APIs to the +transport drivers. Transport drivers use this to find any suitable HID device. +They allocate HID device objects and register them with HID core. Transport +drivers are not required to register themselves with HID core. HID core is never +aware of which transport drivers are available and is not interested in it. It +is only interested in devices. + +Transport drivers attach a constant "struct hid_ll_driver" object with each +device. Once a device is registered with HID core, the callbacks provided via +this struct are used by HID core to communicate with the device. + +Transport drivers are responsible of detecting device failures and unplugging. +HID core will operate a device as long as it is registered regardless of any +device failures. Once transport drivers detect unplug or failure events, they +must unregister the device from HID core and HID core will stop using the +provided callbacks. + +1.2) Transport Driver Requirements +---------------------------------- + +The terms "asynchronous" and "synchronous" in this document describe the +transmission behavior regarding acknowledgements. An asynchronous channel must +not perform any synchronous operations like waiting for acknowledgements or +verifications. Generally, HID calls operating on asynchronous channels must be +running in atomic-context just fine. +On the other hand, synchronous channels can be implemented by the transport +driver in whatever way they like. They might just be the same as asynchronous +channels, but they can also provide acknowledgement reports, automatic +retransmission on failure, etc. in a blocking manner. If such functionality is +required on asynchronous channels, a transport-driver must implement that via +its own worker threads. + +HID core requires transport drivers to follow a given design. A Transport +driver must provide two bi-directional I/O channels to each HID device. These +channels must not necessarily be bi-directional in the hardware itself. A +transport driver might just provide 4 uni-directional channels. Or it might +multiplex all four on a single physical channel. However, in this document we +will describe them as two bi-directional channels as they have several +properties in common. + + - Interrupt Channel (intr): The intr channel is used for asynchronous data + reports. No management commands or data acknowledgements are sent on this + channel. Any unrequested incoming or outgoing data report must be sent on + this channel and is never acknowledged by the remote side. Devices usually + send their input events on this channel. Outgoing events are normally + not send via intr, except if high throughput is required. + - Control Channel (ctrl): The ctrl channel is used for synchronous requests and + device management. Unrequested data input events must not be sent on this + channel and are normally ignored. Instead, devices only send management + events or answers to host requests on this channel. + The control-channel is used for direct blocking queries to the device + independent of any events on the intr-channel. + Outgoing reports are usually sent on the ctrl channel via synchronous + SET_REPORT requests. + +Communication between devices and HID core is mostly done via HID reports. A +report can be of one of three types: + + - INPUT Report: Input reports provide data from device to host. This + data may include button events, axis events, battery status or more. This + data is generated by the device and sent to the host with or without + requiring explicit requests. Devices can choose to send data continuously or + only on change. + - OUTPUT Report: Output reports change device states. They are sent from host + to device and may include LED requests, rumble requests or more. Output + reports are never sent from device to host, but a host can retrieve their + current state. + Hosts may choose to send output reports either continuously or only on + change. + - FEATURE Report: Feature reports are used for specific static device features + and never reported spontaneously. A host can read and/or write them to access + data like battery-state or device-settings. + Feature reports are never sent without requests. A host must explicitly set + or retrieve a feature report. This also means, feature reports are never sent + on the intr channel as this channel is asynchronous. + +INPUT and OUTPUT reports can be sent as pure data reports on the intr channel. +For INPUT reports this is the usual operational mode. But for OUTPUT reports, +this is rarely done as OUTPUT reports are normally quite scarce. But devices are +free to make excessive use of asynchronous OUTPUT reports (for instance, custom +HID audio speakers make great use of it). + +Plain reports must not be sent on the ctrl channel, though. Instead, the ctrl +channel provides synchronous GET/SET_REPORT requests. Plain reports are only +allowed on the intr channel and are the only means of data there. + + - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent + from host to device. The device must answer with a data report for the + requested report ID on the ctrl channel as a synchronous acknowledgement. + Only one GET_REPORT request can be pending for each device. This restriction + is enforced by HID core as several transport drivers don't allow multiple + simultaneous GET_REPORT requests. + Note that data reports which are sent as answer to a GET_REPORT request are + not handled as generic device events. That is, if a device does not operate + in continuous data reporting mode, an answer to GET_REPORT does not replace + the raw data report on the intr channel on state change. + GET_REPORT is only used by custom HID device drivers to query device state. + Normally, HID core caches any device state so this request is not necessary + on devices that follow the HID specs except during device initialization to + retrieve the current state. + GET_REPORT requests can be sent for any of the 3 report types and shall + return the current report state of the device. However, OUTPUT reports as + payload may be blocked by the underlying transport driver if the + specification does not allow them. + - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is + sent from host to device and a device must update it's current report state + according to the given data. Any of the 3 report types can be used. However, + INPUT reports as payload might be blocked by the underlying transport driver + if the specification does not allow them. + A device must answer with a synchronous acknowledgement. However, HID core + does not require transport drivers to forward this acknowledgement to HID + core. + Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This + restriction is enforced by HID core as some transport drivers do not support + multiple synchronous SET_REPORT requests. + +Other ctrl-channel requests are supported by USB-HID but are not available +(or deprecated) in most other transport level specifications: + + - GET/SET_IDLE: Only used by USB-HID and I2C-HID. + - GET/SET_PROTOCOL: Not used by HID core. + - RESET: Used by I2C-HID, not hooked up in HID core. + - SET_POWER: Used by I2C-HID, not hooked up in HID core. + +2) HID API +========== + +2.1) Initialization +------------------- + +Transport drivers normally use the following procedure to register a new device +with HID core: + + struct hid_device *hid; + int ret; + + hid = hid_allocate_device(); + if (IS_ERR(hid)) { + ret = PTR_ERR(hid); + goto err_<...>; + } + + strlcpy(hid->name, <device-name-src>, 127); + strlcpy(hid->phys, <device-phys-src>, 63); + strlcpy(hid->uniq, <device-uniq-src>, 63); + + hid->ll_driver = &custom_ll_driver; + hid->bus = <device-bus>; + hid->vendor = <device-vendor>; + hid->product = <device-product>; + hid->version = <device-version>; + hid->country = <device-country>; + hid->dev.parent = <pointer-to-parent-device>; + hid->driver_data = <transport-driver-data-field>; + + ret = hid_add_device(hid); + if (ret) + goto err_<...>; + +Once hid_add_device() is entered, HID core might use the callbacks provided in +"custom_ll_driver". Note that fields like "country" can be ignored by underlying +transport-drivers if not supported. + +To unregister a device, use: + + hid_destroy_device(hid); + +Once hid_destroy_device() returns, HID core will no longer make use of any +driver callbacks. + +2.2) hid_ll_driver operations +----------------------------- + +The available HID callbacks are: + - int (*start) (struct hid_device *hdev) + Called from HID device drivers once they want to use the device. Transport + drivers can choose to setup their device in this callback. However, normally + devices are already set up before transport drivers register them to HID core + so this is mostly only used by USB-HID. + + - void (*stop) (struct hid_device *hdev) + Called from HID device drivers once they are done with a device. Transport + drivers can free any buffers and deinitialize the device. But note that + ->start() might be called again if another HID device driver is loaded on the + device. + Transport drivers are free to ignore it and deinitialize devices after they + destroyed them via hid_destroy_device(). + + - int (*open) (struct hid_device *hdev) + Called from HID device drivers once they are interested in data reports. + Usually, while user-space didn't open any input API/etc., device drivers are + not interested in device data and transport drivers can put devices asleep. + However, once ->open() is called, transport drivers must be ready for I/O. + ->open() calls are nested for each client that opens the HID device. + + - void (*close) (struct hid_device *hdev) + Called from HID device drivers after ->open() was called but they are no + longer interested in device reports. (Usually if user-space closed any input + devices of the driver). + Transport drivers can put devices asleep and terminate any I/O of all + ->open() calls have been followed by a ->close() call. However, ->start() may + be called again if the device driver is interested in input reports again. + + - int (*parse) (struct hid_device *hdev) + Called once during device setup after ->start() has been called. Transport + drivers must read the HID report-descriptor from the device and tell HID core + about it via hid_parse_report(). + + - int (*power) (struct hid_device *hdev, int level) + Called by HID core to give PM hints to transport drivers. Usually this is + analogical to the ->open() and ->close() hints and redundant. + + - void (*request) (struct hid_device *hdev, struct hid_report *report, + int reqtype) + Send an HID request on the ctrl channel. "report" contains the report that + should be sent and "reqtype" the request type. Request-type can be + HID_REQ_SET_REPORT or HID_REQ_GET_REPORT. + This callback is optional. If not provided, HID core will assemble a raw + report following the HID specs and send it via the ->raw_request() callback. + The transport driver is free to implement this asynchronously. + + - int (*wait) (struct hid_device *hdev) + Used by HID core before calling ->request() again. A transport driver can use + it to wait for any pending requests to complete if only one request is + allowed at a time. + + - int (*raw_request) (struct hid_device *hdev, unsigned char reportnum, + __u8 *buf, size_t count, unsigned char rtype, + int reqtype) + Same as ->request() but provides the report as raw buffer. This request shall + be synchronous. A transport driver must not use ->wait() to complete such + requests. This request is mandatory and hid core will reject the device if + it is missing. + + - int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len) + Send raw output report via intr channel. Used by some HID device drivers + which require high throughput for outgoing requests on the intr channel. This + must not cause SET_REPORT calls! This must be implemented as asynchronous + output report on the intr channel! + + - int (*idle) (struct hid_device *hdev, int report, int idle, int reqtype) + Perform SET/GET_IDLE request. Only used by USB-HID, do not implement! + +2.3) Data Path +-------------- + +Transport drivers are responsible of reading data from I/O devices. They must +handle any I/O-related state-tracking themselves. HID core does not implement +protocol handshakes or other management commands which can be required by the +given HID transport specification. + +Every raw data packet read from a device must be fed into HID core via +hid_input_report(). You must specify the channel-type (intr or ctrl) and report +type (input/output/feature). Under normal conditions, only input reports are +provided via this API. + +Responses to GET_REPORT requests via ->request() must also be provided via this +API. Responses to ->raw_request() are synchronous and must be intercepted by the +transport driver and not passed to hid_input_report(). +Acknowledgements to SET_REPORT requests are not of interest to HID core. + +---------------------------------------------------- +Written 2013, David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index dc35a2b75eee..ee6593608c8e 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -93,6 +93,11 @@ the request was handled successfully. event to the kernel. The payload is of type struct uhid_create_req and contains information about your device. You can start I/O now. + UHID_CREATE2: + Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array + inside struct uhid_create2_req, instead of a pointer to a separate array. + Enables use from languages that don't support pointers, e.g. Python. + UHID_DESTROY: This destroys the internal HID device. No further I/O will be accepted. There may still be pending messages that you can receive with read() but no further @@ -105,6 +110,12 @@ the request was handled successfully. contains a data-payload. This is the raw data that you read from your device. The kernel will parse the HID reports and react on it. + UHID_INPUT2: + Same as UHID_INPUT, but the data array is the last field of uhid_input2_req. + Enables userspace to write only the required bytes to kernel (ev.type + + ev.u.input2.size + the part of the data array that matters), instead of + the entire struct uhid_input2_req. + UHID_FEATURE_ANSWER: If you receive a UHID_FEATURE request you must answer with this request. You must copy the "id" field from the request into the answer. Set the "err" field diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index f7220011a00b..7af9d0b5dea1 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -175,6 +175,15 @@ config HID_PRODIKEYS multimedia keyboard, but will lack support for the musical keyboard and some additional multimedia keys. +config HID_CP2112 + tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support" + depends on USB_HID && I2C && GPIOLIB + ---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. + config HID_CYPRESS tristate "Cypress mouse and barcode readers" if EXPERT depends on HID @@ -608,25 +617,27 @@ config HID_SAMSUNG Support for Samsung InfraRed remote control or keyboards. config HID_SONY - tristate "Sony PS2/3 accessories" + tristate "Sony PS2/3/4 accessories" depends on USB_HID depends on NEW_LEDS depends on LEDS_CLASS + select POWER_SUPPLY ---help--- Support for * Sony PS3 6-axis controllers + * Sony PS4 DualShock 4 controllers * Buzz controllers * Sony PS3 Blue-ray Disk Remote Control (Bluetooth) * Logitech Harmony adapter for Sony Playstation 3 (Bluetooth) config SONY_FF - bool "Sony PS2/3 accessories force feedback support" + 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 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" diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 30e44318f87f..fc712dde02a4 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_HID_AUREAL) += hid-aureal.o obj-$(CONFIG_HID_BELKIN) += hid-belkin.o obj-$(CONFIG_HID_CHERRY) += hid-cherry.o obj-$(CONFIG_HID_CHICONY) += hid-chicony.o +obj-$(CONFIG_HID_CP2112) += hid-cp2112.o obj-$(CONFIG_HID_CYPRESS) += hid-cypress.o obj-$(CONFIG_HID_DRAGONRISE) += hid-dr.o obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 2448d757b449..9e8064205bc7 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1248,6 +1248,11 @@ void hid_output_report(struct hid_report *report, __u8 *data) } EXPORT_SYMBOL_GPL(hid_output_report); +static int hid_report_len(struct hid_report *report) +{ + return ((report->size - 1) >> 3) + 1 + (report->id > 0) + 7; +} + /* * Allocator for buffer that is going to be passed to hid_output_report() */ @@ -1258,7 +1263,7 @@ u8 *hid_alloc_report_buf(struct hid_report *report, gfp_t flags) * of implement() working on 8 byte chunks */ - int len = ((report->size - 1) >> 3) + 1 + (report->id > 0) + 7; + int len = hid_report_len(report); return kmalloc(len, flags); } @@ -1314,6 +1319,41 @@ static struct hid_report *hid_get_report(struct hid_report_enum *report_enum, return report; } +/* + * Implement a generic .request() callback, using .raw_request() + * DO NOT USE in hid drivers directly, but through hid_hw_request instead. + */ +void __hid_request(struct hid_device *hid, struct hid_report *report, + int reqtype) +{ + char *buf; + int ret; + int len; + + buf = hid_alloc_report_buf(report, GFP_KERNEL); + if (!buf) + return; + + len = hid_report_len(report); + + if (reqtype == HID_REQ_SET_REPORT) + hid_output_report(report, buf); + + ret = hid->ll_driver->raw_request(hid, report->id, buf, len, + report->type, reqtype); + if (ret < 0) { + dbg_hid("unable to complete request: %d\n", ret); + goto out; + } + + if (reqtype == HID_REQ_GET_REPORT) + hid_input_report(hid, report->type, buf, ret, 0); + +out: + kfree(buf); +} +EXPORT_SYMBOL_GPL(__hid_request); + int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size, int interrupt) { @@ -1693,6 +1733,7 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS2) }, { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) }, { HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS, USB_DEVICE_ID_PRODIKEYS_PCMIDI) }, + { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_CP2112) }, { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_1) }, { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2) }, { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_3) }, @@ -1782,6 +1823,7 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2) }, + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) }, { HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) }, { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) }, { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) }, @@ -2434,6 +2476,14 @@ int hid_add_device(struct hid_device *hdev) return -ENODEV; /* + * Check for the mandatory transport channel. + */ + if (!hdev->ll_driver->raw_request) { + hid_err(hdev, "transport driver missing .raw_request()\n"); + return -EINVAL; + } + + /* * Read the device report descriptor once and use as template * for the driver-specific modifications. */ diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c new file mode 100644 index 000000000000..56be85a9a77c --- /dev/null +++ b/drivers/hid/hid-cp2112.c @@ -0,0 +1,1073 @@ +/* + * hid-cp2112.c - Silicon Labs HID USB to SMBus master bridge + * Copyright (c) 2013,2014 Uplogix, Inc. + * David Barksdale <dbarksdale@uplogix.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +/* + * The Silicon Labs CP2112 chip is a USB HID device which provides an + * SMBus controller for talking to slave devices and 8 GPIO pins. The + * host communicates with the CP2112 via raw HID reports. + * + * Data Sheet: + * http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2112.pdf + * Programming Interface Specification: + * http://www.silabs.com/Support%20Documents/TechnicalDocs/AN495.pdf + */ + +#include <linux/gpio.h> +#include <linux/hid.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/nls.h> +#include <linux/usb/ch9.h> +#include "hid-ids.h" + +enum { + CP2112_GPIO_CONFIG = 0x02, + CP2112_GPIO_GET = 0x03, + CP2112_GPIO_SET = 0x04, + CP2112_GET_VERSION_INFO = 0x05, + CP2112_SMBUS_CONFIG = 0x06, + CP2112_DATA_READ_REQUEST = 0x10, + CP2112_DATA_WRITE_READ_REQUEST = 0x11, + CP2112_DATA_READ_FORCE_SEND = 0x12, + CP2112_DATA_READ_RESPONSE = 0x13, + CP2112_DATA_WRITE_REQUEST = 0x14, + CP2112_TRANSFER_STATUS_REQUEST = 0x15, + CP2112_TRANSFER_STATUS_RESPONSE = 0x16, + CP2112_CANCEL_TRANSFER = 0x17, + CP2112_LOCK_BYTE = 0x20, + CP2112_USB_CONFIG = 0x21, + CP2112_MANUFACTURER_STRING = 0x22, + CP2112_PRODUCT_STRING = 0x23, + CP2112_SERIAL_STRING = 0x24, +}; + +enum { + STATUS0_IDLE = 0x00, + STATUS0_BUSY = 0x01, + STATUS0_COMPLETE = 0x02, + STATUS0_ERROR = 0x03, +}; + +enum { + STATUS1_TIMEOUT_NACK = 0x00, + STATUS1_TIMEOUT_BUS = 0x01, + STATUS1_ARBITRATION_LOST = 0x02, + STATUS1_READ_INCOMPLETE = 0x03, + STATUS1_WRITE_INCOMPLETE = 0x04, + STATUS1_SUCCESS = 0x05, +}; + +struct cp2112_smbus_config_report { + u8 report; /* CP2112_SMBUS_CONFIG */ + __be32 clock_speed; /* Hz */ + u8 device_address; /* Stored in the upper 7 bits */ + u8 auto_send_read; /* 1 = enabled, 0 = disabled */ + __be16 write_timeout; /* ms, 0 = no timeout */ + __be16 read_timeout; /* ms, 0 = no timeout */ + u8 scl_low_timeout; /* 1 = enabled, 0 = disabled */ + __be16 retry_time; /* # of retries, 0 = no limit */ +} __packed; + +struct cp2112_usb_config_report { + u8 report; /* CP2112_USB_CONFIG */ + __le16 vid; /* Vendor ID */ + __le16 pid; /* Product ID */ + u8 max_power; /* Power requested in 2mA units */ + u8 power_mode; /* 0x00 = bus powered + 0x01 = self powered & regulator off + 0x02 = self powered & regulator on */ + u8 release_major; + u8 release_minor; + u8 mask; /* What fields to program */ +} __packed; + +struct cp2112_read_req_report { + u8 report; /* CP2112_DATA_READ_REQUEST */ + u8 slave_address; + __be16 length; +} __packed; + +struct cp2112_write_read_req_report { + u8 report; /* CP2112_DATA_WRITE_READ_REQUEST */ + u8 slave_address; + __be16 length; + u8 target_address_length; + u8 target_address[16]; +} __packed; + +struct cp2112_write_req_report { + u8 report; /* CP2112_DATA_WRITE_REQUEST */ + u8 slave_address; + u8 length; + u8 data[61]; +} __packed; + +struct cp2112_force_read_report { + u8 report; /* CP2112_DATA_READ_FORCE_SEND */ + __be16 length; +} __packed; + +struct cp2112_xfer_status_report { + u8 report; /* CP2112_TRANSFER_STATUS_RESPONSE */ + u8 status0; /* STATUS0_* */ + u8 status1; /* STATUS1_* */ + __be16 retries; + __be16 length; +} __packed; + +struct cp2112_string_report { + u8 dummy; /* force .string to be aligned */ + u8 report; /* CP2112_*_STRING */ + u8 length; /* length in bytes of everyting after .report */ + u8 type; /* USB_DT_STRING */ + wchar_t string[30]; /* UTF16_LITTLE_ENDIAN string */ +} __packed; + +/* Number of times to request transfer status before giving up waiting for a + transfer to complete. This may need to be changed if SMBUS clock, retries, + or read/write/scl_low timeout settings are changed. */ +static const int XFER_STATUS_RETRIES = 10; + +/* Time in ms to wait for a CP2112_DATA_READ_RESPONSE or + CP2112_TRANSFER_STATUS_RESPONSE. */ +static const int RESPONSE_TIMEOUT = 50; + +static const struct hid_device_id cp2112_devices[] = { + { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_CP2112) }, + { } +}; +MODULE_DEVICE_TABLE(hid, cp2112_devices); + +struct cp2112_device { + struct i2c_adapter adap; + struct hid_device *hdev; + wait_queue_head_t wait; + u8 read_data[61]; + u8 read_length; + int xfer_status; + atomic_t read_avail; + atomic_t xfer_avail; + struct gpio_chip gc; +}; + +static int gpio_push_pull = 0xFF; +module_param(gpio_push_pull, int, S_IRUGO | S_IWUSR); +MODULE_PARM_DESC(gpio_push_pull, "GPIO push-pull configuration bitmask"); + +static int cp2112_gpio_direction_input(struct gpio_chip *chip, unsigned offset) +{ + struct cp2112_device *dev = container_of(chip, struct cp2112_device, + gc); + struct hid_device *hdev = dev->hdev; + u8 buf[5]; + int ret; + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf, + sizeof(buf), HID_FEATURE_REPORT, + HID_REQ_GET_REPORT); + if (ret != sizeof(buf)) { + hid_err(hdev, "error requesting GPIO config: %d\n", ret); + return ret; + } + + buf[1] &= ~(1 << offset); + buf[2] = gpio_push_pull; + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf, sizeof(buf), + HID_FEATURE_REPORT, HID_REQ_SET_REPORT); + if (ret < 0) { + hid_err(hdev, "error setting GPIO config: %d\n", ret); + return ret; + } + + return 0; +} + +static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int value) +{ + struct cp2112_device *dev = container_of(chip, struct cp2112_device, + gc); + struct hid_device *hdev = dev->hdev; + u8 buf[3]; + int ret; + + buf[0] = CP2112_GPIO_SET; + buf[1] = value ? 0xff : 0; + buf[2] = 1 << offset; + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_SET, buf, sizeof(buf), + HID_FEATURE_REPORT, HID_REQ_SET_REPORT); + if (ret < 0) + hid_err(hdev, "error setting GPIO values: %d\n", ret); +} + +static int cp2112_gpio_get(struct gpio_chip *chip, unsigned offset) +{ + struct cp2112_device *dev = container_of(chip, struct cp2112_device, + gc); + struct hid_device *hdev = dev->hdev; + u8 buf[2]; + int ret; + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_GET, buf, sizeof(buf), + HID_FEATURE_REPORT, HID_REQ_GET_REPORT); + if (ret != sizeof(buf)) { + hid_err(hdev, "error requesting GPIO values: %d\n", ret); + return ret; + } + + return (buf[1] >> offset) & 1; +} + +static int cp2112_gpio_direction_output(struct gpio_chip *chip, + unsigned offset, int value) +{ + struct cp2112_device *dev = container_of(chip, struct cp2112_device, + gc); + struct hid_device *hdev = dev->hdev; + u8 buf[5]; + int ret; + + cp2112_gpio_set(chip, offset, value); + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf, + sizeof(buf), HID_FEATURE_REPORT, + HID_REQ_GET_REPORT); + if (ret != sizeof(buf)) { + hid_err(hdev, "error requesting GPIO config: %d\n", ret); + return ret; + } + + buf[1] |= 1 << offset; + buf[2] = gpio_push_pull; + + ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf, sizeof(buf), + HID_FEATURE_REPORT, HID_REQ_SET_REPORT); + if (ret < 0) { + hid_err(hdev, "error setting GPIO config: %d\n", ret |