* [PATCH v8 0/9] Drivers to support the MCU on QNAP NAS devices
From: Heiko Stuebner @ 2024-09-08 21:07 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
This implements a set of drivers for the MCU used on QNAP NAS devices.
Of course no documentation for the serial protocol is available, so
thankfully QNAP has a tool on their rescue-inird to talk to the MCU and
I found interceptty [0] to listen to what goes over the serial connection.
In general it looks like there are two different generations in general,
an "EC" device and now this "MCU" - referenced in the strings of the
userspace handlers for those devices.
For the MCU "SPEC3" and "SPEC4" are listed which is configured in
the model.conf of the device. When setting the value from SPEC4 to
SPEC3 on my TS433, the supported commands change, but the command
interface stays the same and especially the version command is the
same.
The binding also does not expose any interals of the device that
might change, so hopefully there shouldn't be big roadblocks to
support different devices, apart from possibly adapting the commands.
changes in v8:
- patch for hid-sensor hub to not do wonky stuff with an old
platform-data copy
I hope my reading of the situation is correct here, but that
initial platform_data really seemed wrong
mfd:
- flush serial before writing a new command
- wait for send to complete before starting the receive wait-timeout
- set expected length to 0 directly when the reply is complete
not after leaving the receive callback
changes in v7:
- use ASCII representation in commands where possible instead of hex vals
- drop get_variant function and use mfd platform-data instead
mfd:
- a lot of style improvements
leds:
- name variables better (value -> brightness, num -> num_err_led)
- handle preservation of blink mode more effectively
- snprintf -> scnprintf
- drop duplicate "failed to register ... LED" messages
changes in v6:
- format mcu commands arrays in single lines (Lee)
mfd:
- drop obsolete remain kdoc for the removed
reply_lock (kernel test robot)
changes in v5:
binding:
- add Conor's Reviewed-by
mfd:
Address comments from Lee
- improve commit message
- improve Kconfig help text
- sort headers alphabetical
- style and spelling improvements
- constants for magic numbers
- drop reply assignment, the mcu only replies to commands sent to it,
so there should only ever be one command in fligth.
hwmon:
Add Acked-by from Guenter and address some remarks
- don't allow empty fan subnode
- use num var directly when getting cooling levels, without using ret
intermediate
- use dev_err_probe in thermal init function
changes in v4:
binding:
- move cooling properties into a fan subnode and reference
fan-common.yaml (Rob)
- dropped Krzysztof's Ack because of this
mfd:
- use correct format-string for size_t (kernel test robot)
input:
- added Dmitry's Ack
hwmon:
- adapted to fan-subnode when reading cooling properties
- dropped Guenter's Ack because of this
changes in v3:
mfd
- use correct power-off priority: default
- constify the cmd-data array in command functions (Dmitry)
leds:
- don't point to temporary buffers for cdev->name (Florian Eckert)
hwmon:
- use clamp_val(), don't try to reimplement (Guenter)
- add Guenter's Ack
input:
address Dmitry's comments
- constify some cmd arrays
- add input-close callback to cancel beep worker
- drop initial input event report
changes in v2:
binding:
- rename to qnap,ts433-mcu.yaml (Krzysztof)
- drop "preserve formatting" indicator (Krzysztof)
- add Krzysztof's Review tag
mfd:
- fix checkpatch --strict CHECKs
- add a MAINTAINERS entry for all qnap-mcu-parts
Heiko Stuebner (9):
HID: hid-sensor-hub: don't use stale platform-data on remove
mfd: core: make platform_data pointer const in struct mfd_cell
dt-bindings: mfd: add binding for qnap,ts433-mcu devices
mfd: add base driver for qnap-mcu devices
leds: add driver for LEDs from qnap-mcu devices
Input: add driver for the input part of qnap-mcu devices
hwmon: add driver for the hwmon parts of qnap-mcu devices
arm64: dts: rockchip: hook up the MCU on the QNAP TS433
arm64: dts: rockchip: set hdd led labels on qnap-ts433
.../bindings/mfd/qnap,ts433-mcu.yaml | 42 ++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/qnap-mcu-hwmon.rst | 27 ++
MAINTAINERS | 9 +
.../boot/dts/rockchip/rk3568-qnap-ts433.dts | 61 +++
drivers/hid/hid-sensor-hub.c | 21 +-
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/qnap-mcu-hwmon.c | 364 ++++++++++++++++++
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qnap-mcu-input.c | 153 ++++++++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-qnap-mcu.c | 227 +++++++++++
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 2 +
drivers/mfd/qnap-mcu.c | 332 ++++++++++++++++
include/linux/mfd/core.h | 2 +-
include/linux/mfd/qnap-mcu.h | 26 ++
20 files changed, 1310 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
create mode 100644 Documentation/hwmon/qnap-mcu-hwmon.rst
create mode 100644 drivers/hwmon/qnap-mcu-hwmon.c
create mode 100644 drivers/input/misc/qnap-mcu-input.c
create mode 100644 drivers/leds/leds-qnap-mcu.c
create mode 100644 drivers/mfd/qnap-mcu.c
create mode 100644 include/linux/mfd/qnap-mcu.h
--
2.43.0
^ permalink raw reply
* [PATCH v8 9/9] arm64: dts: rockchip: set hdd led labels on qnap-ts433
From: Heiko Stuebner @ 2024-09-08 21:08 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
The automatically generated names for the LEDs from color and function
do not match nicely for the 4 hdds, so set them manually per the label
property to also match the LEDs generated from the MCU.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
index 4bc5f5691d45..7bd32d230ad2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
@@ -50,6 +50,7 @@ led-0 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_LOW>;
+ label = "hdd1:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd1_led_pin>;
@@ -59,6 +60,7 @@ led-1 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
+ label = "hdd2:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd2_led_pin>;
@@ -68,6 +70,7 @@ led-2 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD7 GPIO_ACTIVE_LOW>;
+ label = "hdd3:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd3_led_pin>;
@@ -77,6 +80,7 @@ led-3 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio2 RK_PA0 GPIO_ACTIVE_LOW>;
+ label = "hdd4:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd4_led_pin>;
--
2.43.0
^ permalink raw reply related
* [PATCH v8 8/9] arm64: dts: rockchip: hook up the MCU on the QNAP TS433
From: Heiko Stuebner @ 2024-09-08 21:08 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
The MCU is an important part of the device functionality. It provides
functionality like fan-control, more leds, etc and even more important
without it, the NAS-device cannot even fully turned off.
Hook up the serial device to its uart and hook into the thermal
management to control the fan according to the cpu temperature.
While the MCU also provides a temperature sensor for the case, this one
is just polled and does not provide functionality for handling trip
points in hardware, so a lot of polling would be involved.
As the cpu is only cooled passively in these devices, it's temperature
rising will indicate the temperature level of the system just earlier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../boot/dts/rockchip/rk3568-qnap-ts433.dts | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
index e601d9271ba8..4bc5f5691d45 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
@@ -483,6 +483,54 @@ rgmii_phy0: ethernet-phy@0 {
};
};
+/*
+ * The MCU can provide system temperature too, but only by polling and of
+ * course also cannot set trip points. So attach to the cpu thermal-zone
+ * instead to control the fan.
+ */
+&cpu_thermal {
+ trips {
+ case_fan0: case-fan0 {
+ hysteresis = <2000>;
+ temperature = <35000>;
+ type = "active";
+ };
+
+ case_fan1: case-fan1 {
+ hysteresis = <2000>;
+ temperature = <45000>;
+ type = "active";
+ };
+
+ case_fan2: case-fan2 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ /*
+ * Always provide some air movement, due to small case
+ * full of harddrives.
+ */
+ map1 {
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ trip = <&case_fan0>;
+ };
+
+ map2 {
+ cooling-device = <&fan 2 3>;
+ trip = <&case_fan1>;
+ };
+
+ map3 {
+ cooling-device = <&fan 4 THERMAL_NO_LIMIT>;
+ trip = <&case_fan2>;
+ };
+ };
+};
+
&pcie30phy {
data-lanes = <1 2>;
status = "okay";
@@ -582,6 +630,15 @@ &tsadc {
*/
&uart0 {
status = "okay";
+
+ mcu {
+ compatible = "qnap,ts433-mcu";
+
+ fan: fan-0 {
+ #cooling-cells = <2>;
+ cooling-levels = <0 64 89 128 166 204 221 238>;
+ };
+ };
};
/*
--
2.43.0
^ permalink raw reply related
* [PATCH v8 7/9] hwmon: add driver for the hwmon parts of qnap-mcu devices
From: Heiko Stuebner @ 2024-09-08 21:08 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
The MCU can be found on network-attached-storage devices made by QNAP
and provides access to fan control including reading back its RPM as
well as reading the temperature of the NAS case.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/qnap-mcu-hwmon.rst | 27 ++
MAINTAINERS | 1 +
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/qnap-mcu-hwmon.c | 364 +++++++++++++++++++++++++
6 files changed, 406 insertions(+)
create mode 100644 Documentation/hwmon/qnap-mcu-hwmon.rst
create mode 100644 drivers/hwmon/qnap-mcu-hwmon.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 913c11390a45..7adbe23f0659 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -199,6 +199,7 @@ Hardware Monitoring Kernel Drivers
pxe1610
pwm-fan
q54sj108a2
+ qnap-mcu-hwmon
raspberrypi-hwmon
sbrmi
sbtsi_temp
diff --git a/Documentation/hwmon/qnap-mcu-hwmon.rst b/Documentation/hwmon/qnap-mcu-hwmon.rst
new file mode 100644
index 000000000000..83407e3408f2
--- /dev/null
+++ b/Documentation/hwmon/qnap-mcu-hwmon.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver qnap-mcu-hwmon
+============================
+
+This driver enables the use of the hardware monitoring and fan control
+of the MCU used on some QNAP network attached storage devices.
+
+Author: Heiko Stuebner <heiko@sntech.de>
+
+Description
+-----------
+
+The driver implements a simple interface for driving the fan controlled by
+setting its PWM output value and exposes the fan rpm and case-temperature
+to user space through hwmon's sysfs interface.
+
+The fan rotation speed returned via the optional 'fan1_input' is calculated
+inside the MCU device.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= =======================================================
+fan1_input ro fan tachometer speed in RPM
+pwm1 rw relative speed (0-255), 255=max. speed.
+temp1_input ro Measured temperature in millicelsius
+=============== ======= =======================================================
diff --git a/MAINTAINERS b/MAINTAINERS
index cc5ef91d019e..8c35c994d0b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/hwmon/qnap-mcu-hwmon.c
F: drivers/input/misc/qnap-mcu-input.c
F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b60fe2e58ad6..0118ad91057e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1793,6 +1793,18 @@ config SENSORS_PWM_FAN
This driver can also be built as a module. If so, the module
will be called pwm-fan.
+config SENSORS_QNAP_MCU_HWMON
+ tristate "QNAP MCU hardware monitoring"
+ depends on MFD_QNAP_MCU
+ depends on THERMAL || THERMAL=n
+ help
+ Say yes here to enable support for fan and temperature sensor
+ connected to a QNAP MCU, as found in a number of QNAP network
+ attached storage devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called qnap-mcu-hwmon.
+
config SENSORS_RASPBERRYPI_HWMON
tristate "Raspberry Pi voltage monitor"
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index b1c7056c37db..d60f46a03cc9 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
+obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON) += qnap-mcu-hwmon.o
obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
obj-$(CONFIG_SENSORS_SBRMI) += sbrmi.o
diff --git a/drivers/hwmon/qnap-mcu-hwmon.c b/drivers/hwmon/qnap-mcu-hwmon.c
new file mode 100644
index 000000000000..29057514739c
--- /dev/null
+++ b/drivers/hwmon/qnap-mcu-hwmon.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Driver for hwmon elements found on QNAP-MCU devices
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/fwnode.h>
+#include <linux/hwmon.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/thermal.h>
+
+struct qnap_mcu_hwmon {
+ struct qnap_mcu *mcu;
+ struct device *dev;
+
+ unsigned int pwm_min;
+ unsigned int pwm_max;
+
+ struct fwnode_handle *fan_node;
+ unsigned int fan_state;
+ unsigned int fan_max_state;
+ unsigned int *fan_cooling_levels;
+
+ struct thermal_cooling_device *cdev;
+ struct hwmon_chip_info info;
+};
+
+static int qnap_mcu_hwmon_get_rpm(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'F', 'A' };
+ u8 reply[6];
+ int ret;
+
+ /* poll the fan rpm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First 2 bytes must mirror the sent command */
+ if (memcmp(cmd, reply, 2))
+ return -EIO;
+
+ return reply[4] * 30;
+}
+
+static int qnap_mcu_hwmon_get_pwm(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'F', 'Z', '0' }; /* 0 = fan-id? */
+ u8 reply[4];
+ int ret;
+
+ /* poll the fan pwm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First 3 bytes must mirror the sent command */
+ if (memcmp(cmd, reply, 3))
+ return -EIO;
+
+ return reply[3];
+}
+
+static int qnap_mcu_hwmon_set_pwm(struct qnap_mcu_hwmon *hwm, u8 pwm)
+{
+ const u8 cmd[] = { '@', 'F', 'W', '0', pwm }; /* 0 = fan-id?, pwm 0-255 */
+
+ /* set the fan pwm */
+ return qnap_mcu_exec_with_ack(hwm->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_hwmon_get_temp(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'T', '3' };
+ u8 reply[4];
+ int ret;
+
+ /* poll the fan rpm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First bytes must mirror the sent command */
+ if (memcmp(cmd, reply, sizeof(cmd)))
+ return -EIO;
+
+ /*
+ * There is an unknown bit set in bit7.
+ * Bits [6:0] report the actual temperature as returned by the
+ * original qnap firmware-tools, so just drop bit7 for now.
+ */
+ return (reply[3] & 0x7f) * 1000;
+}
+
+static int qnap_mcu_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long val)
+{
+ struct qnap_mcu_hwmon *hwm = dev_get_drvdata(dev);
+
+ switch (attr) {
+ case hwmon_pwm_input:
+ if (val < 0 || val > 255)
+ return -EINVAL;
+
+ if (val != 0)
+ val = clamp_val(val, hwm->pwm_min, hwm->pwm_max);
+
+ return qnap_mcu_hwmon_set_pwm(hwm, val);
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct qnap_mcu_hwmon *hwm = dev_get_drvdata(dev);
+ int ret;
+
+ switch (type) {
+ case hwmon_pwm:
+ switch (attr) {
+ case hwmon_pwm_input:
+ ret = qnap_mcu_hwmon_get_pwm(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_fan:
+ ret = qnap_mcu_hwmon_get_rpm(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ case hwmon_temp:
+ ret = qnap_mcu_hwmon_get_temp(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static umode_t qnap_mcu_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ case hwmon_temp:
+ return 0444;
+
+ case hwmon_pwm:
+ return 0644;
+
+ case hwmon_fan:
+ return 0444;
+
+ default:
+ return 0;
+ }
+}
+
+static const struct hwmon_ops qnap_mcu_hwmon_hwmon_ops = {
+ .is_visible = qnap_mcu_hwmon_is_visible,
+ .read = qnap_mcu_hwmon_read,
+ .write = qnap_mcu_hwmon_write,
+};
+
+/* thermal cooling device callbacks */
+static int qnap_mcu_hwmon_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+
+ if (!hwm)
+ return -EINVAL;
+
+ *state = hwm->fan_max_state;
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+
+ if (!hwm)
+ return -EINVAL;
+
+ *state = hwm->fan_state;
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+ int ret;
+
+ if (!hwm || state > hwm->fan_max_state)
+ return -EINVAL;
+
+ if (state == hwm->fan_state)
+ return 0;
+
+ ret = qnap_mcu_hwmon_set_pwm(hwm, hwm->fan_cooling_levels[state]);
+ if (ret)
+ return ret;
+
+ hwm->fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops qnap_mcu_hwmon_cooling_ops = {
+ .get_max_state = qnap_mcu_hwmon_get_max_state,
+ .get_cur_state = qnap_mcu_hwmon_get_cur_state,
+ .set_cur_state = qnap_mcu_hwmon_set_cur_state,
+};
+
+static void devm_fan_node_release(void *data)
+{
+ struct qnap_mcu_hwmon *hwm = data;
+
+ fwnode_handle_put(hwm->fan_node);
+}
+
+static int qnap_mcu_hwmon_get_cooling_data(struct device *dev, struct qnap_mcu_hwmon *hwm)
+{
+ struct fwnode_handle *fwnode;
+ int num, i, ret;
+
+ fwnode = device_get_named_child_node(dev->parent, "fan-0");
+ if (!fwnode)
+ return 0;
+
+ /* if we found the fan-node, we're keeping it until device-unbind */
+ hwm->fan_node = fwnode;
+ ret = devm_add_action_or_reset(dev, devm_fan_node_release, hwm);
+ if (ret)
+ return ret;
+
+ num = fwnode_property_count_u32(fwnode, "cooling-levels");
+ if (num <= 0)
+ return dev_err_probe(dev, num ? : -EINVAL,
+ "Failed to count elements in 'cooling-levels'\n");
+
+ hwm->fan_cooling_levels = devm_kcalloc(dev, num, sizeof(u32),
+ GFP_KERNEL);
+ if (!hwm->fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = fwnode_property_read_u32_array(fwnode, "cooling-levels",
+ hwm->fan_cooling_levels, num);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read 'cooling-levels'\n");
+
+ for (i = 0; i < num; i++) {
+ if (hwm->fan_cooling_levels[i] > hwm->pwm_max)
+ return dev_err_probe(dev, -EINVAL, "fan state[%d]:%d > %d\n", i,
+ hwm->fan_cooling_levels[i], hwm->pwm_max);
+ }
+
+ hwm->fan_max_state = num - 1;
+
+ return 0;
+}
+
+static const struct hwmon_channel_info * const qnap_mcu_hwmon_channels[] = {
+ HWMON_CHANNEL_INFO(pwm, HWMON_PWM_INPUT),
+ HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
+ NULL
+};
+
+static int qnap_mcu_hwmon_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ const struct qnap_mcu_variant *variant = pdev->dev.platform_data;
+ struct qnap_mcu_hwmon *hwm;
+ struct thermal_cooling_device *cdev;
+ struct device *dev = &pdev->dev;
+ struct device *hwmon;
+ int ret;
+
+ hwm = devm_kzalloc(dev, sizeof(*hwm), GFP_KERNEL);
+ if (!hwm)
+ return -ENOMEM;
+
+ hwm->mcu = mcu;
+ hwm->dev = &pdev->dev;
+ hwm->pwm_min = variant->fan_pwm_min;
+ hwm->pwm_max = variant->fan_pwm_max;
+
+ platform_set_drvdata(pdev, hwm);
+
+ /*
+ * Set duty cycle to maximum allowed.
+ */
+ ret = qnap_mcu_hwmon_set_pwm(hwm, hwm->pwm_max);
+ if (ret)
+ return ret;
+
+ hwm->info.ops = &qnap_mcu_hwmon_hwmon_ops;
+ hwm->info.info = qnap_mcu_hwmon_channels;
+
+ ret = qnap_mcu_hwmon_get_cooling_data(dev, hwm);
+ if (ret)
+ return ret;
+
+ hwm->fan_state = hwm->fan_max_state;
+
+ hwmon = devm_hwmon_device_register_with_info(dev, "qnapmcu",
+ hwm, &hwm->info, NULL);
+ if (IS_ERR(hwmon))
+ return dev_err_probe(dev, PTR_ERR(hwmon), "Failed to register hwmon device\n");
+
+ /*
+ * Only register cooling device when we found cooling-levels.
+ * qnap_mcu_hwmon_get_cooling_data() will fail when reading malformed
+ * levels and only succeed with either no or correct cooling levels.
+ */
+ if (IS_ENABLED(CONFIG_THERMAL) && hwm->fan_cooling_levels) {
+ cdev = devm_thermal_of_cooling_device_register(dev,
+ to_of_node(hwm->fan_node), "qnap-mcu-hwmon",
+ hwm, &qnap_mcu_hwmon_cooling_ops);
+ if (IS_ERR(cdev))
+ return dev_err_probe(dev, PTR_ERR(cdev),
+ "Failed to register qnap-mcu-hwmon as cooling device\n");
+ hwm->cdev = cdev;
+ }
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_hwmon_driver = {
+ .probe = qnap_mcu_hwmon_probe,
+ .driver = {
+ .name = "qnap-mcu-hwmon",
+ },
+};
+module_platform_driver(qnap_mcu_hwmon_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-hwmon");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU hwmon driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v8 6/9] Input: add driver for the input part of qnap-mcu devices
From: Heiko Stuebner @ 2024-09-08 21:08 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
The MCU controls the power-button and beeper, so expose them as input
device. There is of course no interrupt line, so the status of the
power-button needs to be polled. To generate an event the power-button
also needs to be held for 1-2 seconds, so the polling interval does
not need to be overly fast.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 1 +
drivers/input/misc/Kconfig | 12 +++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qnap-mcu-input.c | 153 ++++++++++++++++++++++++++++
4 files changed, 167 insertions(+)
create mode 100644 drivers/input/misc/qnap-mcu-input.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 943905cbcf62..cc5ef91d019e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/input/misc/qnap-mcu-input.c
F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
F: include/linux/qnap-mcu.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6a852c76331b..13d135257e06 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -917,6 +917,18 @@ config INPUT_HISI_POWERKEY
To compile this driver as a module, choose M here: the
module will be called hisi_powerkey.
+config INPUT_QNAP_MCU
+ tristate "Input Support for QNAP MCU controllers"
+ depends on MFD_QNAP_MCU
+ help
+ This option enables support for input elements available on
+ embedded controllers used in QNAP NAS devices.
+
+ This includes a polled power-button as well as a beeper.
+
+ To compile this driver as a module, choose M here: the
+ module will be called qnap-mcu-input.
+
config INPUT_RAVE_SP_PWRBUTTON
tristate "RAVE SP Power button Driver"
depends on RAVE_SP_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4f7f736831ba..6d91804d0a6f 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
+obj-$(CONFIG_INPUT_QNAP_MCU) += qnap-mcu-input.o
obj-$(CONFIG_INPUT_RAVE_SP_PWRBUTTON) += rave-sp-pwrbutton.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
diff --git a/drivers/input/misc/qnap-mcu-input.c b/drivers/input/misc/qnap-mcu-input.c
new file mode 100644
index 000000000000..76e62f0816c1
--- /dev/null
+++ b/drivers/input/misc/qnap-mcu-input.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Driver for input events on QNAP-MCUs
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/input.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <uapi/linux/input-event-codes.h>
+
+/*
+ * The power-key needs to be pressed for a while to create an event,
+ * so there is no use for overly frequent polling.
+ */
+#define POLL_INTERVAL 500
+
+struct qnap_mcu_input_dev {
+ struct input_dev *input;
+ struct qnap_mcu *mcu;
+ struct device *dev;
+
+ struct work_struct beep_work;
+ int beep_type;
+};
+
+static void qnap_mcu_input_poll(struct input_dev *input)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+ static const u8 cmd[] = { '@', 'C', 'V' };
+ u8 reply[4];
+ int state, ret;
+
+ /* poll the power button */
+ ret = qnap_mcu_exec(idev->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return;
+
+ /* First bytes must mirror the sent command */
+ if (memcmp(cmd, reply, sizeof(cmd))) {
+ dev_err(idev->dev, "malformed data received\n");
+ return;
+ }
+
+ state = reply[3] - 0x30;
+ input_event(input, EV_KEY, KEY_POWER, state);
+ input_sync(input);
+}
+
+static void qnap_mcu_input_beeper_work(struct work_struct *work)
+{
+ struct qnap_mcu_input_dev *idev =
+ container_of(work, struct qnap_mcu_input_dev, beep_work);
+ const u8 cmd[] = { '@', 'C', (idev->beep_type == SND_TONE) ? '3' : '2' };
+
+ qnap_mcu_exec_with_ack(idev->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_input_event(struct input_dev *input, unsigned int type,
+ unsigned int code, int value)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+
+ if (type != EV_SND || (code != SND_BELL && code != SND_TONE))
+ return -EOPNOTSUPP;
+
+ if (value < 0)
+ return -EINVAL;
+
+ /* beep runtime is determined by the MCU */
+ if (value == 0)
+ return 0;
+
+ /* Schedule work to actually turn the beeper on */
+ idev->beep_type = code;
+ schedule_work(&idev->beep_work);
+
+ return 0;
+}
+
+static void qnap_mcu_input_close(struct input_dev *input)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+
+ cancel_work_sync(&idev->beep_work);
+}
+
+static int qnap_mcu_input_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ struct qnap_mcu_input_dev *idev;
+ struct device *dev = &pdev->dev;
+ struct input_dev *input;
+ int ret;
+
+ idev = devm_kzalloc(dev, sizeof(*idev), GFP_KERNEL);
+ if (!idev)
+ return -ENOMEM;
+
+ input = devm_input_allocate_device(dev);
+ if (!input)
+ return dev_err_probe(dev, -ENOMEM, "no memory for input device\n");
+
+ idev->input = input;
+ idev->dev = dev;
+ idev->mcu = mcu;
+
+ input_set_drvdata(input, idev);
+
+ input->name = "qnap-mcu";
+ input->phys = "qnap-mcu-input/input0";
+ input->id.bustype = BUS_HOST;
+ input->id.vendor = 0x0001;
+ input->id.product = 0x0001;
+ input->id.version = 0x0100;
+ input->event = qnap_mcu_input_event;
+ input->close = qnap_mcu_input_close;
+
+ input_set_capability(input, EV_KEY, KEY_POWER);
+ input_set_capability(input, EV_SND, SND_BELL);
+ input_set_capability(input, EV_SND, SND_TONE);
+
+ INIT_WORK(&idev->beep_work, qnap_mcu_input_beeper_work);
+
+ ret = input_setup_polling(input, qnap_mcu_input_poll);
+ if (ret)
+ return dev_err_probe(dev, ret, "unable to set up polling\n");
+
+ input_set_poll_interval(input, POLL_INTERVAL);
+
+ ret = input_register_device(input);
+ if (ret)
+ return dev_err_probe(dev, ret, "unable to register input device\n");
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_input_driver = {
+ .probe = qnap_mcu_input_probe,
+ .driver = {
+ .name = "qnap-mcu-input",
+ },
+};
+module_platform_driver(qnap_mcu_input_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-input");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU input driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v8 4/9] mfd: add base driver for qnap-mcu devices
From: Heiko Stuebner @ 2024-09-08 21:07 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
These microcontroller units are used in network-attached-storage devices
made by QNAP and provide additional functionality to the system.
This adds the base driver that implements the serial protocol via
serdev and additionally hooks into the poweroff handlers to turn
off the parts of the system not supplied by the general PMIC.
Turning off (at least the TSx33 devices using Rockchip SoCs) consists of
two separate actions. Turning off the MCU alone does not turn off the main
SoC and turning off only the SoC/PMIC does not turn off the hard-drives.
Also if the MCU is not turned off, the system also won't start again until
it is unplugged from power.
So on shutdown the MCU needs to be turned off separately before the
main PMIC.
The protocol spoken by the MCU is sadly not documented, but was
obtained by listening to the chatter on the serial port, as thankfully
the "hal_app" program from QNAPs firmware allows triggering all/most
MCU actions from the command line.
The implementation of how to talk to the serial device got some
inspiration from the rave-sp servdev driver.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 6 +
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile | 2 +
drivers/mfd/qnap-mcu.c | 332 +++++++++++++++++++++++++++++++++++
include/linux/mfd/qnap-mcu.h | 26 +++
5 files changed, 379 insertions(+)
create mode 100644 drivers/mfd/qnap-mcu.c
create mode 100644 include/linux/mfd/qnap-mcu.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7889addb8949..ee6e98ba2e6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18679,6 +18679,12 @@ L: linux-media@vger.kernel.org
S: Odd Fixes
F: drivers/media/tuners/qm1d1c0042*
+QNAP MCU DRIVER
+M: Heiko Stuebner <heiko@sntech.de>
+S: Maintained
+F: drivers/mfd/qnap-mcu.c
+F: include/linux/qnap-mcu.h
+
QNX4 FILESYSTEM
M: Anders Larsen <al@alarsen.net>
S: Maintained
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bc8be2e593b6..63d51cc45891 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2362,6 +2362,19 @@ config MFD_INTEL_M10_BMC_PMCI
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_QNAP_MCU
+ tristate "QNAP microcontroller unit core driver"
+ depends on SERIAL_DEV_BUS
+ select MFD_CORE
+ help
+ Select this to get support for the QNAP MCU device found in
+ several devices of QNAP network attached storage products that
+ implements additional functionality for the device, like fan
+ and LED control.
+
+ This driver implements the base serial protocol to talk to the
+ device and provides functions for the other parts to hook into.
+
config MFD_RSMU_I2C
tristate "Renesas Synchronization Management Unit with I2C"
depends on I2C && OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 02b651cd7535..fc8b825725ff 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -286,5 +286,7 @@ obj-$(CONFIG_MFD_INTEL_M10_BMC_PMCI) += intel-m10-bmc-pmci.o
obj-$(CONFIG_MFD_ATC260X) += atc260x-core.o
obj-$(CONFIG_MFD_ATC260X_I2C) += atc260x-i2c.o
+obj-$(CONFIG_MFD_QNAP_MCU) += qnap-mcu.o
+
obj-$(CONFIG_MFD_RSMU_I2C) += rsmu_i2c.o rsmu_core.o
obj-$(CONFIG_MFD_RSMU_SPI) += rsmu_spi.o rsmu_core.o
diff --git a/drivers/mfd/qnap-mcu.c b/drivers/mfd/qnap-mcu.c
new file mode 100644
index 000000000000..2a52ac01f5fc
--- /dev/null
+++ b/drivers/mfd/qnap-mcu.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Core driver for the microcontroller unit in QNAP NAS devices that is
+ * connected via a dedicated UART port.
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/cleanup.h>
+#include <linux/export.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/reboot.h>
+#include <linux/serdev.h>
+#include <linux/slab.h>
+
+/* The longest command found so far is 5 bytes long */
+#define QNAP_MCU_MAX_CMD_SIZE 5
+#define QNAP_MCU_MAX_DATA_SIZE 36
+#define QNAP_MCU_CHECKSUM_SIZE 1
+
+#define QNAP_MCU_RX_BUFFER_SIZE \
+ (QNAP_MCU_MAX_DATA_SIZE + QNAP_MCU_CHECKSUM_SIZE)
+
+#define QNAP_MCU_TX_BUFFER_SIZE \
+ (QNAP_MCU_MAX_CMD_SIZE + QNAP_MCU_CHECKSUM_SIZE)
+
+#define QNAP_MCU_ACK_LEN 2
+#define QNAP_MCU_VERSION_LEN 4
+
+/**
+ * struct qnap_mcu_reply - Reply to a command
+ *
+ * @data: Buffer to store reply payload in
+ * @length: Expected reply length, including the checksum
+ * @received: Received number of bytes, so far
+ * @done: Triggered when the entire reply has been received
+ */
+struct qnap_mcu_reply {
+ u8 *data;
+ size_t length;
+ size_t received;
+ struct completion done;
+};
+
+/**
+ * struct qnap_mcu - QNAP NAS embedded controller
+ *
+ * @serdev: Pointer to underlying serdev
+ * @bus_lock: Lock to serialize access to the device
+ * @reply: Reply data structure
+ * @variant: Device variant specific information
+ * @version: MCU firmware version
+ */
+struct qnap_mcu {
+ struct serdev_device *serdev;
+ struct mutex bus_lock;
+ struct qnap_mcu_reply reply;
+ const struct qnap_mcu_variant *variant;
+ u8 version[QNAP_MCU_VERSION_LEN];
+};
+
+/*
+ * The QNAP-MCU uses a basic XOR checksum.
+ * It is always the last byte and XORs the whole previous message.
+ */
+static u8 qnap_mcu_csum(const u8 *buf, size_t size)
+{
+ u8 csum = 0;
+
+ while (size--)
+ csum ^= *buf++;
+
+ return csum;
+}
+
+static int qnap_mcu_write(struct qnap_mcu *mcu, const u8 *data, u8 data_size)
+{
+ unsigned char tx[QNAP_MCU_TX_BUFFER_SIZE];
+ size_t length = data_size + QNAP_MCU_CHECKSUM_SIZE;
+
+ if (length > sizeof(tx)) {
+ dev_err(&mcu->serdev->dev, "data too big for transmit buffer");
+ return -EINVAL;
+ }
+
+ memcpy(tx, data, data_size);
+ tx[data_size] = qnap_mcu_csum(data, data_size);
+
+ return serdev_device_write(mcu->serdev, tx, length, HZ);
+}
+
+static size_t qnap_mcu_receive_buf(struct serdev_device *serdev, const u8 *buf, size_t size)
+{
+ struct device *dev = &serdev->dev;
+ struct qnap_mcu *mcu = dev_get_drvdata(dev);
+ struct qnap_mcu_reply *reply = &mcu->reply;
+ const u8 *src = buf;
+ const u8 *end = buf + size;
+
+ if (!reply->length) {
+ dev_warn(dev, "Received %zu bytes, we were not waiting for\n", size);
+ return size;
+ }
+
+ while (src < end) {
+ reply->data[reply->received] = *src++;
+ reply->received++;
+
+ if (reply->received == reply->length) {
+ complete(&reply->done);
+
+ /*
+ * We report the consumed number of bytes. If there
+ * are still bytes remaining (though there shouldn't)
+ * the serdev layer will re-execute this handler with
+ * the remainder of the Rx bytes.
+ */
+ return src - buf;
+ }
+ }
+
+ /*
+ * The only way to get out of the above loop and end up here
+ * is through consuming all of the supplied data, so here we
+ * report that we processed it all.
+ */
+ return size;
+}
+
+static const struct serdev_device_ops qnap_mcu_serdev_device_ops = {
+ .receive_buf = qnap_mcu_receive_buf,
+ .write_wakeup = serdev_device_write_wakeup,
+};
+
+int qnap_mcu_exec(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size,
+ u8 *reply_data, size_t reply_data_size)
+{
+ unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
+ size_t length = reply_data_size + QNAP_MCU_CHECKSUM_SIZE;
+ struct qnap_mcu_reply *reply = &mcu->reply;
+ int ret = 0;
+
+ if (length > sizeof(rx)) {
+ dev_err(&mcu->serdev->dev, "expected data too big for receive buffer");
+ return -EINVAL;
+ }
+
+ mutex_lock(&mcu->bus_lock);
+
+ reply->data = rx,
+ reply->length = length,
+ reply->received = 0,
+ reinit_completion(&reply->done);
+
+ qnap_mcu_write(mcu, cmd_data, cmd_data_size);
+
+ if (!wait_for_completion_timeout(&reply->done, msecs_to_jiffies(500))) {
+ dev_err(&mcu->serdev->dev, "Command timeout\n");
+ ret = -ETIMEDOUT;
+ } else {
+ u8 crc = qnap_mcu_csum(rx, reply_data_size);
+
+ if (crc != rx[reply_data_size]) {
+ dev_err(&mcu->serdev->dev,
+ "Invalid Checksum received\n");
+ ret = -EIO;
+ } else {
+ memcpy(reply_data, rx, reply_data_size);
+ }
+ }
+
+ /* We don't expect any characters from the device now */
+ reply->length = 0;
+
+ mutex_unlock(&mcu->bus_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(qnap_mcu_exec);
+
+int qnap_mcu_exec_with_ack(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size)
+{
+ u8 ack[QNAP_MCU_ACK_LEN];
+ int ret;
+
+ ret = qnap_mcu_exec(mcu, cmd_data, cmd_data_size, ack, sizeof(ack));
+ if (ret)
+ return ret;
+
+ /* Should return @0 */
+ if (ack[0] != 0x40 || ack[1] != 0x30) {
+ dev_err(&mcu->serdev->dev, "Did not receive ack\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qnap_mcu_exec_with_ack);
+
+static int qnap_mcu_get_version(struct qnap_mcu *mcu)
+{
+ const u8 cmd[] = { '%', 'V' };
+ u8 rx[14];
+ int ret;
+
+ /* Reply is the 2 command-bytes + 4 bytes describing the version */
+ ret = qnap_mcu_exec(mcu, cmd, sizeof(cmd), rx, QNAP_MCU_VERSION_LEN + 2);
+ if (ret)
+ return ret;
+
+ memcpy(mcu->version, &rx[2], QNAP_MCU_VERSION_LEN);
+
+ return 0;
+}
+
+/*
+ * The MCU controls power to the peripherals but not the CPU.
+ *
+ * So using the PMIC to power off the system keeps the MCU and hard-drives
+ * running. This also then prevents the system from turning back on until
+ * the MCU is turned off by unplugging the power cable.
+ * Turning off the MCU alone on the other hand turns off the hard drives,
+ * LEDs, etc while the main SoC stays running - including its network ports.
+ */
+static int qnap_mcu_power_off(struct sys_off_data *data)
+{
+ const u8 cmd[] = { '@', 'C', '0' };
+ struct qnap_mcu *mcu = data->cb_data;
+ int ret;
+
+ ret = qnap_mcu_exec_with_ack(mcu, cmd, sizeof(cmd));
+ if (ret) {
+ dev_err(&mcu->serdev->dev, "MCU poweroff failed %d\n", ret);
+ return NOTIFY_STOP;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static const struct qnap_mcu_variant qnap_ts433_mcu = {
+ .baud_rate = 115200,
+ .num_drives = 4,
+ .fan_pwm_min = 51, /* Specified in original model.conf */
+ .fan_pwm_max = 255,
+ .usb_led = true,
+};
+
+static struct mfd_cell qnap_mcu_cells[] = {
+ { .name = "qnap-mcu-input", },
+ { .name = "qnap-mcu-leds", },
+ { .name = "qnap-mcu-hwmon", }
+};
+
+static int qnap_mcu_probe(struct serdev_device *serdev)
+{
+ struct device *dev = &serdev->dev;
+ struct qnap_mcu *mcu;
+ int ret;
+
+ mcu = devm_kzalloc(dev, sizeof(*mcu), GFP_KERNEL);
+ if (!mcu)
+ return -ENOMEM;
+
+ mcu->serdev = serdev;
+ dev_set_drvdata(dev, mcu);
+
+ mcu->variant = of_device_get_match_data(dev);
+ if (!mcu->variant)
+ return -ENODEV;
+
+ mutex_init(&mcu->bus_lock);
+ init_completion(&mcu->reply.done);
+
+ serdev_device_set_client_ops(serdev, &qnap_mcu_serdev_device_ops);
+ ret = devm_serdev_device_open(dev, serdev);
+ if (ret)
+ return ret;
+
+ serdev_device_set_baudrate(serdev, mcu->variant->baud_rate);
+ serdev_device_set_flow_control(serdev, false);
+
+ ret = serdev_device_set_parity(serdev, SERDEV_PARITY_NONE);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to set parity\n");
+
+ ret = qnap_mcu_get_version(mcu);
+ if (ret)
+ return ret;
+
+ ret = devm_register_sys_off_handler(dev,
+ SYS_OFF_MODE_POWER_OFF_PREPARE,
+ SYS_OFF_PRIO_DEFAULT,
+ &qnap_mcu_power_off, mcu);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to register poweroff handler\n");
+
+ for (int i = 0; i < ARRAY_SIZE(qnap_mcu_cells); i++) {
+ qnap_mcu_cells[i].platform_data = mcu->variant;
+ qnap_mcu_cells[i].pdata_size = sizeof(*mcu->variant);
+ }
+
+ ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, qnap_mcu_cells,
+ ARRAY_SIZE(qnap_mcu_cells), NULL, 0, NULL);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add child devices\n");
+
+ return 0;
+}
+
+static const struct of_device_id qnap_mcu_dt_ids[] = {
+ { .compatible = "qnap,ts433-mcu", .data = &qnap_ts433_mcu },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, qnap_mcu_dt_ids);
+
+static struct serdev_device_driver qnap_mcu_drv = {
+ .probe = qnap_mcu_probe,
+ .driver = {
+ .name = "qnap-mcu",
+ .of_match_table = qnap_mcu_dt_ids,
+ },
+};
+module_serdev_device_driver(qnap_mcu_drv);
+
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU core driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/qnap-mcu.h b/include/linux/mfd/qnap-mcu.h
new file mode 100644
index 000000000000..8d48c212fd44
--- /dev/null
+++ b/include/linux/mfd/qnap-mcu.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Core definitions for QNAP MCU MFD driver.
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#ifndef _LINUX_QNAP_MCU_H_
+#define _LINUX_QNAP_MCU_H_
+
+struct qnap_mcu;
+
+struct qnap_mcu_variant {
+ u32 baud_rate;
+ int num_drives;
+ int fan_pwm_min;
+ int fan_pwm_max;
+ bool usb_led;
+};
+
+int qnap_mcu_exec(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size,
+ u8 *reply_data, size_t reply_data_size);
+int qnap_mcu_exec_with_ack(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size);
+
+#endif /* _LINUX_QNAP_MCU_H_ */
--
2.43.0
^ permalink raw reply related
* [PATCH v8 5/9] leds: add driver for LEDs from qnap-mcu devices
From: Heiko Stuebner @ 2024-09-08 21:07 UTC (permalink / raw)
To: lee, jikos, jic23
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, srinivas.pandruvada,
bentiss, dmitry.torokhov, pavel, ukleinek, devicetree,
linux-kernel, linux-hwmon, linux-arm-kernel, linux-rockchip,
linux-input, linux-iio, linux-leds, Heiko Stuebner
In-Reply-To: <20240908210803.3339919-1-heiko@sntech.de>
This adds a driver that connects to the qnap-mcu mfd driver and provides
access to the LEDs on it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 1 +
drivers/leds/Kconfig | 11 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-qnap-mcu.c | 227 +++++++++++++++++++++++++++++++++++
4 files changed, 240 insertions(+)
create mode 100644 drivers/leds/leds-qnap-mcu.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ee6e98ba2e6f..943905cbcf62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
F: include/linux/qnap-mcu.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8d9d8da376e4..9a337478dd80 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -580,6 +580,17 @@ config LEDS_PCA995X
LED driver chips accessed via the I2C bus. Supported
devices include PCA9955BTW, PCA9952TW and PCA9955TW.
+config LEDS_QNAP_MCU
+ tristate "LED Support for QNAP MCU controllers"
+ depends on LEDS_CLASS
+ depends on MFD_QNAP_MCU
+ help
+ This option enables support for LEDs available on embedded
+ controllers used in QNAP NAS devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called qnap-mcu-leds.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 18afbb5a23ee..c6f74865d729 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA995X) += leds-pca995x.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_QNAP_MCU) += leds-qnap-mcu.o
obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
obj-$(CONFIG_LEDS_SUN50I_A100) += leds-sun50i-a100.o
diff --git a/drivers/leds/leds-qnap-mcu.c b/drivers/leds/leds-qnap-mcu.c
new file mode 100644
index 000000000000..4e4709456261
--- /dev/null
+++ b/drivers/leds/leds-qnap-mcu.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for LEDs found on QNAP MCU devices
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/leds.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+enum qnap_mcu_err_led_mode {
+ QNAP_MCU_ERR_LED_ON = 0,
+ QNAP_MCU_ERR_LED_OFF = 1,
+ QNAP_MCU_ERR_LED_BLINK_FAST = 2,
+ QNAP_MCU_ERR_LED_BLINK_SLOW = 3,
+};
+
+struct qnap_mcu_err_led {
+ struct qnap_mcu *mcu;
+ struct led_classdev cdev;
+ char name[LED_MAX_NAME_SIZE];
+ u8 num;
+ u8 mode;
+};
+
+static inline struct qnap_mcu_err_led *
+ cdev_to_qnap_mcu_err_led(struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct qnap_mcu_err_led, cdev);
+}
+
+static int qnap_mcu_err_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct qnap_mcu_err_led *err_led = cdev_to_qnap_mcu_err_led(led_cdev);
+ u8 cmd[] = { '@', 'R', '0' + err_led->num, '0' };
+
+ /* Don't disturb a possible set blink-mode if LED stays on */
+ if (brightness != 0 && err_led->mode >= QNAP_MCU_ERR_LED_BLINK_FAST)
+ return 0;
+
+ err_led->mode = brightness ? QNAP_MCU_ERR_LED_ON : QNAP_MCU_ERR_LED_OFF;
+ cmd[3] = '0' + err_led->mode;
+
+ return qnap_mcu_exec_with_ack(err_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_err_led_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct qnap_mcu_err_led *err_led = cdev_to_qnap_mcu_err_led(led_cdev);
+ u8 cmd[] = { '@', 'R', '0' + err_led->num, '0' };
+
+ /* LED is off, nothing to do */
+ if (err_led->mode == QNAP_MCU_ERR_LED_OFF)
+ return 0;
+
+ if (*delay_on < 500) {
+ *delay_on = 100;
+ *delay_off = 100;
+ err_led->mode = QNAP_MCU_ERR_LED_BLINK_FAST;
+ } else {
+ *delay_on = 500;
+ *delay_off = 500;
+ err_led->mode = QNAP_MCU_ERR_LED_BLINK_SLOW;
+ }
+
+ cmd[3] = '0' + err_led->mode;
+
+ return qnap_mcu_exec_with_ack(err_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_register_err_led(struct device *dev, struct qnap_mcu *mcu, int num_err_led)
+{
+ struct qnap_mcu_err_led *err_led;
+ int ret;
+
+ err_led = devm_kzalloc(dev, sizeof(*err_led), GFP_KERNEL);
+ if (!err_led)
+ return -ENOMEM;
+
+ err_led->mcu = mcu;
+ err_led->num = num_err_led;
+ err_led->mode = QNAP_MCU_ERR_LED_OFF;
+
+ scnprintf(err_led->name, LED_MAX_NAME_SIZE, "hdd%d:red:status", num_err_led + 1);
+ err_led->cdev.name = err_led->name;
+
+ err_led->cdev.brightness_set_blocking = qnap_mcu_err_led_set;
+ err_led->cdev.blink_set = qnap_mcu_err_led_blink_set;
+ err_led->cdev.brightness = 0;
+ err_led->cdev.max_brightness = 1;
+
+ ret = devm_led_classdev_register(dev, &err_led->cdev);
+ if (ret)
+ return ret;
+
+ return qnap_mcu_err_led_set(&err_led->cdev, 0);
+}
+
+enum qnap_mcu_usb_led_mode {
+ QNAP_MCU_USB_LED_ON = 1,
+ QNAP_MCU_USB_LED_OFF = 3,
+ QNAP_MCU_USB_LED_BLINK = 2,
+};
+
+struct qnap_mcu_usb_led {
+ struct qnap_mcu *mcu;
+ struct led_classdev cdev;
+ u8 mode;
+};
+
+static inline struct qnap_mcu_usb_led *
+ cdev_to_qnap_mcu_usb_led(struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct qnap_mcu_usb_led, cdev);
+}
+
+static int qnap_mcu_usb_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct qnap_mcu_usb_led *usb_led = cdev_to_qnap_mcu_usb_led(led_cdev);
+ u8 cmd[] = { '@', 'C', 0 };
+
+ /* Don't disturb a possible set blink-mode if LED stays on */
+ if (brightness != 0 && usb_led->mode == QNAP_MCU_USB_LED_BLINK)
+ return 0;
+
+ usb_led->mode = brightness ? QNAP_MCU_USB_LED_ON : QNAP_MCU_USB_LED_OFF;
+
+ /*
+ * Byte 3 is shared between the usb led target on/off/blink
+ * and also the buzzer control (in the input driver)
+ */
+ cmd[2] = 'D' + usb_led->mode;
+
+ return qnap_mcu_exec_with_ack(usb_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_usb_led_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct qnap_mcu_usb_led *usb_led = cdev_to_qnap_mcu_usb_led(led_cdev);
+ u8 cmd[] = { '@', 'C', 0 };
+
+ /* LED is off, nothing to do */
+ if (usb_led->mode == QNAP_MCU_USB_LED_OFF)
+ return 0;
+
+ *delay_on = 250;
+ *delay_off = 250;
+ usb_led->mode = QNAP_MCU_USB_LED_BLINK;
+
+ /*
+ * Byte 3 is shared between the USB LED target on/off/blink
+ * and also the buzzer control (in the input driver)
+ */
+ cmd[2] = 'D' + usb_led->mode;
+
+ return qnap_mcu_exec_with_ack(usb_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_register_usb_led(struct device *dev, struct qnap_mcu *mcu)
+{
+ struct qnap_mcu_usb_led *usb_led;
+ int ret;
+
+ usb_led = devm_kzalloc(dev, sizeof(*usb_led), GFP_KERNEL);
+ if (!usb_led)
+ return -ENOMEM;
+
+ usb_led->mcu = mcu;
+ usb_led->mode = QNAP_MCU_USB_LED_OFF;
+ usb_led->cdev.name = "usb:blue:disk";
+ usb_led->cdev.brightness_set_blocking = qnap_mcu_usb_led_set;
+ usb_led->cdev.blink_set = qnap_mcu_usb_led_blink_set;
+ usb_led->cdev.brightness = 0;
+ usb_led->cdev.max_brightness = 1;
+
+ ret = devm_led_classdev_register(dev, &usb_led->cdev);
+ if (ret)
+ return ret;
+
+ return qnap_mcu_usb_led_set(&usb_led->cdev, 0);
+}
+
+static int qnap_mcu_leds_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ const struct qnap_mcu_variant *variant = pdev->dev.platform_data;
+ int ret;
+
+ for (int i = 0; i < variant->num_drives; i++) {
+ ret = qnap_mcu_register_err_led(&pdev->dev, mcu, i);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register error LED %d\n", i);
+ }
+
+ if (variant->usb_led) {
+ ret = qnap_mcu_register_usb_led(&pdev->dev, mcu);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register USB LED\n");
+ }
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_leds_driver = {
+ .probe = qnap_mcu_leds_probe,
+ .driver = {
+ .name = "qnap-mcu-leds",
+ },
+};
+module_platform_driver(qnap_mcu_leds_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-leds");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU LEDs driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: input: update reference to m8921-keypad.yaml
From: Simon Horman @ 2024-09-08 20:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Dmitry Torokhov, Dmitry Baryshkov, devicetree, linux-arm-msm,
linux-input
commit 53ed3233e6b5 ("dt-bindings: input: qcom,pm8921-keypad: convert to
YAML format") resulted in a renaming of the output .txt file from
qcom,pm8xxx-keypad.txt to qcom,pm8921-keypad.yaml.
This patch makes a corresponding update to the link to that .txt file
in wakeup-source.txt.
Flagged by make htmldocs:
Warning: Documentation/devicetree/bindings/power/wakeup-source.txt references a file that doesn't exist: Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
Signed-off-by: Simon Horman <horms@kernel.org>
---
Documentation/devicetree/bindings/power/wakeup-source.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt
index a6c8978964aa..128b55be67b7 100644
--- a/Documentation/devicetree/bindings/power/wakeup-source.txt
+++ b/Documentation/devicetree/bindings/power/wakeup-source.txt
@@ -26,7 +26,7 @@ List of legacy properties and respective binding document
3. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
Documentation/devicetree/bindings/mfd/tc3589x.txt
Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
-4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
+4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml
5. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
6. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
^ permalink raw reply related
* [PATCH] dt-binding: touchscreen: fix x-plat-ohm missing type definition
From: Sayyad Abid @ 2024-09-08 15:17 UTC (permalink / raw)
To: devicetree
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, Michael Welling, linux-input, linux-kernel,
sayyad.abid16
This patch fixes the issue with x-plat-ohm missing a type definition.
The patch adds the fix for this issue by adding value of this property
should be a 32-bit unsigned integer.
Signed-off-by: Sayyad Abid <sayyad.abid16@gmail.com>
---
.../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
index 7187c390b2f5..98ff65cf9f9f 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
@@ -38,6 +38,8 @@ properties:
ti,x-plate-ohms:
description: resistance of the touchscreen's X plates in ohm (defaults to 280)
+ $ref: /schemas/types.yaml#/definitions/uint32
+
ti,esd-recovery-timeout-ms:
description: |
--
2.39.2
^ permalink raw reply related
* [PATCH v5 2/2] input: add driver for Hynitron CST816X touchscreen
From: Oleh Kuzhylnyi @ 2024-09-08 11:30 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-input,
devicetree, linux-kernel, Oleh Kuzhylnyi, Conor Dooley,
igor.opaniuk, Neil Armstrong, Jeff LaBundy
In-Reply-To: <20240908113027.69471-1-kuzhylol@gmail.com>
Introduce support for the Hynitron CST816X touchscreen controller
used for 240×240 1.28-inch Round LCD Display Module manufactured
by Waveshare Electronics. The driver is designed based on an Arduino
implementation marked as under MIT License. This driver is written
for a particular round display based on the CST816S controller, which
is not compatiable with existing driver for Hynitron controllers.
Signed-off-by: Oleh Kuzhylnyi <kuzhylol@gmail.com>
---
Changes in v5:
- Update commit based on Dmitry's feedback:
- Make GPIO reset optional
- Combine declaration and initialization for i2c_xfer
- Return 0 explicitly where possible
- Rename rc (return code) to error
- Make Touch processing call return boolean
- Improve error handling for i2c_transfer
- Use get_unaligned_be16 for getting coordinates
- Move touch event completeness upper to irq callback
Changes in v4:
- Update commit based on Dmitry's feedback:
- Move abs_x and abs_y to u16
- Remove __packed qualifier for touch_info struct
- Hide tiny touch irq context to stack
- Extend cst816x_i2c_read_register() with buf and buf_size
- Remove loop from event lookup
Changes in v3:
- Drop timer and delayed work
- Process touch in threaded IRQ context
- Fix chip reset sequence
- Move input_register() before devm_request_threaded_irq()
- Re-arrange and document input reporting
- Set u16 data type for event_code
- Remove double tap event to prevent continuous double side sliding
Changes in v2:
- Apply dev_err_probe() for better error handling
- Remove redundant printing, remove dev_warn() message spamming
- Get rid of PM since the touchscreen goes into sleep mode automatically
- Get rid of IRQ control and IRQF_NO_AUTOEN flag
- Reduce timer timeout up to 10ms to handle touch events faster
- Skip registering of non-gesture CST816X_SWIPE event
- Shift input_register_device() as a final call in probe() callback
- Specify name of i2c_device_id explicitly
- Update module description and fix typo
- Add necessary spaces between lines
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/hynitron-cst816x.c | 259 +++++++++++++++++++
3 files changed, 272 insertions(+)
create mode 100644 drivers/input/touchscreen/hynitron-cst816x.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index c821fe3ee794..02f40d0fbac0 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -481,6 +481,18 @@ config TOUCHSCREEN_HYNITRON_CSTXXX
To compile this driver as a module, choose M here: the
module will be called hynitron-cstxxx.
+config TOUCHSCREEN_HYNITRON_CST816X
+ tristate "Hynitron CST816X touchscreen support"
+ depends on I2C
+ help
+ Say Y here if you have a touchscreen using a Hynitron
+ CST816X touchscreen controller.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hynitron-cst816x.
+
config TOUCHSCREEN_ILI210X
tristate "Ilitek ILI210X based touchscreen"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index a81cb5aa21a5..a92a87417a97 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_CORE) += goodix_berlin_core.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_I2C) += goodix_berlin_i2c.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_SPI) += goodix_berlin_spi.o
obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
+obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CST816X) += hynitron-cst816x.o
obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CSTXXX) += hynitron_cstxxx.o
obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
obj-$(CONFIG_TOUCHSCREEN_ILITEK) += ilitek_ts_i2c.o
diff --git a/drivers/input/touchscreen/hynitron-cst816x.c b/drivers/input/touchscreen/hynitron-cst816x.c
new file mode 100644
index 000000000000..3886617e6a71
--- /dev/null
+++ b/drivers/input/touchscreen/hynitron-cst816x.c
@@ -0,0 +1,259 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Driver for I2C connected Hynitron CST816X Touchscreen
+ *
+ * Copyright (C) 2024 Oleh Kuzhylnyi <kuzhylol@gmail.com>
+ */
+#include <asm/unaligned.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+
+enum cst816x_registers {
+ CST816X_FRAME = 0x01,
+ CST816X_MOTION = 0xEC,
+};
+
+enum cst816x_gestures {
+ CST816X_SWIPE_UP = 0x01,
+ CST816X_SWIPE_DOWN = 0x02,
+ CST816X_SWIPE_LEFT = 0x03,
+ CST816X_SWIPE_RIGHT = 0x04,
+ CST816X_SINGLE_TAP = 0x05,
+ CST816X_LONG_PRESS = 0x0C,
+ CST816X_RESERVED = 0xFF,
+};
+
+struct cst816x_touch_info {
+ u8 gesture;
+ u8 touch;
+ u16 abs_x;
+ u16 abs_y;
+};
+
+struct cst816x_priv {
+ struct device *dev;
+ struct i2c_client *client;
+ struct gpio_desc *reset;
+ struct input_dev *input;
+};
+
+struct cst816x_event_mapping {
+ enum cst816x_gestures gesture;
+ u16 code;
+};
+
+static const struct cst816x_event_mapping event_map[16] = {
+ {CST816X_SWIPE_UP, BTN_FORWARD},
+ {CST816X_SWIPE_DOWN, BTN_BACK},
+ {CST816X_SWIPE_LEFT, BTN_LEFT},
+ {CST816X_SWIPE_RIGHT, BTN_RIGHT},
+ {CST816X_SINGLE_TAP, BTN_TOUCH},
+ {CST816X_LONG_PRESS, BTN_TOOL_TRIPLETAP},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+ {CST816X_RESERVED, KEY_RESERVED},
+};
+
+static int cst816x_i2c_read_register(struct cst816x_priv *priv, u8 reg,
+ void *buf, size_t len)
+{
+ int rc;
+ struct i2c_msg xfer[] = {
+ {
+ .addr = priv->client->addr,
+ .flags = 0,
+ .buf = ®,
+ .len = sizeof(reg),
+ },
+ {
+ .addr = priv->client->addr,
+ .flags = I2C_M_RD,
+ .buf = buf,
+ .len = len,
+ },
+ };
+
+ rc = i2c_transfer(priv->client->adapter, xfer, ARRAY_SIZE(xfer));
+ if (rc != ARRAY_SIZE(xfer)) {
+ rc = rc < 0 ? rc : -EIO;
+ dev_err(&priv->client->dev, "i2c rx err: %d\n", rc);
+ return rc;
+ }
+
+ return 0;
+}
+
+static bool cst816x_process_touch(struct cst816x_priv *priv,
+ struct cst816x_touch_info *info)
+{
+ u8 raw[8];
+
+ if (cst816x_i2c_read_register(priv, CST816X_FRAME, raw, sizeof(raw)))
+ return false;
+
+ info->gesture = raw[0];
+ info->touch = raw[1];
+ info->abs_x = get_unaligned_be16(&raw[2]) & GENMASK(11, 0);
+ info->abs_y = get_unaligned_be16(&raw[4]) & GENMASK(11, 0);
+
+ dev_dbg(priv->dev, "x: %d, y: %d, t: %d, g: 0x%x\n", info->abs_x,
+ info->abs_y, info->touch, info->gesture);
+
+ return true;
+}
+
+static int cst816x_register_input(struct cst816x_priv *priv)
+{
+ priv->input = devm_input_allocate_device(priv->dev);
+ if (!priv->input)
+ return -ENOMEM;
+
+ priv->input->name = "Hynitron CST816X Touchscreen";
+ priv->input->phys = "input/ts";
+ priv->input->id.bustype = BUS_I2C;
+ input_set_drvdata(priv->input, priv);
+
+ for (unsigned int i = 0; i < ARRAY_SIZE(event_map); i++)
+ input_set_capability(priv->input, EV_KEY, event_map[i].code);
+
+ input_set_abs_params(priv->input, ABS_X, 0, 240, 0, 0);
+ input_set_abs_params(priv->input, ABS_Y, 0, 240, 0, 0);
+
+ return input_register_device(priv->input);
+}
+
+static void cst816x_reset(struct cst816x_priv *priv)
+{
+ if (priv->reset) {
+ gpiod_set_value_cansleep(priv->reset, 1);
+ msleep(50);
+ gpiod_set_value_cansleep(priv->reset, 0);
+ msleep(100);
+ }
+}
+
+static void report_gesture_event(const struct cst816x_priv *priv,
+ enum cst816x_gestures gesture, bool touch)
+{
+ u16 key = event_map[gesture & 0x0F].code;
+
+ if (key != KEY_RESERVED)
+ input_report_key(priv->input, key, touch);
+}
+
+/*
+ * Supports five gestures: TOUCH, LEFT, RIGHT, FORWARD, BACK, and LONG_PRESS.
+ * Reports surface interaction, sliding coordinates and finger detachment.
+ *
+ * 1. TOUCH Gesture Scenario:
+ *
+ * [x/y] [touch] [gesture] [Action] [Report ABS] [Report Key]
+ * x y true 0x00 Touch ABS_X_Y BTN_TOUCH
+ * x y true 0x00 Slide ABS_X_Y
+ * x y false 0x05 Gesture BTN_TOUCH
+ *
+ * 2. LEFT, RIGHT, FORWARD, BACK, and LONG_PRESS Gestures Scenario:
+ *
+ * [x/y] [touch] [gesture] [Action] [Report ABS] [Report Key]
+ * x y true 0x00 Touch ABS_X_Y BTN_TOUCH
+ * x y true 0x01 Gesture ABS_X_Y BTN_FORWARD
+ * x y true 0x01 Slide ABS_X_Y
+ * x y false 0x01 Detach BTN_FORWARD | BTN_TOUCH
+ */
+static irqreturn_t cst816x_irq_cb(int irq, void *cookie)
+{
+ struct cst816x_priv *priv = cookie;
+ struct cst816x_touch_info info;
+
+ if (!cst816x_process_touch(priv, &info))
+ goto out;
+
+ if (info.touch) {
+ input_report_abs(priv->input, ABS_X, info.abs_x);
+ input_report_abs(priv->input, ABS_Y, info.abs_y);
+ input_report_key(priv->input, BTN_TOUCH, 1);
+ }
+
+ if (info.gesture) {
+ report_gesture_event(priv, info.gesture, info.touch);
+
+ if (!info.touch)
+ input_report_key(priv->input, BTN_TOUCH, 0);
+ }
+
+ input_sync(priv->input);
+
+out:
+ return IRQ_HANDLED;
+}
+
+static int cst816x_probe(struct i2c_client *client)
+{
+ struct cst816x_priv *priv;
+ struct device *dev = &client->dev;
+ int error;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ priv->client = client;
+
+ priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset))
+ return dev_err_probe(dev, PTR_ERR(priv->reset),
+ "reset gpio not found\n");
+
+ cst816x_reset(priv);
+
+ error = cst816x_register_input(priv);
+ if (error)
+ return dev_err_probe(dev, error, "input register failed\n");
+
+ error = devm_request_threaded_irq(dev, client->irq, NULL, cst816x_irq_cb,
+ IRQF_ONESHOT, dev->driver->name, priv);
+ if (error)
+ return dev_err_probe(dev, error, "irq request failed\n");
+
+ return 0;
+}
+
+static const struct i2c_device_id cst816x_id[] = {
+ { .name = "cst816s", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, cst816x_id);
+
+static const struct of_device_id cst816x_of_match[] = {
+ { .compatible = "hynitron,cst816s", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cst816x_of_match);
+
+static struct i2c_driver cst816x_driver = {
+ .driver = {
+ .name = "cst816x",
+ .of_match_table = cst816x_of_match,
+ },
+ .id_table = cst816x_id,
+ .probe = cst816x_probe,
+};
+
+module_i2c_driver(cst816x_driver);
+
+MODULE_AUTHOR("Oleh Kuzhylnyi <kuzhylol@gmail.com>");
+MODULE_DESCRIPTION("Hynitron CST816X Touchscreen Driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: input: touchscreen: add Hynitron CST816X
From: Oleh Kuzhylnyi @ 2024-09-08 11:30 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-input,
devicetree, linux-kernel, Oleh Kuzhylnyi, Conor Dooley,
igor.opaniuk, Neil Armstrong, Jeff LaBundy
Add documentation for the Hynitron CST816X touchscreen bindings.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Oleh Kuzhylnyi <kuzhylol@gmail.com>
---
.../input/touchscreen/hynitron,cst816s.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816s.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816s.yaml b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816s.yaml
new file mode 100644
index 000000000000..ac9f1d8e8fc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816s.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/hynitron,cst816s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hynitron CST816S Touchscreen controller
+
+description:
+ Hynitron CST816S Touchscreen controller for 1.28-inch 240x240 Resolution
+ Touch LCD Display Module
+
+maintainers:
+ - Oleh Kuzhylnyi <kuzhylol@gmail.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - hynitron,cst816s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@15 {
+ compatible = "hynitron,cst816s";
+ reg = <0x15>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+...
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v7 1/8] mfd: core: make platform_data pointer const in struct mfd_cell
From: kernel test robot @ 2024-09-08 8:22 UTC (permalink / raw)
To: Heiko Stuebner, lee
Cc: llvm, oe-kbuild-all, robh, krzk+dt, conor+dt, jdelvare, linux,
heiko, dmitry.torokhov, pavel, ukleinek, devicetree, linux-kernel,
linux-hwmon, linux-arm-kernel, linux-rockchip, linux-input,
linux-leds
In-Reply-To: <20240905185232.2899464-2-heiko@sntech.de>
Hi Heiko,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20240905]
[also build test ERROR on v6.11-rc6]
[cannot apply to lee-mfd/for-mfd-next groeck-staging/hwmon-next lee-leds/for-leds-next linus/master lee-mfd/for-mfd-fixes v6.11-rc6 v6.11-rc5 v6.11-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Heiko-Stuebner/mfd-core-make-platform_data-pointer-const-in-struct-mfd_cell/20240906-025553
base: next-20240905
patch link: https://lore.kernel.org/r/20240905185232.2899464-2-heiko%40sntech.de
patch subject: [PATCH v7 1/8] mfd: core: make platform_data pointer const in struct mfd_cell
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20240908/202409081514.inB0qj3o-lkp@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 05f5a91d00b02f4369f46d076411c700755ae041)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240908/202409081514.inB0qj3o-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409081514.inB0qj3o-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/hid/hid-sensor-hub.c:8:
In file included from include/linux/hid.h:29:
In file included from include/linux/hid_bpf.h:6:
In file included from include/linux/bpf.h:21:
In file included from include/linux/kallsyms.h:13:
In file included from include/linux/mm.h:2206:
include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
518 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~~~~~~~~~ ^ ~~~
In file included from drivers/hid/hid-sensor-hub.c:8:
In file included from include/linux/hid.h:29:
In file included from include/linux/hid_bpf.h:6:
In file included from include/linux/bpf.h:31:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:26:
In file included from include/linux/kernel_stat.h:8:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:14:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:548:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
548 | val = __raw_readb(PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:561:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
561 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^
In file included from drivers/hid/hid-sensor-hub.c:8:
In file included from include/linux/hid.h:29:
In file included from include/linux/hid_bpf.h:6:
In file included from include/linux/bpf.h:31:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:26:
In file included from include/linux/kernel_stat.h:8:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:14:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:574:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
574 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
| ^
In file included from drivers/hid/hid-sensor-hub.c:8:
In file included from include/linux/hid.h:29:
In file included from include/linux/hid_bpf.h:6:
In file included from include/linux/bpf.h:31:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:26:
In file included from include/linux/kernel_stat.h:8:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:14:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:585:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
585 | __raw_writeb(value, PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:595:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
595 | __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:605:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
605 | __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
>> drivers/hid/hid-sensor-hub.c:744:33: error: initializing 'struct hid_sensor_hub_device *' with an expression of type 'const void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
744 | struct hid_sensor_hub_device *hsdev =
| ^
745 | data->hid_sensor_hub_client_devs[i].platform_data;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7 warnings and 1 error generated.
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3)
Selected by [m]:
- TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y])
vim +744 drivers/hid/hid-sensor-hub.c
401ca24fb34aee srinivas pandruvada 2012-09-05 732
401ca24fb34aee srinivas pandruvada 2012-09-05 733 static void sensor_hub_remove(struct hid_device *hdev)
401ca24fb34aee srinivas pandruvada 2012-09-05 734 {
401ca24fb34aee srinivas pandruvada 2012-09-05 735 struct sensor_hub_data *data = hid_get_drvdata(hdev);
401ca24fb34aee srinivas pandruvada 2012-09-05 736 unsigned long flags;
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 737 int i;
401ca24fb34aee srinivas pandruvada 2012-09-05 738
401ca24fb34aee srinivas pandruvada 2012-09-05 739 hid_dbg(hdev, " hardware removed\n");
401ca24fb34aee srinivas pandruvada 2012-09-05 740 hid_hw_close(hdev);
f2f13a68c37c13 Axel Lin 2012-09-19 741 hid_hw_stop(hdev);
401ca24fb34aee srinivas pandruvada 2012-09-05 742 spin_lock_irqsave(&data->lock, flags);
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 743 for (i = 0; i < data->hid_sensor_client_cnt; ++i) {
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 @744 struct hid_sensor_hub_device *hsdev =
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 745 data->hid_sensor_hub_client_devs[i].platform_data;
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 746 if (hsdev->pending.status)
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 747 complete(&hsdev->pending.ready);
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 748 }
401ca24fb34aee srinivas pandruvada 2012-09-05 749 spin_unlock_irqrestore(&data->lock, flags);
401ca24fb34aee srinivas pandruvada 2012-09-05 750 mfd_remove_devices(&hdev->dev);
401ca24fb34aee srinivas pandruvada 2012-09-05 751 mutex_destroy(&data->mutex);
401ca24fb34aee srinivas pandruvada 2012-09-05 752 }
401ca24fb34aee srinivas pandruvada 2012-09-05 753
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 00/22] iio: use dev_get_platdata() to access platform_data
From: Jonathan Cameron @ 2024-09-07 15:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Michael Hennerich,
Antoniu Miclaus, Jinjie Ruan, Lorenzo Bianconi,
Srinivas Pandruvada, Basavaraj Natikar, linux-input, linux-iio,
linux-kernel, Jiri Kosina, Lars-Peter Clausen
In-Reply-To: <ZtdOB3VRN0QCGWU9@smile.fi.intel.com>
On Tue, 3 Sep 2024 20:57:27 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Sep 03, 2024 at 01:16:45AM +0300, Andy Shevchenko wrote:
> > Unify how IIO drivers access platform_data field of struct device.
> > In simple and straightforward cases constify the local variables.
> >
> > (Not tested)
>
> Jonathan, in case you are fine with the series, feel free to squash, e.g.,
> changes against hid-sensor drivers.
I don't follow, but maybe that will become clear once I've looked
at rest of the stuff I haven't read yet.
Anyhow, applied to the togreg branch of iio.git and pushed out as testing
for all the normal reasons. Another series that will probably be 6.13 material.
Thanks,
Jonathan
>
^ permalink raw reply
* Re: [PATCH v2 0/3] iio: Introduce and use aligned_s64 type
From: Jonathan Cameron @ 2024-09-07 15:37 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Uwe Kleine-König, Jonathan Cameron, Srinivas Pandruvada,
Basavaraj Natikar, linux-input, linux-iio, linux-kernel,
Jiri Kosina, Lars-Peter Clausen, Lorenzo Bianconi
In-Reply-To: <20240903180218.3640501-1-andriy.shevchenko@linux.intel.com>
On Tue, 3 Sep 2024 20:59:03 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> Instead of having open coded idea of aligned member, use
> a newly defined type like it's done in, e.g., u64 case.
> Update a few IIO drivers to show how to use it.
>
> v2 (took only one year from v1, not bad!):
:)
Applied with that tweak for patch 2 that you called out.
Will probably be next cycle though before these go upstream
(so think of this as queuing them up very early for 6.13 :)
> - avoided touching unrelated comments, code lines, etc. (Jonathan)
> - used kernel internal type for the in-kernel code (Jonathan)
>
> Andy Shevchenko (3):
> types: Complement the aligned types with signed 64-bit one
> iio: imu: st_lsm6dsx: Use aligned data type for timestamp
> iio: hid-sensor: Use aligned data type for timestamp
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 2 +-
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +-
> drivers/iio/humidity/hid-sensor-humidity.c | 2 +-
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 3 +--
> drivers/iio/light/hid-sensor-als.c | 2 +-
> drivers/iio/orientation/hid-sensor-incl-3d.c | 2 +-
> drivers/iio/orientation/hid-sensor-rotation.c | 2 +-
> drivers/iio/position/hid-sensor-custom-intel-hinge.c | 2 +-
> drivers/iio/pressure/hid-sensor-press.c | 2 +-
> drivers/iio/temperature/hid-sensor-temperature.c | 2 +-
> include/linux/types.h | 3 ++-
> include/uapi/linux/types.h | 1 +
> 12 files changed, 13 insertions(+), 12 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] treewide: Correct the typo 'retun'
From: Markus Elfring @ 2024-09-07 15:30 UTC (permalink / raw)
To: WangYuli, linux-input, linux-omap, linux-rdma, linux-scsi,
linux-arm-msm, linux-arm-kernel, linux-mtd, dri-devel, freedreno,
Aaro Koskinen, Abhinav Kumar, Abhinav Kumar, Andreas Kemnade,
Andrew Morton, Anil Gurumurthy, Anil Ravindranath, Archit Taneja,
Chandan Uddaraju, Daniel Vetter, Dasaratharaman Chandramouli,
David Airlie, David Woodhouse, Dmitry Baryshkov, Dmitry Torokhov,
Dmitry Torokhov, Don Hiatt, Doug Ledford, Eric Piel,
Gustavo A. R. Silva, Ira Weiny, James Bottomley, James Bottomley,
Jason Gunthorpe, Jiri Kosina, Jeykumar Sankaran, Jordan Crouse,
Kevin Hilman, Krishna Gudipati, Leon Romanovsky, Marijn Suijten,
Martin K. Petersen, Masanari Iida, Miquel Raynal, Miloslav Trmac,
Richard Weinberger, Rob Clark, Roger Quadros, Russell King,
Rajesh Yadav, Sean Paul, Sean Paul, Sravanthi Kollukuduru,
Sudarsana Kalluru, Tony Lindgren, Vignesh Raghavendra,
Vijay Kumar B., Wentao Guan, zhanjun
Cc: LKML
In-Reply-To: <63D0F870EE8E87A0+20240906054008.390188-1-wangyuli@uniontech.com>
…
> should be instead of 'return'.
“return” instead?
Can a corresponding imperative wording be preferred for a better change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.11-rc6#n94
Regards,
Markus
^ permalink raw reply
* [PATCH] HID:replace BUG_ON() with WARN_ON()
From: He Lugang @ 2024-09-07 15:30 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, He Lugang
There is no need to kill the system entirely in HID with BUG_ON,
use WARN_ON to handle fault more gracefully which allow the system
to keep running.
Signed-off-by: He Lugang <helugang@uniontech.com>
---
drivers/hid/hid-cp2112.c | 3 ++-
drivers/hid/hid-lg4ff.c | 3 ++-
drivers/hid/hid-sony.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 20a0d1315d90..03e11f15257f 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -852,7 +852,8 @@ static int cp2112_set_usb_config(struct hid_device *hdev,
{
int ret;
- BUG_ON(cfg->report != CP2112_USB_CONFIG);
+ if (WARN_ON(cfg->report != CP2112_USB_CONFIG))
+ return -EINVAL;
ret = cp2112_hid_output(hdev, (u8 *)cfg, sizeof(*cfg),
HID_FEATURE_REPORT);
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index e3fcf1353fb3..c0a138f21ca4 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -1350,7 +1350,8 @@ int lg4ff_init(struct hid_device *hid)
/* Initialize device properties */
if (mmode_ret == LG4FF_MMODE_IS_MULTIMODE) {
- BUG_ON(mmode_idx == -1);
+ if (WARN_ON(mmode_idx == -1))
+ return -EINVAL;
mmode_wheel = &lg4ff_multimode_wheels[mmode_idx];
}
lg4ff_init_wheel_data(&entry->wdata, &lg4ff_devices[i], mmode_wheel, real_product_id);
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index df29c614e490..c5db29456507 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1379,7 +1379,8 @@ static int sony_leds_init(struct sony_sc *sc)
u8 max_brightness[MAX_LEDS] = { [0 ... (MAX_LEDS - 1)] = 1 };
u8 use_hw_blink[MAX_LEDS] = { 0 };
- BUG_ON(!(sc->quirks & SONY_LED_SUPPORT));
+ if (WARN_ON(!(sc->quirks & SONY_LED_SUPPORT)))
+ return -EINVAL;
if (sc->quirks & BUZZ_CONTROLLER) {
sc->led_count = 4;
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v7 1/8] mfd: core: make platform_data pointer const in struct mfd_cell
From: kernel test robot @ 2024-09-07 12:04 UTC (permalink / raw)
To: Heiko Stuebner, lee
Cc: oe-kbuild-all, robh, krzk+dt, conor+dt, jdelvare, linux, heiko,
dmitry.torokhov, pavel, ukleinek, devicetree, linux-kernel,
linux-hwmon, linux-arm-kernel, linux-rockchip, linux-input,
linux-leds
In-Reply-To: <20240905185232.2899464-2-heiko@sntech.de>
Hi Heiko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20240905]
[also build test WARNING on v6.11-rc6]
[cannot apply to lee-mfd/for-mfd-next groeck-staging/hwmon-next lee-leds/for-leds-next linus/master lee-mfd/for-mfd-fixes v6.11-rc6 v6.11-rc5 v6.11-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Heiko-Stuebner/mfd-core-make-platform_data-pointer-const-in-struct-mfd_cell/20240906-025553
base: next-20240905
patch link: https://lore.kernel.org/r/20240905185232.2899464-2-heiko%40sntech.de
patch subject: [PATCH v7 1/8] mfd: core: make platform_data pointer const in struct mfd_cell
config: arm-randconfig-001-20240907 (https://download.01.org/0day-ci/archive/20240907/202409071933.IYm8oa1N-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240907/202409071933.IYm8oa1N-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409071933.IYm8oa1N-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_remove':
>> drivers/hid/hid-sensor-hub.c:745:25: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
745 | data->hid_sensor_hub_client_devs[i].platform_data;
| ^~~~
vim +/const +745 drivers/hid/hid-sensor-hub.c
401ca24fb34aee srinivas pandruvada 2012-09-05 732
401ca24fb34aee srinivas pandruvada 2012-09-05 733 static void sensor_hub_remove(struct hid_device *hdev)
401ca24fb34aee srinivas pandruvada 2012-09-05 734 {
401ca24fb34aee srinivas pandruvada 2012-09-05 735 struct sensor_hub_data *data = hid_get_drvdata(hdev);
401ca24fb34aee srinivas pandruvada 2012-09-05 736 unsigned long flags;
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 737 int i;
401ca24fb34aee srinivas pandruvada 2012-09-05 738
401ca24fb34aee srinivas pandruvada 2012-09-05 739 hid_dbg(hdev, " hardware removed\n");
401ca24fb34aee srinivas pandruvada 2012-09-05 740 hid_hw_close(hdev);
f2f13a68c37c13 Axel Lin 2012-09-19 741 hid_hw_stop(hdev);
401ca24fb34aee srinivas pandruvada 2012-09-05 742 spin_lock_irqsave(&data->lock, flags);
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 743 for (i = 0; i < data->hid_sensor_client_cnt; ++i) {
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 744 struct hid_sensor_hub_device *hsdev =
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 @745 data->hid_sensor_hub_client_devs[i].platform_data;
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 746 if (hsdev->pending.status)
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 747 complete(&hsdev->pending.ready);
e651a1da442ae0 Srinivas Pandruvada 2015-02-19 748 }
401ca24fb34aee srinivas pandruvada 2012-09-05 749 spin_unlock_irqrestore(&data->lock, flags);
401ca24fb34aee srinivas pandruvada 2012-09-05 750 mfd_remove_devices(&hdev->dev);
401ca24fb34aee srinivas pandruvada 2012-09-05 751 mutex_destroy(&data->mutex);
401ca24fb34aee srinivas pandruvada 2012-09-05 752 }
401ca24fb34aee srinivas pandruvada 2012-09-05 753
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* hid-lenovo breaks middle mouse button on tpIIkbd
From: Harald Welte @ 2024-09-07 10:18 UTC (permalink / raw)
To: ValdikSS; +Cc: linux-input
Dear ValdikSS,
Dear Linux Input maintainers,
I've recently acquired a brand new tpIIkbd (ThinkPad TrackPoint Keyboard II)
which I use via bloetooth. Sadly, the center mouse button never worked and
I finally got to try to debug what's going on here.
The keyboard has a small slider swithc to select between Android and
Windows mode. I've set it to "windows" mode, but couldn't observe any
difference in the bug in both modes.
The keyboard shows up as /sys/kernel/debug/hid/0005:17EF:60E1.000F
== btmon
* the events are visible on bluetooth with "BTMON". Middle mouse button
press+release looks like this:
> ACL Data RX: Handle 10 flags 0x02 dlen 11 #32 [hci0] 14.353057
ATT: Handle Value Notification (0x1b) len 6
Handle: 0x001c
Data[4]: 04000000
> ACL Data RX: Handle 10 flags 0x02 dlen 11 #33 [hci0] 15.357078
ATT: Handle Value Notification (0x1b) len 6
Handle: 0x001c
Data[4]: 00000000
== bluetoothd
* bluetoothd is feeding those into uhid (I checked this via strace,
looks like this:
read(30, "\x1b\x1c\x00\x04\x00\x00\x00", 23) = 7
writev(33, [{iov_base="\x0c\x00\x00\x00\x05\x00\x02\x04\x00 ...
where '30' is the L2CAP socket and '33' is the /dev/uhid device
== /sys/kernel/debug/hid/*/event
/sys/kernel/debug/hid/*/event:
report (size 5) (numbered) = 02 04 00 00 00
Button.0001 = 0
Button.0002 = 0
Button.0003 = 1
GenericDesktop.X = 0
GenericDesktop.Y = 0
GenericDesktop.Wheel = 0
== evtest
However, evtest shows exactly nothing when the centre button is pressed
or depressed. It works just fine for left and right button.
so somehow the events that look perfectly valid on btmon and as HID event
are lost between /dev/uhid and /dev/event*
When I rmmod the hid-lenovo module, it suddenly starts working and the
evnets are showing up in evtest (and I can start to paste the buffer
with the center button like on any other mouse/trackpad).
There are some BTN_MIDDLE quirks/workarounds in hid-lenovo.c that I don't
understand (I'm not a HID or linux input expert at all). But my best
guess at this point is that either that code is broken, or Lenovo has
released a new version of that keyboard [or its firmware] which doesn't
need the workaround designed for earlier versions?
Having the module loaded but doing
echo 0 > /sys/devices/virtual/misc/uhid/0005:17EF:60E1.000F/middleclick_workaround
will *not* fix the bug. The middle button is not working for both 1 or
0 in that middleclick_workaround file.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH 20/22] Input: regulator-haptic - use guard notation when acquiring mutex
From: kernel test robot @ 2024-09-07 3:40 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: oe-kbuild-all, Michael Hennerich, Ville Syrjala,
Support Opensource, Eddie James, Andrey Moiseev, Hans de Goede,
Javier Carrasco, Jeff LaBundy, linux-kernel
In-Reply-To: <20240904044922.1049488-1-dmitry.torokhov@gmail.com>
Hi Dmitry,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus hid/for-next linus/master v6.11-rc6 next-20240906]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Dmitry-Torokhov/Input-ad714x-use-guard-notation-when-acquiring-mutex/20240905-085752
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240904044922.1049488-1-dmitry.torokhov%40gmail.com
patch subject: [PATCH 20/22] Input: regulator-haptic - use guard notation when acquiring mutex
config: x86_64-buildonly-randconfig-001-20240907 (https://download.01.org/0day-ci/archive/20240907/202409071004.IhekZKbM-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240907/202409071004.IhekZKbM-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409071004.IhekZKbM-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/input/misc/regulator-haptic.c: In function 'regulator_haptic_suspend':
>> drivers/input/misc/regulator-haptic.c:206:13: warning: unused variable 'error' [-Wunused-variable]
206 | int error;
| ^~~~~
vim +/error +206 drivers/input/misc/regulator-haptic.c
d64cb71bede87d Jaewon Kim 2014-12-17 201
1a3e6c1ee47d00 Jonathan Cameron 2023-01-02 202 static int regulator_haptic_suspend(struct device *dev)
d64cb71bede87d Jaewon Kim 2014-12-17 203 {
d64cb71bede87d Jaewon Kim 2014-12-17 204 struct platform_device *pdev = to_platform_device(dev);
d64cb71bede87d Jaewon Kim 2014-12-17 205 struct regulator_haptic *haptic = platform_get_drvdata(pdev);
d64cb71bede87d Jaewon Kim 2014-12-17 @206 int error;
d64cb71bede87d Jaewon Kim 2014-12-17 207
aaa0758ff6b5c4 Dmitry Torokhov 2024-09-03 208 scoped_guard(mutex_intr, &haptic->mutex) {
d64cb71bede87d Jaewon Kim 2014-12-17 209 regulator_haptic_set_voltage(haptic, 0);
d64cb71bede87d Jaewon Kim 2014-12-17 210 haptic->suspended = true;
d64cb71bede87d Jaewon Kim 2014-12-17 211
d64cb71bede87d Jaewon Kim 2014-12-17 212 return 0;
d64cb71bede87d Jaewon Kim 2014-12-17 213 }
d64cb71bede87d Jaewon Kim 2014-12-17 214
aaa0758ff6b5c4 Dmitry Torokhov 2024-09-03 215 return -EINTR;
aaa0758ff6b5c4 Dmitry Torokhov 2024-09-03 216 }
aaa0758ff6b5c4 Dmitry Torokhov 2024-09-03 217
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 4172a64ef2c4c519a67037fc4edc78277f786fee
From: kernel test robot @ 2024-09-07 0:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 4172a64ef2c4c519a67037fc4edc78277f786fee Input: zforce_ts - switch to using asynchronous probing
Warning ids grouped by kconfigs:
recent_errors
`-- x86_64-allnoconfig
`-- drivers-input-keyboard-matrix_keypad.c:linux-gpio-consumer.h-is-included-more-than-once.
elapsed time: 1054m
configs tested: 134
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm defconfig gcc-14.1.0
arm neponset_defconfig clang-15
arm pxa168_defconfig clang-15
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240906 gcc-12
i386 buildonly-randconfig-002-20240906 gcc-12
i386 buildonly-randconfig-003-20240906 gcc-12
i386 buildonly-randconfig-004-20240906 gcc-12
i386 buildonly-randconfig-005-20240906 gcc-12
i386 buildonly-randconfig-006-20240906 gcc-12
i386 defconfig clang-18
i386 randconfig-001-20240906 gcc-12
i386 randconfig-002-20240906 gcc-12
i386 randconfig-003-20240906 gcc-12
i386 randconfig-004-20240906 gcc-12
i386 randconfig-005-20240906 gcc-12
i386 randconfig-006-20240906 gcc-12
i386 randconfig-011-20240906 gcc-12
i386 randconfig-012-20240906 gcc-12
i386 randconfig-013-20240906 gcc-12
i386 randconfig-014-20240906 gcc-12
i386 randconfig-015-20240906 gcc-12
i386 randconfig-016-20240906 gcc-12
loongarch alldefconfig clang-15
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k atari_defconfig clang-15
m68k defconfig gcc-14.1.0
m68k m5407c3_defconfig clang-15
m68k m5475evb_defconfig clang-15
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips vocore2_defconfig clang-15
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc64 defconfig gcc-14.1.0
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc cm5200_defconfig clang-15
powerpc eiger_defconfig clang-15
powerpc iss476-smp_defconfig clang-15
powerpc ps3_defconfig clang-15
powerpc tqm8555_defconfig clang-15
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
riscv nommu_k210_sdcard_defconfig clang-15
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh j2_defconfig clang-15
sh se7750_defconfig clang-15
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig clang-15
um i386_defconfig gcc-12
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240907 gcc-12
x86_64 buildonly-randconfig-002-20240907 gcc-12
x86_64 buildonly-randconfig-003-20240907 gcc-12
x86_64 buildonly-randconfig-004-20240907 gcc-12
x86_64 buildonly-randconfig-005-20240907 gcc-12
x86_64 buildonly-randconfig-006-20240907 gcc-12
x86_64 defconfig clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240907 gcc-12
x86_64 randconfig-002-20240907 gcc-12
x86_64 randconfig-003-20240907 gcc-12
x86_64 randconfig-004-20240907 gcc-12
x86_64 randconfig-005-20240907 gcc-12
x86_64 randconfig-006-20240907 gcc-12
x86_64 randconfig-011-20240907 gcc-12
x86_64 randconfig-012-20240907 gcc-12
x86_64 randconfig-013-20240907 gcc-12
x86_64 randconfig-014-20240907 gcc-12
x86_64 randconfig-015-20240907 gcc-12
x86_64 randconfig-016-20240907 gcc-12
x86_64 randconfig-071-20240907 gcc-12
x86_64 randconfig-072-20240907 gcc-12
x86_64 randconfig-073-20240907 gcc-12
x86_64 randconfig-074-20240907 gcc-12
x86_64 randconfig-075-20240907 gcc-12
x86_64 randconfig-076-20240907 gcc-12
x86_64 rhel-8.3-rust clang-18
x86_64 rhel-8.3 gcc-12
xtensa allnoconfig gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS e06edf96dea065dd1d9df695bf8b92784992333e
From: kernel test robot @ 2024-09-07 0:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: e06edf96dea065dd1d9df695bf8b92784992333e Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table
elapsed time: 1054m
configs tested: 134
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm defconfig gcc-14.1.0
arm neponset_defconfig clang-15
arm pxa168_defconfig clang-15
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240906 gcc-12
i386 buildonly-randconfig-002-20240906 gcc-12
i386 buildonly-randconfig-003-20240906 gcc-12
i386 buildonly-randconfig-004-20240906 gcc-12
i386 buildonly-randconfig-005-20240906 gcc-12
i386 buildonly-randconfig-006-20240906 gcc-12
i386 defconfig clang-18
i386 randconfig-001-20240906 gcc-12
i386 randconfig-002-20240906 gcc-12
i386 randconfig-003-20240906 gcc-12
i386 randconfig-004-20240906 gcc-12
i386 randconfig-005-20240906 gcc-12
i386 randconfig-006-20240906 gcc-12
i386 randconfig-011-20240906 gcc-12
i386 randconfig-012-20240906 gcc-12
i386 randconfig-013-20240906 gcc-12
i386 randconfig-014-20240906 gcc-12
i386 randconfig-015-20240906 gcc-12
i386 randconfig-016-20240906 gcc-12
loongarch alldefconfig clang-15
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k atari_defconfig clang-15
m68k defconfig gcc-14.1.0
m68k m5407c3_defconfig clang-15
m68k m5475evb_defconfig clang-15
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips vocore2_defconfig clang-15
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc64 defconfig gcc-14.1.0
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc cm5200_defconfig clang-15
powerpc eiger_defconfig clang-15
powerpc iss476-smp_defconfig clang-15
powerpc ps3_defconfig clang-15
powerpc tqm8555_defconfig clang-15
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
riscv nommu_k210_sdcard_defconfig clang-15
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh j2_defconfig clang-15
sh se7750_defconfig clang-15
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig clang-15
um i386_defconfig gcc-12
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240907 gcc-12
x86_64 buildonly-randconfig-002-20240907 gcc-12
x86_64 buildonly-randconfig-003-20240907 gcc-12
x86_64 buildonly-randconfig-004-20240907 gcc-12
x86_64 buildonly-randconfig-005-20240907 gcc-12
x86_64 buildonly-randconfig-006-20240907 gcc-12
x86_64 defconfig clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240907 gcc-12
x86_64 randconfig-002-20240907 gcc-12
x86_64 randconfig-003-20240907 gcc-12
x86_64 randconfig-004-20240907 gcc-12
x86_64 randconfig-005-20240907 gcc-12
x86_64 randconfig-006-20240907 gcc-12
x86_64 randconfig-011-20240907 gcc-12
x86_64 randconfig-012-20240907 gcc-12
x86_64 randconfig-013-20240907 gcc-12
x86_64 randconfig-014-20240907 gcc-12
x86_64 randconfig-015-20240907 gcc-12
x86_64 randconfig-016-20240907 gcc-12
x86_64 randconfig-071-20240907 gcc-12
x86_64 randconfig-072-20240907 gcc-12
x86_64 randconfig-073-20240907 gcc-12
x86_64 randconfig-074-20240907 gcc-12
x86_64 randconfig-075-20240907 gcc-12
x86_64 randconfig-076-20240907 gcc-12
x86_64 rhel-8.3-rust clang-18
x86_64 rhel-8.3 gcc-12
xtensa allnoconfig gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:ib/6.11-rc6-matrix-keypad-spitz] BUILD SUCCESS de35996d4b364749194c5b473d1912578880833e
From: kernel test robot @ 2024-09-06 22:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/6.11-rc6-matrix-keypad-spitz
branch HEAD: de35996d4b364749194c5b473d1912578880833e Input: matrix_keypad - remove support for platform data
elapsed time: 1011m
configs tested: 134
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm defconfig gcc-14.1.0
arm neponset_defconfig clang-15
arm pxa168_defconfig clang-15
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240906 gcc-12
i386 buildonly-randconfig-002-20240906 gcc-12
i386 buildonly-randconfig-003-20240906 gcc-12
i386 buildonly-randconfig-004-20240906 gcc-12
i386 buildonly-randconfig-005-20240906 gcc-12
i386 buildonly-randconfig-006-20240906 gcc-12
i386 defconfig clang-18
i386 randconfig-001-20240906 gcc-12
i386 randconfig-002-20240906 gcc-12
i386 randconfig-003-20240906 gcc-12
i386 randconfig-004-20240906 gcc-12
i386 randconfig-005-20240906 gcc-12
i386 randconfig-006-20240906 gcc-12
i386 randconfig-011-20240906 gcc-12
i386 randconfig-012-20240906 gcc-12
i386 randconfig-013-20240906 gcc-12
i386 randconfig-014-20240906 gcc-12
i386 randconfig-015-20240906 gcc-12
i386 randconfig-016-20240906 gcc-12
loongarch alldefconfig clang-15
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k atari_defconfig clang-15
m68k defconfig gcc-14.1.0
m68k m5407c3_defconfig clang-15
m68k m5475evb_defconfig clang-15
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips vocore2_defconfig clang-15
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc64 defconfig gcc-14.1.0
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc cm5200_defconfig clang-15
powerpc eiger_defconfig clang-15
powerpc iss476-smp_defconfig clang-15
powerpc ps3_defconfig clang-15
powerpc tqm8555_defconfig clang-15
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
riscv nommu_k210_sdcard_defconfig clang-15
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh j2_defconfig clang-15
sh se7750_defconfig clang-15
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig clang-15
um i386_defconfig gcc-12
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240907 gcc-12
x86_64 buildonly-randconfig-002-20240907 gcc-12
x86_64 buildonly-randconfig-003-20240907 gcc-12
x86_64 buildonly-randconfig-004-20240907 gcc-12
x86_64 buildonly-randconfig-005-20240907 gcc-12
x86_64 buildonly-randconfig-006-20240907 gcc-12
x86_64 defconfig clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240907 gcc-12
x86_64 randconfig-002-20240907 gcc-12
x86_64 randconfig-003-20240907 gcc-12
x86_64 randconfig-004-20240907 gcc-12
x86_64 randconfig-005-20240907 gcc-12
x86_64 randconfig-006-20240907 gcc-12
x86_64 randconfig-011-20240907 gcc-12
x86_64 randconfig-012-20240907 gcc-12
x86_64 randconfig-013-20240907 gcc-12
x86_64 randconfig-014-20240907 gcc-12
x86_64 randconfig-015-20240907 gcc-12
x86_64 randconfig-016-20240907 gcc-12
x86_64 randconfig-071-20240907 gcc-12
x86_64 randconfig-072-20240907 gcc-12
x86_64 randconfig-073-20240907 gcc-12
x86_64 randconfig-074-20240907 gcc-12
x86_64 randconfig-075-20240907 gcc-12
x86_64 randconfig-076-20240907 gcc-12
x86_64 rhel-8.3-rust clang-18
x86_64 rhel-8.3 gcc-12
xtensa allnoconfig gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v7 2/2] dt-bindings: input: Goodix SPI HID Touchscreen
From: Rob Herring @ 2024-09-06 20:28 UTC (permalink / raw)
To: Charles Wang
Cc: dmitry.torokhov, dianders, dan.carpenter, conor, krzk+dt, jikos,
bentiss, hbarnor, linux-input, devicetree, linux-kernel,
Conor Dooley
In-Reply-To: <20240814024513.164199-3-charles.goodix@gmail.com>
On Tue, Aug 13, 2024 at 9:45 PM Charles Wang <charles.goodix@gmail.com> wrote:
>
> The Goodix GT7986U touch controller report touch data according to the
> HID protocol through the SPI bus. However, it is incompatible with
> Microsoft's HID-over-SPI protocol.
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Charles Wang <charles.goodix@gmail.com>
> ---
> .../bindings/input/goodix,gt7986u.yaml | 71 +++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/goodix,gt7986u.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml b/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml
> new file mode 100644
> index 000000000..a7d42a5d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/goodix,gt7986u.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/goodix,gt7986u.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GOODIX GT7986U SPI HID Touchscreen
> +
> +maintainers:
> + - Charles Wang <charles.goodix@gmail.com>
> +
> +description: Supports the Goodix GT7986U touchscreen.
> + This touch controller reports data packaged according to the HID protocol,
> + but is incompatible with Microsoft's HID-over-SPI protocol.
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - goodix,gt7986u
This is already documented in goodix,gt7375p.yaml. Now linux-next has warnings:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/input/goodix,gt7986u.example.dtb:
touchscreen@0: compatible: 'oneOf' conditional failed, one must be
fixed:
['goodix,gt7986u'] is too short
'goodix,gt7375p' was expected
from schema $id:
http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/input/goodix,gt7986u.example.dtb:
touchscreen@0: reg:0:0: 0 is not one of [93, 20]
from schema $id:
http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/input/goodix,gt7986u.example.dtb:
touchscreen@0: 'vdd-supply' is a required property
from schema $id:
http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/input/goodix,gt7986u.example.dtb:
touchscreen@0: 'goodix,hid-report-addr', 'spi-max-frequency' do not
match any of the regexes: 'pinctrl-[0-9]+'
from schema $id:
http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
Please sort this out and send a fix.
Rob
^ permalink raw reply
* Re: [PATCH] Input: keypad-nomadik-ske - remove the driver
From: Dmitry Torokhov @ 2024-09-06 16:51 UTC (permalink / raw)
To: Nuno Sá
Cc: Arnd Bergmann, Michael Hennerich, Linus Walleij, linux-input,
linux-kernel, Lee Jones, linux-arm-kernel, Utsav Agarwal
In-Reply-To: <9db96c99c805e615ba40ca7fd3632174d1e8d11f.camel@gmail.com>
Hi Nuno,
On Fri, Sep 06, 2024 at 10:38:35AM +0200, Nuno Sá wrote:
>
> Hi Dmitry,
>
> This is not forgotten and I plan to start working on this early next week.
>
> One thing I noticed and I might as well just ask before starting the work, is that
> the platform data allows, in theory, for you to have holes in your keymap [1]. Like
> enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of
> the box as we just define the number of rows/cols and then without any other property
> we assume (I think) that the map is contiguous.
>
> This is just early thinking but one way to support the current behavior would be 2
> custom DT properties that would be 2 u32 arrays specifying the enabled columns and
> rows. Out of it, we could build row and col masks and get the total number of cols
> and rows that we could pass to matrix_keypad_build_keymap().
I'd ask DT maintainers but in my opinion we could add 2 u32 scalar
properties to specify row and col masks (either enabled or disabled,
whatever is more convenient) and then indeed we could figure out the
resulting size of key matrix and use matrix_keypad_build_keymap() to
load it.
>
> The question is... is it worth it? I'm aware that if we just assume a contiguous
> keymap we could break some old users. But I guess it would be only out of tree ones
> as we don't have any in kernel user of the platform data. On top of it, I guess it's
> sane to assume that one just wants a contiguous keymap...
>
> [1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630
I think in practice it's just a few extra lines of code, so shoudl be
fairly easy to keep supporting this.
But we can actually split the binding and the driver implementation,
with binding defining all capabilities of the hardware and driver
implementing just a subset of it (i.e. complain if row and column mask
properties are specified and abort probe).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: keypad-nomadik-ske - remove the driver
From: Nuno Sá @ 2024-09-06 8:38 UTC (permalink / raw)
To: Dmitry Torokhov, Arnd Bergmann, Michael Hennerich
Cc: Linus Walleij, linux-input, linux-kernel, Lee Jones,
linux-arm-kernel, Utsav Agarwal
In-Reply-To: <ZsNcpom_Fm5uCyEj@google.com>
On Mon, 2024-08-19 at 07:54 -0700, Dmitry Torokhov wrote:
> On Mon, Aug 19, 2024 at 11:29:32AM +0200, Arnd Bergmann wrote:
> > On Fri, Aug 16, 2024, at 20:54, Dmitry Torokhov wrote:
> > > The users of this driver were removed in 2013 in commit 28633c54bda6
> > > ("ARM: ux500: Rip out keypad initialisation which is no longer used").
> > >
> > > Remove the driver as well.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > > drivers/input/keyboard/Kconfig | 11 -
> > > drivers/input/keyboard/Makefile | 1 -
> > > drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------
> > > .../linux/platform_data/keypad-nomadik-ske.h | 50 ---
> > > 4 files changed, 440 deletions(-)
> > >
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > I have a list of drivers that I determined to be likely
> > unused as well and found a few more input drivers
> > that were unused in 2022:
> >
> > CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520
> > CONFIG_KEYBOARD_ADP5589
> > CONFIG_INPUT_AD714X
> > CONFIG_TOUCHSCREEN_AD7877
> >
> > As far as I can tell, these all lost their last device
> > definition, or they never had one and are impossible to
> > be used with device tree data.
>
> I asked Analog Devices folks (CCed) about 5589 and Nuno said that it is
> still relevant and promised to do conversion to DT similar to adp5588.
>
> Nuno, Michale, what about the other drivers that Arnd listed?
>
Hi Dmitry,
This is not forgotten and I plan to start working on this early next week.
One thing I noticed and I might as well just ask before starting the work, is that
the platform data allows, in theory, for you to have holes in your keymap [1]. Like
enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of
the box as we just define the number of rows/cols and then without any other property
we assume (I think) that the map is contiguous.
This is just early thinking but one way to support the current behavior would be 2
custom DT properties that would be 2 u32 arrays specifying the enabled columns and
rows. Out of it, we could build row and col masks and get the total number of cols
and rows that we could pass to matrix_keypad_build_keymap().
The question is... is it worth it? I'm aware that if we just assume a contiguous
keymap we could break some old users. But I guess it would be only out of tree ones
as we don't have any in kernel user of the platform data. On top of it, I guess it's
sane to assume that one just wants a contiguous keymap...
[1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630
Thanks!
- Nuno Sá
^ 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