This driver adds support for the monitoring logic in the Enermax DigiFanless 550W (EDF550AWN) power supply. It spans the HID and hwmon subsystems, so I decided it needs review from both maintainer teams. (I'm still aiming for it to filter through the hwmon linux-staging repo).
Signed-off-by: Frank Schaefer <[email protected]> --- Documentation/hwmon/zdpms | 107 ++++++ drivers/hid/Kconfig | 16 + drivers/hid/Makefile | 1 + drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + drivers/hid/hid-zdpms.c | 828 ++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 954 insertions(+) create mode 100644 Documentation/hwmon/zdpms create mode 100644 drivers/hid/hid-zdpms.c diff --git a/Documentation/hwmon/zdpms b/Documentation/hwmon/zdpms new file mode 100644 index 0000000..98a4cdc --- /dev/null +++ b/Documentation/hwmon/zdpms @@ -0,0 +1,107 @@ +Kernel driver hid-zdpms +======================= + +Supported chips: + * Enermax DigiFanless 550W PIC (Microchip PIC32MX230F064D) + Prefix: 'zdpms' + Addresses scanned: USB HID space + Datasheet: Still not published + +Authors: + Frank Schaefer <[email protected]> + +Module Parameters +----------------- + +zdpms_timeout=timeout Set the ZDPMS transaction timeout in milliseconds + (default 100 ms). This is clamped to a minimum of 20 + milliseconds, because accuracy is spotty with anything + less. + Example: 'modprobe hid-zdpms zdpms_timeout=500' +zdpms_12v_config=<int> Set the 12V rail configuration (1 for single rail, 2 + for dual rail). By default the rail configuration is + left untouched. + Example: 'modprobe hid-zdpms zdpms_12v_config=2' + +Description +----------- + +The Enermax DigiFanless 550W power supply has an integrated Microchip +32-bit peripheral interface controller (PIC), running a specialized +application to monitor internal power-supply sensors and handle some +incidental user-controllable configuration (mainly the 12V rail +configuration). This controller application communicates with the host +via USB raw Human Interface Device (HID) protocol, using a custom OEM +usage table and failing to disclose the required report descriptors via +standard HID enumeration. This controller is the foundation of the +Enermax Zero-Delay Power Monitoring System (ZDPMS), which is apparently +supported by Enermax only through a proprietary Windows application. + +The Microchip PIC application implements voltage and current sensors for +all internal DC rails (12V1, 12V2, 5V, and 3.3V), an internal temperature +sensor, and an AC input voltage sensor, all of which we are able to query. +There are also supposedly shutdown thresholds for overvoltage protection +and overtemp protection, but as near as i can tell, they are hardcoded and +firmly out of software's reach. + +Sensor values are reported by the PIC in an odd format similar to (but +not quite identical to) IEEE 754 half-precision floating-point. They +seem to have a 5-bit exponent and no sign field, and the leading '1' bit +implicit in IEEE 754 mantissa fields is apparently explicit here. The +exponent also appears to be a fixed value for each sensor, implying that +each sensor has its own fixed range and precision. The apparent lack of +a sign bit implies that all sensor readings are lower-bounded at zero. + +Voltage sensors (also known as IN sensors) report their values in volts; +current sensors (known as CURR sensors) report their values in amperes. +The only known temperature sensor reports its value in degrees Celcius. +Applications such as the Enermax OEM application are supposedly expected +to calculate watts in software using the information supplied in voltage +and amperage sensors (although we currently lack enough sensor readings +to calculate all AC input properties). + +Supposedly, if any sensor reading crosses its hardcoded alarm threshold, +the power supply will shut down, presumably powering down the embedded +Microchip PIC as well (although we have yet to confirm this empirically). +So any software alarms are probably superfluous. + +It is unknown how often the Microchip PIC will measure internal sensor +readings, although the "zero delay" terminology implies that it is near +instantaneous (which seems appropriate for overvoltage protection). +The driver queries the PIC every time userland reads a sensor token via +sysfs but does no internal monitoring of its own. + +Known Issues +------------ + +This driver identifies the Enermax PIC controller application by USB +vendor and product ID. Unfortunately, it is specifically advertising a +Microchip vendor ID rather than an Enermax vendor ID, and the product ID +is an otherwise unknown value. Even worse, it does not advertise any +vendor, product, or serial number string through HID enumeration, so I +have some concerns about how well Enermax has ensured uniqueness of +enumerated IDs. There's also an open question as to whether Enermax has +incorporated similar technology in any of their other power supplies, how +those other products enumerate via HID, and how the driver will respond +upon seeing one of these other devices. + +Also, since pretty much all my knowledge of this hardware is based on +dissecting USB traffic generated by the Enermax OEM application, I'm not +entirely certain of some aspects, such as the sensor-reading format. For +example, I've never seen either of the two high bits of the exponent unset, +or the high bit of the mantissa set--so for all I know, these bits may not +mean what I think they mean. + +Furthermore, although the OEM application is able to determine the apparent +power usage (volt-amperes), the actual power usage (watts), and the power +factor for the AC inputs, I haven't learned how it determines any of those +values. + +Finally, there is a possibility that upon non-fatal "alarm" conditions, +the controller may notify the host via an unexpected HID event. I have no +idea what this will look like, and if there's a host-initiated query or +command in flight, any such unexpected event may interfere with the expected +response. To figure out how to deal with this (or even see what it looks +like without vendor documentation), it may be necessary to construct a +benchtop load setup specifically to trigger such alarm conditions. This is +difficult and somewhat dangerous, for obvious reasons. diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index cc4c664..de01050 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -849,6 +849,22 @@ config HID_XINMO standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here if you have a Xin-Mo Dual Arcade controller. +config HID_ZDPMS + tristate "Enermax ZDPMS support (EXPERIMENTAL)" + depends on HID && HWMON + default n + ---help--- + Support for monitoring sensors and software-configurable settings + embedded in the Enermax DigiFanless 550W power supply. This driver + registers as a hwmon driver to expose these sensors for use by + libsensors-based applications. + + This driver is largely based on dissecting captures of USB traffic + generated by the Enermax ZDPMS OEM Windows application. At least + two sensors are not supported (yet), and it's uncertain how this + driver will behave in the presence of other Enermax products with + similar (but not quite identical) functionality. + config HID_ZEROPLUS tristate "Zeroplus based game controller support" depends on HID diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 2f8a41d..dd538dd 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -92,6 +92,7 @@ obj-$(CONFIG_HID_TOPSEED) += hid-topseed.o obj-$(CONFIG_HID_TWINHAN) += hid-twinhan.o obj-$(CONFIG_HID_UCLOGIC) += hid-uclogic.o obj-$(CONFIG_HID_XINMO) += hid-xinmo.o +obj-$(CONFIG_HID_ZDPMS) += hid-zdpms.o obj-$(CONFIG_HID_ZEROPLUS) += hid-zpff.o obj-$(CONFIG_HID_ZYDACRON) += hid-zydacron.o diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index e6fce23..5d4062b 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1895,6 +1895,7 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACENAVIGATOR) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICOLCD) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICOLCD_BOOTLOADER) }, + { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_ZDPMS) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_MOUSE_4500) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_NE4K) }, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index b3b225b..a9eedea 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -650,6 +650,7 @@ #define USB_DEVICE_ID_PICOLCD 0xc002 #define USB_DEVICE_ID_PICOLCD_BOOTLOADER 0xf002 #define USB_DEVICE_ID_PICK16F1454 0x0042 +#define USB_DEVICE_ID_ZDPMS 0xf590 #define USB_VENDOR_ID_MICROSOFT 0x045e #define USB_DEVICE_ID_SIDEWINDER_GV 0x003b diff --git a/drivers/hid/hid-zdpms.c b/drivers/hid/hid-zdpms.c new file mode 100644 index 0000000..905ef6a --- /dev/null +++ b/drivers/hid/hid-zdpms.c @@ -0,0 +1,828 @@ +/* + * Linux HID/hwmon driver for Enermax ZDPMS controller + * + * Copyright (c) 2015 Frank Schaefer <[email protected]> + * + * The name "Enermax" (and possibly "DigiFanless" and "ZDPMS") are trademark + * Enermax Inc (http://www.enermax.com/). + */ + +/* + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + */ + +#include <linux/init.h> +#include <linux/module.h> +#include <linux/hid.h> +#include <linux/delay.h> +#include <linux/sched.h> +#include <linux/wait.h> +#include <linux/mutex.h> +#include <linux/jiffies.h> +#include <linux/hwmon.h> +#include <linux/hwmon-sysfs.h> +#include <linux/atomic.h> +#include "hid-ids.h" + +#define ZDPMS_VERSION "0.1.1" + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("Enermax ZDPMS controller"); +MODULE_AUTHOR("Frank Schaefer <[email protected]>"); +MODULE_VERSION(ZDPMS_VERSION); + +static const struct hid_device_id zdpms_devices[] = { + { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_ZDPMS) }, + { } +}; +MODULE_DEVICE_TABLE(hid, zdpms_devices); + +static int zdpms_timeout = 100; +module_param(zdpms_timeout, int, S_IRUGO | S_IWUSR); +MODULE_PARM_DESC(zdpms_timeout, + "Transaction timeout in milliseconds (minimum 20)"); + +static int zdpms_12v_config; +module_param(zdpms_12v_config, int, S_IRUGO); +MODULE_PARM_DESC(zdpms_12v_config, + "Set 12V rail configuration (1: single rail, 2: dual rail)"); + +enum { + /* Raw size for HID messages, excluding the URB header */ + ZDPMS_MSG_SIZE = 64, + + /* + * No idea what these mean, but they are part of the initialization + * sequence used by the Enermax ZDPMS OEM application, with the + * single byte value 0x5 passed to each one. I suspect they set + * something, I just don't know what. + */ + ZDPMS_INIT1 = 0x25, + ZDPMS_INIT2 = 0x24, + ZDPMS_INIT3 = 0x23, + + /* + * 12V rail configuration setting. Passing byte value 0x1 sets + * single-rail mode, while passing byte value 0x2 sets dual-rail + * mode. Some PSU models may support more values for more rail + * configurations, but this is what we get on our one sample. + */ + ZDPMS_12V_CONFIG = 0x26, + + /* Sensor values, as near as we can tell. */ + ZDPMS_SENSOR_MIN = 0x27, /* Minimum sensor value */ + ZDPMS_AC_V = 0x27, /* AC input voltage level */ + ZDPMS_DC_12V1 = 0x28, /* + * One of the 12V rail voltage levels + * (probably 12V1) + */ + ZDPMS_DC_5V = 0x29, /* DC 5V rail voltage level */ + ZDPMS_DC_3V = 0x2a, /* DC 3.3V rail voltage level */ + ZDPMS_DC_12V2 = 0x2b, /* + * One of the 21V rail voltage levels. + * (probably 12V1) + */ + ZDPMS_DC_12V1_CURRENT = 0x2c, /* 12V1 current level in amperes */ + ZDPMS_DC_5V_CURRENT = 0x2d, /* 5V current level in amperes */ + ZDPMS_DC_3V_CURRENT = 0x2e, /* 3.3V current level in amperes */ + ZDPMS_DC_12V2_CURRENT = 0x2f, /* 12V2 current level in amperes */ + ZDPMS_TEMP = 0x30, /* PSU temperature in degrees Celcius */ + ZDPMS_SENSOR_MAX = 0x30, /* Maximum sensor value */ + + ZDPMS_MODEL_NUMBER = 0x32, /* + * PSU model number string length + * (variable length) + */ + + /* Message types (a.k.a. HID report IDs) that we've seen. */ + ZDPMS_SET_CONFIG = 0x82, /* Used for setting configuration. */ + ZDPMS_READ_SENSOR = 0x83, /* Used for reading values. */ + ZDPMS_WTF_1 = 0x90, /* No idea at all. Doesn't get a valid + * response. + */ + ZDPMS_WTF_2 = 0x91, /* As above, no idea at all. */ +}; + +static const char * const zdpms_labels[] = { + "AC input voltage", + "DC 12V1", + "DC 5V", + "DC 3.3V", + "DC 12V2", + "DC 12V1 current", + "DC 5V current", + "DC 3.3V current", + "DC 12V2 current", + "PSU temp", +}; + +struct zdpms_device { + /* The hid_device we belong to. */ + struct hid_device *hdev; + + /* The hwmon device pointer. */ + struct device *hwmon_dev; + + /* The wait queue used to track transaction replies. */ + wait_queue_head_t io_wait; + + /* + * The atomic condition variable to indicate that a message is + * received. + */ + atomic_t msg_received; + + /* + * The last data read by the raw event handler. This is expected to be + * a command or query response (up to ZDPMS_MSG_SIZE bytes), and to the + * best of my knowledge, only one pending command or query is supported + * at any time. + */ + uint8_t data[ZDPMS_MSG_SIZE]; + unsigned int sz; + + /* + * The ZDPMS model number (i.e. "EDF550AWN" for the Enermax DigiFanless + * 550W). We don't expect this to be more than 32 bytes. + */ + char model[32]; + + /* + * Transaction lock mutex. This keeps us from launching a second + * command/query while one is still pending. + */ + struct mutex io_lock; + +}; + +/** + * Perform a command/response or query/response exchange with an Enermax + * ZDPMS controller. The command is launched immediately through the + * controller's interrupt endpoint; the response is copied back for the + * caller to perform further analysis. A minimum response timeout + * (maintained in the zdpms_timeout variable) is implicit to avoid + * potential deadlocks. No validation is performed on the response + * content. + * + * Note that commands, queries, and responses are generally zero padded to + * ZDPMS_MSG_SIZE bytes. The first byte of any message must be the report + * ID (typically either ZDPMS_SET_CONFIG or ZDPMS_READ_SENSOR); the second + * byte is supposed to be the length of the message payload, minus the first + * two bytes and any zero padding. For successful commands, the ZDPMS + * controller appears to copy the report ID to the end of the message; for + * unsupported commands, the controller appears to set the length byte to + * 0xFF in the response. + * + * @param hdev + * The hid_device to which we're sending the command/query + * + * @param msg + * The command/query to send to the ZDPMS controller, starting with the + * report ID and message-length byte + * + * @param sz + * The size of the command/query in bytes, including the report ID and + * message-length byte + * + * @param resp + * A user-supplied buffer to store the response. This MUST be at least + * ZDPMS_MSG_SIZE bytes in order to avoid potential buffer overflows. + * + * @return + * Returns the number of bytes read on success (usually ZDPMS_MSG_SIZE), + * or a negative errno value on failure. + */ +static int zdpms_xchg(struct hid_device *hdev, + const uint8_t *data, + unsigned int sz, + uint8_t *resp) +{ + uint8_t msg[ZDPMS_MSG_SIZE]; + struct zdpms_device *dev; + unsigned long last_jiffy; + int ret; + + dev = hid_get_drvdata(hdev); + + /* Copy the message and clear any padding. */ + memcpy(msg, data, sz); + + if (sz < sizeof(msg)) + memset(msg + sz, 0, sizeof(msg) - sz); + + mutex_lock(&(dev->io_lock)); + + /* + * Send the command/query. We use hid_hw_output_report() specifically + * because it will send the raw message to an interrupt endpoint. + * NOTE: No return type (WTF really?). If it fails, we'll supposedly + * find out when we time out waiting for the response... + */ + hid_hw_output_report(hdev, msg, sizeof(msg)); + + /* + * Clamp the timeout to 20ms. Any smaller and it's dicey to represent + * it in jiffies... + */ + if (zdpms_timeout < 20) + zdpms_timeout = 20; + + /* + * We track the last allowable jiffy, in order to avoid our timeout + * getting mistakenly prolonged by a signal storm or similar event. + */ + last_jiffy = jiffies + msecs_to_jiffies(zdpms_timeout); + + do { + ret = wait_event_interruptible_timeout( + dev->io_wait, + atomic_read(&(dev->msg_received)), + last_jiffy - jiffies); + + if (ret == -ERESTARTSYS) + /* Interrupted by a signal. Keep trying... */ + continue; + + if (ret < 0) + /* Unspecified error. Punt! */ + goto fail_mutex_locked; + + if (ret == 0) { + /* Timed out! */ + ret = -ETIMEDOUT; + goto fail_mutex_locked; + } + + if (ret > 0) + /* Message is received. */ + break; + } while (time_before(jiffies, last_jiffy)); + + /* + * Now see about copying the received data to the user-supplied buffer. + */ + memcpy(resp, dev->data, dev->sz); + ret = dev->sz; + atomic_set(&(dev->msg_received), 0); + +fail_mutex_locked: + mutex_unlock(&(dev->io_lock)); + return ret; +} + +/** + * Sets a specific ZDPMS configuration item. Currently-known configuration + * commands only take a one-byte configuration value. Response validation + * is performed. + * + * @param hdev + * Pointer to the hid_device structure to configure + * + * @param cmd + * Device setting to configure + * + * @param val + * Configuration setting to apply + * + * @return + * Returns the size of the return message on success, or a negative + * errno value on failure + */ +static int zdpms_set(struct hid_device *hdev, uint8_t cmd, uint8_t val) +{ + uint8_t msg[8], resp[ZDPMS_MSG_SIZE]; + int result; + + msg[0] = ZDPMS_SET_CONFIG; + msg[1] = 0x03; /* 3-byte message */ + msg[2] = 0x40; /* no idea what this is supposed to mean */ + msg[3] = cmd; /* Command value */ + msg[4] = val; + + result = zdpms_xchg(hdev, msg, 5, resp); + + if (result < 0) + return result; + + if (result < 6) + return -EMSGSIZE; + + if (resp[1] == 0xff) + /* Unsupported command? */ + return -EINVAL; + + if (resp[0] != msg[0] || resp[1] != 4 || resp[2] != msg[2] || + resp[3] != msg[3] || resp[4] != msg[4] || resp[5] != resp[0]) + return -EPROTO; + + return result; +} + +/** + * Reads the ASCII model number string from the ZDPMS controller and stores it + * in the caller-supplied buffer and appends a NULL terminator if possible. If + * the buffer is not large enough to hold the entire string, it will be + * truncated to fit (but no NULL terminator will be added). + * + * @param hdev + * The hid_device we're attempting to query + * + * @param buf + * The caller-supplied buffer to store the model number string + * + * @param sz + * The maximum buffer size (in bytes) + * + * @return + * Returns the length of the model-number string in bytes (not counting + * the NULL terminator), or a negative errno value on failure. The + * returned string length may be larger than the supplied buffer size. + * + */ +static int zdpms_read_model(struct hid_device *hdev, char *buf, size_t sz) +{ + uint8_t msg[8], resp[ZDPMS_MSG_SIZE]; + int result; + + msg[0] = ZDPMS_READ_SENSOR; + msg[1] = 0x2; /* 2-byte message */ + msg[2] = 0x40; /* nope, still no idea what this is for. */ + msg[3] = ZDPMS_MODEL_NUMBER; + result = zdpms_xchg(hdev, msg, 4, resp); + + if (result < 0) + return result; + + if (result < 6) + return -EMSGSIZE; + + if (resp[1] == 0xff) + return -EINVAL; + + if (resp[1] + 2 > ZDPMS_MSG_SIZE || resp[0] != msg[0] || + resp[2] != msg[2] || resp[3] != msg[3] || + resp[resp[1]+1] != resp[0]) + return -EPROTO; + + result = resp[1] - 3; + + if (result < sz) { + /* + * Good news, we can fit the entire model name in the supplied + * buffer, complete with a NULL terminator. + */ + memcpy(buf, resp + 4, result); + buf[result] = '\0'; + } else + /* Whoops, we can only fit in part of it. */ + memcpy(buf, resp + 4, sz); + + return result; +} + +/** + * Query a sensor reading from a ZDPMS controller. This reading is reported + * in millivolts, milliamperes, or millidegrees Celcius, in order to conform + * with the Linux hwmon subsystem expectations. + * + * @param hdev + * The hid_device we're attempting to query + * + * @param sensor + * The sensor index we're attempting to query + * + * @return + * Returns the sensor value (currently always >=0) on success, or a + * negative errno value on failure. + * + */ +static int zdpms_read_sensor(struct hid_device *hdev, uint8_t sensor) +{ + uint8_t msg[8], resp[ZDPMS_MSG_SIZE]; + int result; + uint32_t val; + unsigned int exponent; + + msg[0] = ZDPMS_READ_SENSOR; + msg[1] = 0x2; /* 2-byte message */ + msg[2] = 0x40; /* no idea what this is supposed to mean */ + msg[3] = sensor; /* Sensor value */ + result = zdpms_xchg(hdev, msg, 4, resp); + + if (result < 4) + return result; + + if (result < 7) + return -EMSGSIZE; + + if (resp[1] == 0xff) + /* Nonexistent sensor? */ + return -ENODEV; + + if (resp[0] != msg[0] || resp[1] != 5 || resp[2] != msg[2] || + resp[3] != msg[3] || resp[6] != resp[0]) + return -EPROTO; + + /* + * The sensor value is encoded as little-endian quasi-IEEE 754, in + * bytes 4 and 5. + */ + val = ((resp[5] & 7) << 8) | resp[4]; + exponent = resp[5] >> 3; + + /* + * All hwmon sensors we support are supposed to be reported in + * milliunits (millivolts, millidegrees Celcius, or milliamperes). + * Given that the maximum possible value for the mantissa is 2^11 + * (2048), we'll remain well within 32-bit integer range even after + * applying this multiplier. + */ + val *= 1000; + + /* + * Apply the exponent shift *after* applying the units multiplier, so we + * preserve as much accuracy as possible. + */ + val >>= (32 - exponent); + return val; +} + +/** + * Callback for reporting ZDPMS sensor labels via sysfs, in accordance with + * standard hwmon conventions. + * + * @param dev + * hwmon device pointer. The corresponding zdpms_device structure is + * referenced by the dev_get_drvdata() result and contains a pointer to + * the associated hid_device structure of the ZDPMS controller. + * + * @param attr + * sysfs device attribute pointer. The corresponding sensor device + * attribute can be deduced from this and supplies the desired ZDPMS + * sensor ID. + * + * @param buf + * buffer for storing a string representation of the sensor reading. + * + * @return + * Returns the size of the string representation stored in the buffer, + * not including the NULL terminator, or a negative errno value on + * failure. + * + */ +static ssize_t zdpms_show_label(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct sensor_device_attribute *sens_attr; + struct zdpms_device *zdev; + struct hid_device *hdev; + unsigned int idx; + + sens_attr = to_sensor_dev_attr(attr); + zdev = dev_get_drvdata(dev); + hdev = zdev->hdev; + idx = sens_attr->index; + + /* We use a straight sequential array as a lookup table. */ + idx -= ZDPMS_SENSOR_MIN; + + return sprintf(buf, "%s\n", zdpms_labels[idx]); +} + +/** + * Callback for reporting ZDPMS sensor values via sysfs, in accordance with + * standard hwmon conventions. + * + * @param dev + * hwmon device pointer. The corresponding zdpms_device structure is + * referenced by the dev_get_drvdata() result and contains a pointer to + * the associated hid_device structure of the ZDPMS controller. + * + * @param attr + * sysfs device attribute pointer. The corresponding sensor device + * attribute can be deduced from this and supplies the desired ZDPMS + * sensor ID. + * + * @param buf + * buffer for storing a string representation of the sensor reading. + * + * @return + * Returns the size of the string representation stored in the buffer, + * not including the NULL terminator, or a negative errno value on + * failure. + * + */ +static ssize_t zdpms_show_sensor(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct sensor_device_attribute *sens_attr; + struct zdpms_device *zdev; + struct hid_device *hdev; + unsigned int idx; + int val; + + sens_attr = to_sensor_dev_attr(attr); + zdev = dev_get_drvdata(dev); + hdev = zdev->hdev; + idx = sens_attr->index; + val = zdpms_read_sensor(hdev, idx); + + if (val < 0) + return val; + + return sprintf(buf, "%d\n", val); +} + +/** + * Callback for reporting raw HID events from a ZDPMS controller. ZDPMS + * controllers generally only send HID events in response to commands or + * queries sent to their interrupt endpoints; generally only one such + * command or query is expected to be pending at any time. + * + * @param hdev + * Pointer to the HID device (ZDPMS controller) responsible for this + * HID event + * + * @param report + * Pointer to the HID report structure for this event. This is + * generally ignored, since we prefer to parse raw messages. + * + * @param data + * Pointer to the HID data payload from this event (not including any + * headers such as the USB Request Block (URB) + * + * @param sz + * Size of the HID data payload from this event (usually ZDPMS_MSG_SIZE + * bytes). + * + * @return + * In accordance with the kernel HID API, returns 0 when the event has + * been successfully parsed, or -1 if a parse error occurs. + * + */ +static int zdpms_raw_event(struct hid_device *hdev, + struct hid_report *report, + u8 *data, + int sz) +{ + struct zdpms_device *dev; + + dev = hid_get_drvdata(hdev); + + /* + * We shouldn't receive any messages larger than ZDPMS_MSG_SIZE bytes. + * If we do, we need to clip it so it fits in our buffer. + */ + if (sz > ZDPMS_MSG_SIZE) { + hid_warn(hdev, + "truncated oversize %d-byte event message!\n", + sz); + + sz = ZDPMS_MSG_SIZE; + } + + memcpy(dev->data, data, sz); + dev->sz = sz; + + if (atomic_inc_return(&(dev->msg_received)) > 1) + /* + * This implies we already had a message pending, and we just + * overwrote it. D'oh! + */ + hid_warn(hdev, "overwriting unacknowledged message\n"); + + /* Now wake up anyone waiting on a transaction to complete. */ + wake_up_interruptible(&(dev->io_wait)); + return 0; +} + +static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_12V1); +static SENSOR_DEVICE_ATTR(in1_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_12V1); +static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_5V); +static SENSOR_DEVICE_ATTR(in2_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_5V); +static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_3V); +static SENSOR_DEVICE_ATTR(in3_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_3V); +static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_12V2); +static SENSOR_DEVICE_ATTR(in4_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_12V2); +static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_AC_V); +static SENSOR_DEVICE_ATTR(in5_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_AC_V); +static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_12V1_CURRENT); +static SENSOR_DEVICE_ATTR(curr1_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_12V1_CURRENT); +static SENSOR_DEVICE_ATTR(curr2_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_5V_CURRENT); +static SENSOR_DEVICE_ATTR(curr2_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_5V_CURRENT); +static SENSOR_DEVICE_ATTR(curr3_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_3V_CURRENT); +static SENSOR_DEVICE_ATTR(curr3_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_3V_CURRENT); +static SENSOR_DEVICE_ATTR(curr4_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_DC_12V2_CURRENT); +static SENSOR_DEVICE_ATTR(curr4_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_DC_12V2_CURRENT); +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, zdpms_show_sensor, NULL, + ZDPMS_TEMP); +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, zdpms_show_label, NULL, + ZDPMS_TEMP); + +static struct attribute *zdpms_attrs[] = { + &sensor_dev_attr_in1_label.dev_attr.attr, + &sensor_dev_attr_in1_input.dev_attr.attr, + &sensor_dev_attr_in2_label.dev_attr.attr, + &sensor_dev_attr_in2_input.dev_attr.attr, + &sensor_dev_attr_in3_label.dev_attr.attr, + &sensor_dev_attr_in3_input.dev_attr.attr, + &sensor_dev_attr_in4_label.dev_attr.attr, + &sensor_dev_attr_in4_input.dev_attr.attr, + &sensor_dev_attr_in5_label.dev_attr.attr, + &sensor_dev_attr_in5_input.dev_attr.attr, + &sensor_dev_attr_curr1_label.dev_attr.attr, + &sensor_dev_attr_curr1_input.dev_attr.attr, + &sensor_dev_attr_curr2_label.dev_attr.attr, + &sensor_dev_attr_curr2_input.dev_attr.attr, + &sensor_dev_attr_curr3_label.dev_attr.attr, + &sensor_dev_attr_curr3_input.dev_attr.attr, + &sensor_dev_attr_curr4_label.dev_attr.attr, + &sensor_dev_attr_curr4_input.dev_attr.attr, + &sensor_dev_attr_temp1_label.dev_attr.attr, + &sensor_dev_attr_temp1_input.dev_attr.attr, + NULL, +}; + +ATTRIBUTE_GROUPS(zdpms); + +static int zdpms_probe(struct hid_device *hdev, const struct hid_device_id *id) +{ + struct zdpms_device *dev; + int ret; + + ret = hid_parse(hdev); + + if (ret < 0) { + hid_err(hdev, "parse failed\n"); + return ret; + } + + ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW); + + if (ret < 0) { + hid_err(hdev, "hw start failed\n"); + return ret; + } + + ret = hid_hw_open(hdev); + + if (ret < 0) { + hid_err(hdev, "hw open failed\n"); + goto fail_hid_started; + } + + ret = hid_hw_power(hdev, PM_HINT_FULLON); + + if (ret < 0) { + hid_err(hdev, "power management error: %d\n", ret); + goto fail_hid_open; + } + + dev = devm_kzalloc(&(hdev->dev), + sizeof(struct zdpms_device), + GFP_KERNEL); + + if (dev == NULL) { + ret = -ENOMEM; + goto fail_hid_power_on; + } + + /* Initialize the private device data structure. */ + dev->hdev = hdev; + init_waitqueue_head(&(dev->io_wait)); + atomic_set(&(dev->msg_received), 0); + mutex_init(&(dev->io_lock)); + hid_set_drvdata(hdev, dev); + + /* Allow event processing during probe. */ + hid_device_io_start(hdev); + + /* Perform the initialization sequence */ + ret = zdpms_set(hdev, ZDPMS_INIT1, 0x5); + + if (ret >= 0) { + ret = zdpms_set(hdev, ZDPMS_INIT2, 0x5); + + if (ret >= 0) + ret = zdpms_set(hdev, ZDPMS_INIT3, 0x5); + } + + if (ret < 0) { + hid_err(hdev, + "Primary initialization sequence FAILED (error %d)\n", + ret); + + goto fail_io_started; + } + + if (zdpms_12v_config > 0 && zdpms_12v_config < 3) { + hid_info(hdev, "Setting 12V %s-rail configuration...", + zdpms_12v_config == 1 ? "single" : "dual"); + + ret = zdpms_set(hdev, ZDPMS_12V_CONFIG, zdpms_12v_config); + + if (ret < 0) { + hid_err(hdev, + "12V rail configuration FAILED (error %d)\n", + ret); + + goto fail_io_started; + } + } + + ret = zdpms_read_model(hdev, dev->model, sizeof(dev->model)); + + if (ret < 0) { + hid_err(hdev, "Model number query FAILED (error %d)\n", ret); + goto fail_io_started; + } + + if (ret >= sizeof(dev->model)) { + hid_warn(hdev, + "model number truncated to %ld bytes (full size %d bytes)\n", + sizeof(dev->model) - 1, ret); + + dev->model[sizeof(dev->model) - 1] = '\0'; + } else + dev->model[ret] = '\0'; + + hid_info(hdev, "Detected model number: %s\n", dev->model); + + /* Undo hid_device_io_start(). */ + hid_device_io_stop(hdev); + + /* Now register this as an hwmon device. */ + dev->hwmon_dev = devm_hwmon_device_register_with_groups(&(hdev->dev), + "zdpms", + dev, + zdpms_groups); + + ret = PTR_ERR_OR_ZERO(dev->hwmon_dev); + + if (ret < 0) { + hid_err(hdev, "hwmon device registration FAILED (error %d)\n", + ret); + + goto fail_data_alloced; + } + + return 0; + +fail_io_started: + hid_device_io_stop(hdev); +fail_data_alloced: + hid_set_drvdata(hdev, NULL); + devm_kfree(&(hdev->dev), dev); +fail_hid_power_on: + hid_hw_power(hdev, PM_HINT_NORMAL); +fail_hid_open: + hid_hw_close(hdev); +fail_hid_started: + hid_hw_stop(hdev); + return ret; +} + +static void zdpms_remove(struct hid_device *hdev) +{ + struct zdpms_device *dev; + + dev = hid_get_drvdata(hdev); + mutex_destroy(&(dev->io_lock)); + hid_hw_power(hdev, PM_HINT_NORMAL); + hid_hw_close(hdev); + hid_hw_stop(hdev); +} + +static struct hid_driver zdpms_driver = { + .name = "zdpms", + .id_table = zdpms_devices, + .probe = zdpms_probe, + .remove = zdpms_remove, + .raw_event = zdpms_raw_event, +}; + +module_hid_driver(zdpms_driver); + -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
