* Re: [PATCH] HID: amd_sfh: Stop sensor before starting
From: Jiri Kosina @ 2025-10-30 10:59 UTC (permalink / raw)
To: Mario Limonciello (AMD)
Cc: mario.limonciello, basavaraj.natikar, bentiss, stable, Titas,
linux-input
In-Reply-To: <20251020155101.3905957-1-superm1@kernel.org>
On Mon, 20 Oct 2025, Mario Limonciello (AMD) wrote:
> Titas reports that the accelerometer sensor on their laptop only
> works after a warm boot or unloading/reloading the amd-sfh kernel
> module.
>
> Presumably the sensor is in a bad state on cold boot and failing to
> start, so explicitly stop it before starting.
>
> Cc: stable@vger.kernel.org
> Fixes: 93ce5e0231d79 ("HID: amd_sfh: Implement SFH1.1 functionality")
> Reported-by: Titas <novatitas366@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220670
> Tested-by: Titas <novatitas366@gmail.com>
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list
From: Jiri Kosina @ 2025-10-30 10:56 UTC (permalink / raw)
To: April Grimoire; +Cc: linux-input, linux-kernel
In-Reply-To: <20251022163726.19667-1-april@aprilg.moe>
On Thu, 23 Oct 2025, April Grimoire wrote:
> SONiX AK870 PRO keyboard pretends to be an apple keyboard by VID:PID,
> rendering function keys not treated properly. Despite being a
> SONiX USB DEVICE, it uses a different name, so adding it to the list.
>
> Signed-off-by: April Grimoire <april@aprilg.moe>
> ---
> drivers/hid/hid-apple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index 61404d7a4..57da4f86a 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -355,6 +355,7 @@ static const struct apple_key_translation swapped_fn_leftctrl_keys[] = {
>
> static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
> { "SONiX USB DEVICE" },
> + { "SONiX AK870 PRO" },
> { "Keychron" },
> { "AONE" },
> { "GANSS" },
Appplied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc
From: Jiri Kosina @ 2025-10-30 10:41 UTC (permalink / raw)
To: Lauri Tirkkonen; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <aPM1I35YXWlabuKQ@mail.hacktheplanet.fi>
On Sat, 18 Oct 2025, Lauri Tirkkonen wrote:
> The keyboard of this device has the following in its report description
> for Usage (Keyboard) in Collection (Application):
>
> # 0x15, 0x00, // Logical Minimum (0) 52
> # 0x25, 0x65, // Logical Maximum (101) 54
> # 0x05, 0x07, // Usage Page (Keyboard) 56
> # 0x19, 0x00, // Usage Minimum (0) 58
> # 0x29, 0xdd, // Usage Maximum (221) 60
> # 0x81, 0x00, // Input (Data,Arr,Abs) 62
>
> Since the Usage Min/Max range exceeds the Logical Min/Max range,
> keypresses outside the Logical range are not recognized. This includes,
> for example, the Japanese language keyboard variant's keys for |, _ and
> \.
>
> Fixup the report description to make the Logical range match the Usage
> range, fixing the interpretation of keypresses above 101 on this device.
>
> Signed-off-by: Lauri Tirkkonen <lauri@hacktheplanet.fi>
> ---
> v1 -> v2: moved to hid-lenovo from hid-i2c, renamed hid-ids macro to
> clarify the device only refers to the keyboard
>
> v1: https://lore.kernel.org/all/aOdLxAEYQpV2zp77@mail.hacktheplanet.fi/
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/1] HID: intel-thc-hid: Remove redundant pm_runtime_mark_last_busy() calls
From: Jiri Kosina @ 2025-10-30 10:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-input, Even Xu, Xinpeng Sun, Benjamin Tissoires,
Srinivas Pandruvada, Mark Pearson, Philipp Stanner, Wentao Guan,
Abhishek Tamboli
In-Reply-To: <20251027120123.391125-1-sakari.ailus@linux.intel.com>
On Mon, 27 Oct 2025, Sakari Ailus wrote:
> pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
> pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
> to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
> pm_runtime_mark_last_busy().
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4] HID: quirks: Change manufacturer for 4c4a:4155
From: Jiri Kosina @ 2025-10-30 10:24 UTC (permalink / raw)
To: zhangheng
Cc: Terry Junge, bentiss, staffan.melin, linux-input, linux-kernel,
1114557, stable
In-Reply-To: <e765d91f-3c00-4dc5-ac24-68a5512a0c12@kylinos.cn>
I have updated the shortlog to be a little bit more descriptive and
applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] HID: nintendo: Reduce JC_SUBCMD_RATE_MAX_ATTEMPTS
From: Willy Huang @ 2025-10-30 6:37 UTC (permalink / raw)
To: Daniel J . Ogorchock, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Willy Huang
The JC_SUBCMD_RATE_MAX_ATTEMPTS constant is currently set to 500.
In a worst-case scenario where all attempts consistently fail, this could
cause the loop to block for up to 60000 ms (500 * 60ms * 2, including the
additional retry after a timeout).
This change lowers the maximum potential blocking time to 3000 ms
(25 * 60ms * 2), improving system responsiveness and efficiency.
Signed-off-by: Willy Huang <willyhuang@google.com>
---
drivers/hid/hid-nintendo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index c2849a541f65..342cd6893502 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -819,7 +819,7 @@ static void joycon_wait_for_input_report(struct joycon_ctlr *ctlr)
#define JC_INPUT_REPORT_MAX_DELTA 17
#define JC_SUBCMD_TX_OFFSET_MS 4
#define JC_SUBCMD_VALID_DELTA_REQ 3
-#define JC_SUBCMD_RATE_MAX_ATTEMPTS 500
+#define JC_SUBCMD_RATE_MAX_ATTEMPTS 25
#define JC_SUBCMD_RATE_LIMITER_USB_MS 20
#define JC_SUBCMD_RATE_LIMITER_BT_MS 60
#define JC_SUBCMD_RATE_LIMITER_MS(ctlr) ((ctlr)->hdev->bus == BUS_USB ? JC_SUBCMD_RATE_LIMITER_USB_MS : JC_SUBCMD_RATE_LIMITER_BT_MS)
--
2.51.1.851.g4ebd6896fd-goog
^ permalink raw reply related
* Re: [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads
From: Randy Dunlap @ 2025-10-30 1:35 UTC (permalink / raw)
To: Peter Hutterer, Jonathan Denose, Jiri Kosina, Benjamin Tissoires,
Dmitry Torokhov, Jonathan Corbet, Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien
In-Reply-To: <20251030011735.GA969565@quokka>
Hi,
On 10/29/25 6:17 PM, Peter Hutterer wrote:
> Definition: "pressure pad" used here as all touchpads that use physical
> pressure to convert to click without physical hinges. Also called haptic
> touchpads in general parlance, Synaptics calls them ForcePads.
>
> Most (all?) pressure pads are currently advertised as
> INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads
> by defining the resolution on ABS_MT_PRESSURE has been in the docs since
> commit 20ccc8dd38a3 ("Documentation: input: define
> ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices
> provide this information.
>
> In userspace it's thus impossible to determine whether a device is a
> true pressure pad (pressure equals pressure) or a normal clickpad with
> (pressure equals finger size).
>
> Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces
> INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that
> have support for userspace-controlled effects. Let's expand that
> definition to include all haptic touchpads (pressure pads) since those
> that do support FF effects can be identified by the presence of the
> FF_HAPTIC bit.
>
> This means:
> - clickpad: INPUT_PROP_BUTTONPAD
> - pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD
> - pressurepad with haptics:
> INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD + FF_HAPTIC
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
>
> Original patch series: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#m20ec992705f449f9d9758e0080622cfae1c90660
> See my comment there: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#u
>
> My motivation is that we need something to identify pressurepads that
> do not expose actual haptic feedback configuration. Right now we're
> adding quirks for each device in libinput but that doesn't scale and
> HID defines Usage Page 0x0D Usage 0x55 [1] to tell us whether the form
> factor is a pressurepad, we're just not using it (yet).
>
> I don't think adding a separate INPUT_PROP_PRESSUREPAD is the right
> thing to do - HAPTIC_TOUCHPAD is good enough since presence of the
> FF_HAPTICS bit indicates that it is controllable.
>
> [1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report
>
>
> Documentation/input/event-codes.rst | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git ./Documentation/input/event-codes.rst ../Documentation/input/event-codes.rst
> index 1ead9bb8d9c6..304d11297d3f 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -403,16 +403,25 @@ regular directional axes and accelerometer axes on the same event node.
> INPUT_PROP_HAPTIC_TOUCHPAD
> --------------------------
>
> -The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
> -- supports simple haptic auto and manual triggering
> +The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that the device provides
> +simulated haptic feedback (e.g. a vibrator motor situated below the surface)
> +instead of physical haptic feedback (e.g. a hinge). This property is only set
> +if the device:
> - can differentiate between at least 5 fingers
> - uses correct resolution for the X/Y (units and value)
> -- reports correct force per touch, and correct units for them (newtons or grams)
> - follows the MT protocol type B
Looks reasonable to me. But the list above and the one below
are not rendered as lists in html. It would be nice to convert
them to lists.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
> +If the simulated haptic feedback is controllable by userspace the device must:
> +- support simple haptic auto and manual triggering, and
> +- report correct force per touch, and correct units for them (newtons or grams), and
> +- provide the EV_FF FF_HAPTIC force feedback effect.
> +
> Summing up, such devices follow the MS spec for input devices in
> -Win8 and Win8.1, and in addition support the Simple haptic controller HID table,
> -and report correct units for the pressure.
> +Win8 and Win8.1, and in addition may support the Simple haptic controller HID
> +table, and report correct units for the pressure.
> +
> +Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
> +does not replace that property.
>
> Guidelines
> ==========
--
~Randy
^ permalink raw reply
* [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads
From: Peter Hutterer @ 2025-10-30 1:17 UTC (permalink / raw)
To: Jonathan Denose, Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov,
Jonathan Corbet, Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien, Jonathan Denose
Definition: "pressure pad" used here as all touchpads that use physical
pressure to convert to click without physical hinges. Also called haptic
touchpads in general parlance, Synaptics calls them ForcePads.
Most (all?) pressure pads are currently advertised as
INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads
by defining the resolution on ABS_MT_PRESSURE has been in the docs since
commit 20ccc8dd38a3 ("Documentation: input: define
ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices
provide this information.
In userspace it's thus impossible to determine whether a device is a
true pressure pad (pressure equals pressure) or a normal clickpad with
(pressure equals finger size).
Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces
INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that
have support for userspace-controlled effects. Let's expand that
definition to include all haptic touchpads (pressure pads) since those
that do support FF effects can be identified by the presence of the
FF_HAPTIC bit.
This means:
- clickpad: INPUT_PROP_BUTTONPAD
- pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD
- pressurepad with haptics:
INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD + FF_HAPTIC
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
Original patch series: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#m20ec992705f449f9d9758e0080622cfae1c90660
See my comment there: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#u
My motivation is that we need something to identify pressurepads that
do not expose actual haptic feedback configuration. Right now we're
adding quirks for each device in libinput but that doesn't scale and
HID defines Usage Page 0x0D Usage 0x55 [1] to tell us whether the form
factor is a pressurepad, we're just not using it (yet).
I don't think adding a separate INPUT_PROP_PRESSUREPAD is the right
thing to do - HAPTIC_TOUCHPAD is good enough since presence of the
FF_HAPTICS bit indicates that it is controllable.
[1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report
Documentation/input/event-codes.rst | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git ./Documentation/input/event-codes.rst ../Documentation/input/event-codes.rst
index 1ead9bb8d9c6..304d11297d3f 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -403,16 +403,25 @@ regular directional axes and accelerometer axes on the same event node.
INPUT_PROP_HAPTIC_TOUCHPAD
--------------------------
-The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
-- supports simple haptic auto and manual triggering
+The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that the device provides
+simulated haptic feedback (e.g. a vibrator motor situated below the surface)
+instead of physical haptic feedback (e.g. a hinge). This property is only set
+if the device:
- can differentiate between at least 5 fingers
- uses correct resolution for the X/Y (units and value)
-- reports correct force per touch, and correct units for them (newtons or grams)
- follows the MT protocol type B
+If the simulated haptic feedback is controllable by userspace the device must:
+- support simple haptic auto and manual triggering, and
+- report correct force per touch, and correct units for them (newtons or grams), and
+- provide the EV_FF FF_HAPTIC force feedback effect.
+
Summing up, such devices follow the MS spec for input devices in
-Win8 and Win8.1, and in addition support the Simple haptic controller HID table,
-and report correct units for the pressure.
+Win8 and Win8.1, and in addition may support the Simple haptic controller HID
+table, and report correct units for the pressure.
+
+Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
+does not replace that property.
Guidelines
==========
--
2.51.0
^ permalink raw reply related
* [PATCH v2] HID: Off-by-one error in CP2112 HID driver affecting SMBus block read output
From: Luis Yanes @ 2025-10-29 17:08 UTC (permalink / raw)
To: linux-input
In-Reply-To: <68F7C063.5049@yahoo.es>
Just following up on this bug report and proposed fix. I would appreciate feedback on
whether this approach is acceptable or if there is a preferred way to handle this quirk.
After thoroughly reviewing the driver code and rereading AN495 I still don't know why
these chips (tried 5 of them so far) are showing the previously stated observed behaviour,
because the driver logic seems compliant with the AN495 CP2112 interface specification.
But performing an SMBus block read using the CP2112 HID USB-to-SMBus bridge with these
chips the last byte of a 32-byte response is consistently incorrect unless an extra byte
was requested.
A flag could be added at driver load time to enable a quirk fix for affected chips but
the end user first would need to notice or know that their adapter is affected.
I have not been able to figure out a way to detect those affected chips that will produce
corrupted output without notice or warning other than directly checking the serial number.
So have written a quirks patch against v5.15.195 that applies to a given serial number
range or device version and can be enabled for those known to be affected with minimal
impact on the rest.
Alternatively I think that at least some sort of warning notice always should be included.
Signed-off-by: Luis Yanes <melus0@yahoo.es>
--- a/drivers/hid-cp2112.c
+++ b/drivers/hid-cp2112.c
@@ -26,6 +26,14 @@
#include <linux/nls.h>
#include <linux/usb/ch9.h>
#include "hid-ids.h"
+#include <linux/usb.h>
+
+#ifndef CP2112_QUIRKS
+#define CP2112_SN_RANGE_QUIRKS_START "00670000"
+#define CP2112_SN_RANGE_QUIRKS_END "00670FFF"
+#define CP2112_DEVICE_VERSION_QUIRK 2
+#define CP2112_QUIRK_SMBUS_BLOCK33 BIT(0)
+#endif
#define CP2112_REPORT_MAX_LENGTH 64
#define CP2112_GPIO_CONFIG_LENGTH 5
@@ -170,6 +178,7 @@
struct delayed_work gpio_poll_worker;
unsigned long irq_mask;
u8 gpio_prev_state;
+ unsigned long quirks;
};
static int gpio_push_pull = 0xFF;
@@ -642,6 +651,7 @@
__le16 word;
ssize_t count;
size_t read_length = 0;
+ size_t max_length;
unsigned int retries;
int ret;
@@ -702,8 +712,14 @@
break;
case I2C_SMBUS_BLOCK_DATA:
if (I2C_SMBUS_READ == read_write) {
+ read_length = I2C_SMBUS_BLOCK_MAX ;
+ /* Apply quirk: allow one extra byte for CP2112 block read */
+ if (dev->quirks & CP2112_QUIRK_SMBUS_BLOCK33) {
+ read_length += 1;
+ hid_info(hdev, "Quirk: using block read size %lu\n", read_length);
+ }
count = cp2112_write_read_req(buf, addr,
- I2C_SMBUS_BLOCK_MAX,
+ read_length,
command, NULL, 0);
} else {
count = cp2112_write_req(buf, addr, command,
@@ -796,7 +812,14 @@
memcpy(data->block + 1, buf, read_length);
break;
case I2C_SMBUS_BLOCK_DATA:
- if (read_length > I2C_SMBUS_BLOCK_MAX) {
+ max_length = I2C_SMBUS_BLOCK_MAX;
+
+ if (dev->quirks & CP2112_QUIRK_SMBUS_BLOCK33) {
+ max_length += 1;
+ hid_info(hdev, "Quirk: allowing block read up to %lu bytes\n", max_length);
+ }
+
+ if (read_length > max_length) {
ret = -EPROTO;
goto power_normal;
}
@@ -1235,6 +1258,9 @@
struct gpio_irq_chip *girq;
int ret;
+ struct usb_device *udev;
+ char serial[64] = {0};
+
dev = devm_kzalloc(&hdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
@@ -1282,6 +1308,26 @@
hid_info(hdev, "Part Number: 0x%02X Device Version: 0x%02X\n",
buf[1], buf[2]);
+ if (buf[2] == CP2112_DEVICE_VERSION_QUIRK) {
+ dev->quirks |= CP2112_QUIRK_SMBUS_BLOCK33;
+ hid_info(hdev, "Enabled SMBus block+1 quirk for device version 0x%02X\n", buf[2]);
+ }
+
+ udev = interface_to_usbdev(to_usb_interface(hdev->dev.parent));
+
+ if (udev->descriptor.iSerialNumber) {
+ ret = usb_string(udev, udev->descriptor.iSerialNumber, serial, sizeof(serial));
+ if (ret > 0)
+ hid_info(hdev, "CP2112 device serial number: %s\n", serial);
+ }
+
+ if (strlen(serial) == 8 &&
+ strncmp(serial, CP2112_SN_RANGE_QUIRKS_START, 8) >= 0 &&
+ strncmp(serial, CP2112_SN_RANGE_QUIRKS_END, 8) <= 0) {
+ dev->quirks |= CP2112_QUIRK_SMBUS_BLOCK33;
+ hid_info(hdev, "Enabled SMBus block+1 quirk for serial %s\n", serial);
+ }
+
ret = cp2112_hid_get(hdev, CP2112_SMBUS_CONFIG, (u8 *)&config,
sizeof(config), HID_FEATURE_REPORT);
if (ret != sizeof(config)) {
--
^ permalink raw reply
* Re: [PATCH 08/10] arm64: dts: add description for solidrun imx8mp hummingboard-iiot
From: Alexander Dahl @ 2025-10-29 9:23 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-leds
In-Reply-To: <2c54b7b7-4eb4-44a0-8025-8da16a28efd4@solid-run.com>
Hello Josua,
Am Tue, Oct 28, 2025 at 12:24:36PM +0000 schrieb Josua Mayer:
> Am 27.10.25 um 18:48 schrieb Josua Mayer:
>
> > Add description for the SolidRun i.MX8MP HummingBoard IIoT.
> > The board is a new design around the i.MX8MP System on Module, not
> > sharing much with previous HummingBoards.
> >
> > It comes with some common features:
> > - 3x USB-3.0 Type A connector
> > - 2x 1Gbps RJ45 Ethernet
> > - USB Type-C Console Port
> > - microSD connector
> > - RTC with backup battery
> > - RGB Status LED
> > - 1x M.2 M-Key connector with PCI-E Gen. 3 x1
> > - 1x M.2 B-Key connector with USB-2.0/3.0 + SIM card holder
> > - 1x LVDS Display Connector
> > - 1x DSI Display Connector
> > - GPIO header
> > - 2x RS232/RS485 ports (configurable)
> > - 2x CAN
> >
> > In addition there is a board-to-board expansion connector to support
> > custom daughter boards with access to SPI, a range of GPIOs and -
> > notably - CAN and UART. Both 2x CAN and 2x UART can be muxed either
> > to this b2b connector, or a termianl block connector on the base board.
> >
> > The routing choice for UART and CAN is expressed through gpio
> > mux-controllers in DT and can be changed by applying dtb addons.
> >
> > Four dtb addons are provided:
> >
> > - dsi panel Winstar WJ70N3TYJHMNG0
> > - lvds panel Winstar WF70A8SYJHLNGA
> > - RS485 on UART port "A" (default rs232)
> > - RS485 on UART port "B" (default rs232)
> >
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 6 +
> > ...hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso | 70 ++
> > ...ummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso | 105 +++
> > .../imx8mp-hummingboard-iiot-rs485-a.dtso | 18 +
> > .../imx8mp-hummingboard-iiot-rs485-b.dtso | 18 +
> > .../dts/freescale/imx8mp-hummingboard-iiot.dts | 710 +++++++++++++++++++++
> > 6 files changed, 927 insertions(+)
> cut
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts
> > new file mode 100644
> > index 0000000000000..2e4cb676bc9da
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts
> cut
> > + led-controller@30 {
> > + compatible = "ti,lp5562";
> > + reg = <0x30>;
> > + /* use internal clock, could use external generated by rtc */
> > + clock-mode = /bits/ 8 <1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + multi-led@0 {
> > + reg = <0x0>;
> > + color = <LED_COLOR_ID_RGB>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + led@0 {
> > + reg = <0x0>;
> > + color = <LED_COLOR_ID_RED>;
> > + led-cur = /bits/ 8 <0x32>;
> > + max-cur = /bits/ 8 <0x64>;
> > + };
> > +
> > + led@1 {
> > + reg = <0x1>;
> > + color = <LED_COLOR_ID_GREEN>;
> > + led-cur = /bits/ 8 <0x19>;
> > + max-cur = /bits/ 8 <0x32>;
> > + };
> > +
> > + led@2 {
> > + reg = <0x2>;
> > + color = <LED_COLOR_ID_BLUE>;
> > + led-cur = /bits/ 8 <0x19>;
> > + max-cur = /bits/ 8 <0x32>;
> > + };
> > + };
> > +
> > + led@3 {
> > + reg = <3>;
> > + chan-name = "D8";
>
> chan-name gives the led the name D6 in sysfs.
>
> The bindings do not allow however setting chan-name on
> the multi-led, and it has an auto-generated name in sysfs.
>
> Am I missing something? Can multi-leds have a custom name?
The sysfs names are auto-generated based on the attributes "color",
"function", and "label" with the last being discouraged for new
designs. If the "ti,lp5562" driver does nothing special, you could
add "function" to the multi-led node and see if that fits your needs.
Adding linux-leds to Cc, because this is a LED related question.
Greets
Alex
> In v6.6 leds-lp5562 driver if I set in each multi-led led@[0-2] sub-node
> chan-name to the same string "D7" - then the sysfs name becomes D7.
>
> > + color = <LED_COLOR_ID_GREEN>;
> > + led-cur = /bits/ 8 <0x19>;
> > + max-cur = /bits/ 8 <0x64>;
> > + };
> > + };
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: fsl,scu-key: Add compatible string fsl,imx8qm-sc-key
From: Krzysztof Kozlowski @ 2025-10-29 6:54 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dong Aisheng, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-input, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20251028-b4_qm_scu_key-v1-1-9732e92a5e83@nxp.com>
On Tue, Oct 28, 2025 at 04:01:28PM -0400, Frank Li wrote:
> Add compatible string fsl,imx8qm-sc-key for i.MX8QM and fallback to
> fsl,imx-sc-key.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> Documentation/devicetree/bindings/input/fsl,scu-key.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] input: pf1550: Replace deprecated PM_OPS define
From: Samuel Kayode @ 2025-10-29 2:59 UTC (permalink / raw)
To: Jerome Oufella, naresh.kamboju, maddy, mpe, lee, Dmitry Torokhov,
Frank Li, Sean Nyekjaer, Heiko Carstens, Christian Borntraeger
Cc: linux-s390, linux-input, linux-kernel, Samuel Kayode, imx
Replace SIMPLE_DEV_PM_OPS with DEFINE_SIMPLE_DEV_PM_OPS as the former is
deprecated.
Signed-off-by: Samuel Kayode <samkay014@gmail.com>
---
drivers/input/misc/pf1550-onkey.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/pf1550-onkey.c b/drivers/input/misc/pf1550-onkey.c
index 9be6377151cb3be824ab34ff37f983196b909324..a636ceedfc04f0946e002a0b1be4586138429f12 100644
--- a/drivers/input/misc/pf1550-onkey.c
+++ b/drivers/input/misc/pf1550-onkey.c
@@ -173,8 +173,8 @@ static int pf1550_onkey_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
- pf1550_onkey_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
+ pf1550_onkey_resume);
static const struct platform_device_id pf1550_onkey_id[] = {
{ "pf1550-onkey", },
---
base-commit: a7d6255a0bf302c028ac680564633a6aac5f611d
change-id: 20251028-pf1550-71cea35a0c90
Best regards,
--
Samuel Kayode <samkay014@gmail.com>
^ permalink raw reply related
* [PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys
From: Dragan Simic @ 2025-10-28 21:32 UTC (permalink / raw)
To: nicolas.frattaroli
Cc: alexandre.belloni, conor+dt, devicetree, dmitry.torokhov, heiko,
kernel, krzk+dt, linux-arm-kernel, linux-input, linux-kernel,
linux-rockchip, robh
In-Reply-To: <20250630-rock4d-audio-v1-2-0b3c8e8fda9c@collabora.com>
Hello Nicolas,
On Monday, June 30, 2025, 12:19:24 Nicolas Frattaroli wrote:
> Instead of doing something like what gpio-keys is doing, adc-keys
> hardcodes that all keycodes must be of type EV_KEY.
>
> This limits the usefulness of adc-keys, and overcomplicates the code
> with manual bit-setting logic.
>
> Instead, refactor the code to read the linux,input-type fwnode property,
> and get rid of the custom bit setting logic, replacing it with
> input_set_capability instead. input_report_key is replaced with
> input_event, which allows us to explicitly pass the type.
Thanks for this patch, it's indeed very useful! Please see some
comments below.
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/input/keyboard/adc-keys.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> index f1753207429db02ce6510e5ec0da9b24d9edb61d..339dd4d4a0842108da2c6136b1e0098cd1f6a3cd 100644
> --- a/drivers/input/keyboard/adc-keys.c
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -19,12 +19,14 @@
> struct adc_keys_button {
> u32 voltage;
> u32 keycode;
> + u32 type;
> };
>
> struct adc_keys_state {
> struct iio_channel *channel;
> u32 num_keys;
> u32 last_key;
> + u32 last_type;
> u32 keyup_voltage;
> const struct adc_keys_button *map;
> };
> @@ -35,6 +37,7 @@ static void adc_keys_poll(struct input_dev *input)
> int i, value, ret;
> u32 diff, closest = 0xffffffff;
> int keycode = 0;
> + u32 type = EV_KEY;
>
> ret = iio_read_channel_processed(st->channel, &value);
> if (unlikely(ret < 0)) {
> @@ -46,6 +49,7 @@ static void adc_keys_poll(struct input_dev *input)
> if (diff < closest) {
> closest = diff;
> keycode = st->map[i].keycode;
> + type = st->map[i].type;
> }
> }
> }
> @@ -54,13 +58,14 @@ static void adc_keys_poll(struct input_dev *input)
> keycode = 0;
>
> if (st->last_key && st->last_key != keycode)
> - input_report_key(input, st->last_key, 0);
> + input_event(input, st->last_type, st->last_key, 0);
>
> if (keycode)
> - input_report_key(input, keycode, 1);
> + input_event(input, type, keycode, 1);
When EV_ABS is defined in the DT as the key type, which happens with
joysticks and whatnot, separate handling is needed, by requiring the
actual associated button values to be reported in the input_event()
invocations, more specifically on the keypresses only.
That's also visible in the gpio_keys_gpio_report_event() function in
drivers/input/keyboard/gpio_keys.c.
> input_sync(input);
> st->last_key = keycode;
> + st->last_type = type;
> }
>
> static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> @@ -93,6 +98,10 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> return -EINVAL;
> }
>
> + if (fwnode_property_read_u32(child, "linux,input-type",
> + &map[i].type))
> + map[i].type = EV_KEY;
Going along with the remarks above, it will also be needed to read
and record the values of "linux,input-value" DT properties here, and
to extend the associated binding to define their presence.
> i++;
> }
>
> @@ -156,9 +165,8 @@ static int adc_keys_probe(struct platform_device *pdev)
> input->id.product = 0x0001;
> input->id.version = 0x0100;
>
> - __set_bit(EV_KEY, input->evbit);
> for (i = 0; i < st->num_keys; i++)
> - __set_bit(st->map[i].keycode, input->keybit);
> + input_set_capability(input, st->map[i].type, st->map[i].keycode);
>
> if (device_property_read_bool(dev, "autorepeat"))
> __set_bit(EV_REP, input->evbit);
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8qm: add scu power key support
From: Frank Li @ 2025-10-28 20:01 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dong Aisheng, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-input, devicetree, linux-kernel, imx, linux-arm-kernel,
Frank Li
In-Reply-To: <20251028-b4_qm_scu_key-v1-0-9732e92a5e83@nxp.com>
Add scu power key node.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qm.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm.dtsi b/arch/arm64/boot/dts/freescale/imx8qm.dtsi
index 5206ca82eaf642a32299147e9c1b45704075e2b2..2508a07832810831d019f81d47a8f7042a77d709 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/pads-imx8qm.h>
#include <dt-bindings/thermal/thermal.h>
@@ -330,6 +331,12 @@ clk: clock-controller {
#clock-cells = <2>;
};
+ scu_key: keys {
+ compatible = "fsl,imx8qm-sc-key", "fsl,imx-sc-key";
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
iomuxc: pinctrl {
compatible = "fsl,imx8qm-iomuxc";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: input: fsl,scu-key: Add compatible string fsl,imx8qm-sc-key
From: Frank Li @ 2025-10-28 20:01 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dong Aisheng, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-input, devicetree, linux-kernel, imx, linux-arm-kernel,
Frank Li
In-Reply-To: <20251028-b4_qm_scu_key-v1-0-9732e92a5e83@nxp.com>
Add compatible string fsl,imx8qm-sc-key for i.MX8QM and fallback to
fsl,imx-sc-key.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/input/fsl,scu-key.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/fsl,scu-key.yaml b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
index 29921aab9d9713c475654fd1e1e1ebe26a5e08d1..2566cffc252d7c426bcd94fa3c2dc90fbb664a9b 100644
--- a/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
+++ b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
@@ -18,7 +18,9 @@ allOf:
properties:
compatible:
items:
- - const: fsl,imx8qxp-sc-key
+ - enum:
+ - fsl,imx8qm-sc-key
+ - fsl,imx8qxp-sc-key
- const: fsl,imx-sc-key
linux,keycodes:
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] input: fsl,scu-key: Add compatible string fsl,imx8qm-sc-key
From: Frank Li @ 2025-10-28 20:01 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dong Aisheng, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-input, devicetree, linux-kernel, imx, linux-arm-kernel,
Frank Li
bindings: add fsl,imx8qm-sc-key.
dts: add fsl,imx8qm-sc-key support.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (2):
dt-bindings: input: fsl,scu-key: Add compatible string fsl,imx8qm-sc-key
arm64: dts: imx8qm: add scu power key support
Documentation/devicetree/bindings/input/fsl,scu-key.yaml | 4 +++-
arch/arm64/boot/dts/freescale/imx8qm.dtsi | 7 +++++++
2 files changed, 10 insertions(+), 1 deletion(-)
---
base-commit: f7d2388eeec24966fc4d5cf32d706f0514f29ac5
change-id: 20251028-b4_qm_scu_key-975f51c41752
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: input: elan: Introduce Elan eKTP1059 Touchpad
From: Conor Dooley @ 2025-10-28 19:49 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Tony Lindgren, hns, linux-input, devicetree,
linux-kernel, linux-omap
In-Reply-To: <20251028204149.325506f6@kemnade.info>
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
On Tue, Oct 28, 2025 at 08:41:49PM +0100, Andreas Kemnade wrote:
> On Mon, 25 Aug 2025 17:40:56 +0100
> Conor Dooley <conor@kernel.org> wrote:
>
> > On Mon, Aug 25, 2025 at 12:07:28AM +0200, Andreas Kemnade wrote:
> > > The Elan eKTP1059 Touchpad is seen in the Epson Moverio BT-200
> > > attached via SPI. Add a binding for this chip. Little is known.
> > >
> > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > > ---
> > > .../devicetree/bindings/input/elan,ektp1059.yaml | 45 ++++++++++++++++++++++
> > > 1 file changed, 45 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/elan,ektp1059.yaml b/Documentation/devicetree/bindings/input/elan,ektp1059.yaml
> > > new file mode 100644
> > > index 000000000000..a10256a271e0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/elan,ektp1059.yaml
> > > @@ -0,0 +1,45 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/elan,ektp1059.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Elantech SPI Touchpad
> > > +
> > > +maintainers:
> > > + - Andreas Kemnade <andreas@kemnade.info>
> > > +
> > > +allOf:
> > > + - $ref: touchscreen/touchscreen.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + const: elan,ektp1059
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - interrupts
> > > +
> > > +additionalProperties: false
btw, there's two spaces at EOL here. Is that in the patch itself, or
just a mail artefact?
> >
> > Shouldn't this be unevalutedProperties: false, since you want to make
> > use of what's in touchscreen.yaml?
> >
> did not do too much thought about this yet. But am I allowed to use this
> in a touchpad? BTW: who defines whether the chip is a touchpad? T*P* in
> its part number might be a hint, the device where I am using it, uses it
> as a touchpad. But who says it cannot be glued onto some screen?
I've got no idea what you're talking about here, I don't know anything
about the mechanics of touchpad chips. All I am commenting on is that
you're including touchscreen.yaml but do not permit any properties
defined in that binding to be used for this device.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: input: elan: Introduce Elan eKTP1059 Touchpad
From: Andreas Kemnade @ 2025-10-28 19:41 UTC (permalink / raw)
To: Conor Dooley
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Tony Lindgren, hns, linux-input, devicetree,
linux-kernel, linux-omap
In-Reply-To: <20250825-decal-purchase-8cfe0003a3f2@spud>
On Mon, 25 Aug 2025 17:40:56 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Mon, Aug 25, 2025 at 12:07:28AM +0200, Andreas Kemnade wrote:
> > The Elan eKTP1059 Touchpad is seen in the Epson Moverio BT-200
> > attached via SPI. Add a binding for this chip. Little is known.
> >
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> > .../devicetree/bindings/input/elan,ektp1059.yaml | 45 ++++++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/elan,ektp1059.yaml b/Documentation/devicetree/bindings/input/elan,ektp1059.yaml
> > new file mode 100644
> > index 000000000000..a10256a271e0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/elan,ektp1059.yaml
> > @@ -0,0 +1,45 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/elan,ektp1059.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Elantech SPI Touchpad
> > +
> > +maintainers:
> > + - Andreas Kemnade <andreas@kemnade.info>
> > +
> > +allOf:
> > + - $ref: touchscreen/touchscreen.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: elan,ektp1059
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +additionalProperties: false
>
> Shouldn't this be unevalutedProperties: false, since you want to make
> use of what's in touchscreen.yaml?
>
did not do too much thought about this yet. But am I allowed to use this
in a touchpad? BTW: who defines whether the chip is a touchpad? T*P* in
its part number might be a hint, the device where I am using it, uses it
as a touchpad. But who says it cannot be glued onto some screen?
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi
From: Ilpo Järvinen @ 2025-10-28 16:37 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Hans de Goede
Cc: linux-input, platform-driver-x86
In-Reply-To: <20251020152331.52870-1-hansg@kernel.org>
On Mon, 20 Oct 2025 17:23:29 +0200, Hans de Goede wrote:
> Here is a patch series for adding support for the electronic privacy screen
> on/off events send on e.g. Dell Latitude 7300 models.
>
> On these laptops the firmware does not allow querying the presence nor
> the status of the eprivacy screen at boot. This makes it impossible to
> implement the drm connector eprivacy properties API (1) since drm objects
> do not allow adding new properties after creation and the presence of
> the eprivacy cannot be detected at boot.
>
> [...]
Thank you for your contribution, it has been applied to my local
review-ilpo-fixes branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-fixes branch only once I've pushed my
local branch there, which might take a while.
The list of commits applied:
[1/2] Input: Add keycodes for electronic privacy screen on/off hotkeys
commit: 8f3eaad9812f62e7006ad08602444b32c3101824
[2/2] platform/x86: dell-wmi-base: Handle electronic privacy screen on/off events
commit: 4173edb076b3ae30d734d55fce0ebac63139b656
--
i.
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: display: panel: ronbo,rb070d30: add port property
From: Krzysztof Kozlowski @ 2025-10-28 16:23 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <5e055ce8-e30c-45b7-993a-3ea8f8a796d2@solid-run.com>
On 28/10/2025 13:01, Josua Mayer wrote:
> Am 28.10.25 um 10:03 schrieb Krzysztof Kozlowski:
>> On Mon, Oct 27, 2025 at 06:48:11PM +0100, Josua Mayer wrote:
>>> port property is used for linking dsi ports with dsi panels.
>>> Add port property to ronbo dsi panel binding.
>>>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>> ---
>>> Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>>> index 04f86e0cbac91..a2dc67a87fa3b 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>>> +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>>> @@ -13,6 +13,7 @@ properties:
>>> compatible:
>>> const: ronbo,rb070d30
>>>
>>> + port: true
>> Port is never the second property. Please look at other bindings.
>
> Some places did that ...., e.g.:
Yes, finding few outliers is not a good argument. Especially binding
from 2020 where many conventions did not exist.
Look at the most of the bindings or the recently reviewed.
>
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- compatible:
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- enum:
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- - mantix,mlaf057we51-x
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- - ys,ys57pss36bh5gq
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml-
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml: port: true
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- reg:
>
>>
>> Also, missing blank line
> Okay
>> and missing top-level ref for panel-common.
>
> Does this impact which properties are considered required / valid?
>
> Ronbo panel has different gpios / names from panel-common:
>
> power-gpios: similar to panel-common enable-gpios
> reset-gpios: common to panel-common
> shlr-gpios: special to ronbo
> updn-gpios: special to ronbo
> vcc-lcd-supply: similar to panel-common power-supply
> backlight: common to panel-common
>
> There are some other gpios in panel-common that ronbo panel does not use.
Just use the properties from the common schema where applicable.
>
> Is the above relevant?
> Would it be correct adding the below?:
>
> maintainers:
> - Maxime Ripard <mripard@kernel.org>
>
> +allOf:
> + - $ref: panel-common.yaml#
> +
> properties:
> compatible:
> const: ronbo,rb070d30
>
> @@ -48,5 +50,6 @@ required:
> - shlr-gpios
> - updn-gpios
> - vcc-lcd-supply
> + - port
>
> additionalProperties: false
unevaluatedProperties:false now.
Best regards,
Krzysztof
^ permalink raw reply
* [Bug Report] Libwacom broken user space
From: Чапля Иван @ 2025-10-28 14:13 UTC (permalink / raw)
To: linux-input
[-- Attachment #1.1: Type: text/plain, Size: 6995 bytes --]
[libwacom](https://github.com/linuxwacom/libwacom) is a library to
identify graphics tablets and their model-specific features. It provides
easy access to information such as "is this a built-in-screen tablet",
"what is the size of this model", etc. libwacom is currently used by GUI
toolkits (GNOME, KDE, others?) to map built-in tablets to the correct
screen and by libinput to determine configuration options such as the
left-handed settings. SVG layout files are used to describe the tablet
visually.
Until recently, this library worked perfectly fine. I have a GAOMON S620
graphics tablet that used to work correctly some time ago. I decided to use
it now, and it turned out that I can no longer use the buttons on it; they
simply don't work. This functionality is handled precisely by the libwacom
library. The configuration for each device in this library is stored in a
static .tablet file. Such a file exists for my tablet as well and looks
like this:
```
[Device]
Name=GAOMON S620
ModelName=
DeviceMatch=usb|256c|006d|GAOMON Gaomon Tablet Pen;usb|256c|006d|GAOMON
Gaomon Tablet Pad;usb|256c|006d|GAOMON Gaomon Tablet
Pen|OEM02_T18e;usb|256c|006d|GAOMON Gaomon Tablet Pad|OEM02_T18e;
Width=6
Height=4
Layout=gaomon-s620.svg
IntegratedIn=
Styli=@generic-no-eraser;
[Features]
Stylus=true
Reversible=true
[Buttons]
Left=A;B;C;D
EvdevCodes=BTN_0;BTN_1;BTN_2;BTN_3
```
But for some reason, the library no longer recognizes it.
`libwacom-list-local-devices` output:
```
/dev/input/event8 (usb:256c:006d - "GAOMON Gaomon Tablet Dial") is a tablet
but not supported by libwacom
/dev/input/event7 (usb:256c:006d - "GAOMON Gaomon Tablet Touch Strip") is a
tablet but not supported by libwacom
/dev/input/event6 (usb:256c:006d - "GAOMON Gaomon Tablet") is a tablet but
not supported by libwacom
/dev/input/event5 (usb:256c:006d - "GAOMON Gaomon Tablet") is a tablet but
not supported by libwacom
Failed to find any devices known to libwacom.
```
The library retrieves device information from the `/proc/bus/input/devices`
file. I tested the tablet's functionality on various kernel versions and
obtained the following results:
- 6.17.4 problem occurs
- 6.16.12 problem occurs
- 6.15.10 problem occurs
- 6.14.11 problem occurs
- 6.14.8 problem occurs
- 6.14.7 marked as "obsolete" in fedora koji, unable to install
- 6.14.6 problem do not occurs
`cat /proc/bus/input/devices` output when tablet is broken:
```
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input8
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse2 event5
B: PROP=1
B: EV=1b
B: KEY=1c01 0 0 0 0 0
B: ABS=d000003
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input9
U: Uniq=OEM02_T18e_200919
H: Handlers=event6 js0
B: PROP=0
B: EV=1b
B: KEY=800 201ff 0 0 0 0
B: ABS=3
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Touch Strip"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input10
U: Uniq=OEM02_T18e_200919
H: Handlers=event7 js1
B: PROP=0
B: EV=b
B: KEY=1 0 0 0 0
B: ABS=1000000001b
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Dial"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input11
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse3 event8 js2
B: PROP=0
B: EV=1f
B: KEY=1 0 0 0 0
B: REL=900
B: ABS=10000000003
B: MSC=10
```
`cat /proc/bus/input/devices` output when tablet works fine:
```
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Pen"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input11
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse2 event8
B: PROP=1
B: EV=1b
B: KEY=1c01 0 0 0 0 0
B: ABS=d000003
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Pad"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input12
U: Uniq=OEM02_T18e_200919
H: Handlers=event9 js0
B: PROP=0
B: EV=1b
B: KEY=800 3ff0000000003ff 0 0 0 0
B: ABS=3
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Touch Strip"
P: Phys=usb-0000:00:1d.0-1.5/input0
S:
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input13
U: Uniq=OEM02_T18e_200919
H: Handlers=event10 js1
B: PROP=0
B: EV=b
B: KEY=1 0 0 0 0
B: ABS=1000000001b
```
It turns out that for some reason, the pen and pad parameters necessary for
identifying the device are now missing from this file. Simply replacing the
old names `GAOMON Gaomon Tablet Pen` and `GAOMON Gaomon Tablet Pad` with
the new `GAOMON Gaomon Tablet` in the configuration didn't solve the
problem. It leads to the recognition of the tablet
```
devices:
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event11: 'GAOMON Gaomon Tablet Dial'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event10: 'GAOMON Gaomon Tablet Touch Strip'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event9: 'GAOMON Gaomon Tablet'
- /dev/input/event8: 'GAOMON Gaomon Tablet'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
```
Although an option to assign key combinations for the tablet buttons now
appears, the physical buttons themselves are not detected and do not react
when pressed.
For some reason, starting after version 6.14.6, the pen and pad pointers
disappear during device initialization. There is also at least one other
known case of the [same issue](
https://github.com/linuxwacom/libwacom/issues/914). Unlike me, the user's
problem no longer occurs after renaming DeviceMatch. I have also opened an
[issue](https://github.com/linuxwacom/libwacom/issues/928) on libwacom's
GitHub.
I'm not a programmer, just an end user, I do not know how to write code or
solve problems of such type. So I would be grateful for your help
[-- Attachment #1.2: Type: text/html, Size: 8261 bytes --]
[-- Attachment #2: libwacom broken user space.html --]
[-- Type: text/html, Size: 15601 bytes --]
[-- Attachment #3: libwacom broken user space.pdf --]
[-- Type: application/pdf, Size: 38022 bytes --]
[-- Attachment #4: libwacom broken user space.md --]
[-- Type: text/markdown, Size: 7028 bytes --]
# [bug] Libwacom broken user space
[libwacom](https://github.com/linuxwacom/libwacom) is a library to identify graphics tablets and their model-specific features. It provides easy access to information such as "is this a built-in-screen tablet", "what is the size of this model", etc. libwacom is currently used by GUI toolkits (GNOME, KDE, others?) to map built-in tablets to the correct screen and by libinput to determine configuration options such as the left-handed settings. SVG layout files are used to describe the tablet visually.
Until recently, this library worked perfectly fine. I have a GAOMON S620 graphics tablet that used to work correctly some time ago. I decided to use it now, and it turned out that I can no longer use the buttons on it; they simply don't work. This functionality is handled precisely by the libwacom library. The configuration for each device in this library is stored in a static .tablet file. Such a file exists for my tablet as well and looks like this:
```
[Device]
Name=GAOMON S620
ModelName=
DeviceMatch=usb|256c|006d|GAOMON Gaomon Tablet Pen;usb|256c|006d|GAOMON Gaomon Tablet Pad;usb|256c|006d|GAOMON Gaomon Tablet Pen|OEM02_T18e;usb|256c|006d|GAOMON Gaomon Tablet Pad|OEM02_T18e;
Width=6
Height=4
Layout=gaomon-s620.svg
IntegratedIn=
Styli=@generic-no-eraser;
[Features]
Stylus=true
Reversible=true
[Buttons]
Left=A;B;C;D
EvdevCodes=BTN_0;BTN_1;BTN_2;BTN_3
```
But for some reason, the library no longer recognizes it.
`libwacom-list-local-devices` output:
```
/dev/input/event8 (usb:256c:006d - "GAOMON Gaomon Tablet Dial") is a tablet but not supported by libwacom
/dev/input/event7 (usb:256c:006d - "GAOMON Gaomon Tablet Touch Strip") is a tablet but not supported by libwacom
/dev/input/event6 (usb:256c:006d - "GAOMON Gaomon Tablet") is a tablet but not supported by libwacom
/dev/input/event5 (usb:256c:006d - "GAOMON Gaomon Tablet") is a tablet but not supported by libwacom
Failed to find any devices known to libwacom.
```
The library retrieves device information from the `/proc/bus/input/devices` file. I tested the tablet's functionality on various kernel versions and obtained the following results:
- 6.17.4 problem occurs
- 6.16.12 problem occurs
- 6.15.10 problem occurs
- 6.14.11 problem occurs
- 6.14.8 problem occurs
- 6.14.7 marked as "obsolete" in fedora koji, unable to install
- 6.14.6 problem do not occurs
`cat /proc/bus/input/devices` output when tablet is broken:
```
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input8
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse2 event5
B: PROP=1
B: EV=1b
B: KEY=1c01 0 0 0 0 0
B: ABS=d000003
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input9
U: Uniq=OEM02_T18e_200919
H: Handlers=event6 js0
B: PROP=0
B: EV=1b
B: KEY=800 201ff 0 0 0 0
B: ABS=3
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Touch Strip"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input10
U: Uniq=OEM02_T18e_200919
H: Handlers=event7 js1
B: PROP=0
B: EV=b
B: KEY=1 0 0 0 0
B: ABS=1000000001b
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Dial"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0002/input/input11
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse3 event8 js2
B: PROP=0
B: EV=1f
B: KEY=1 0 0 0 0
B: REL=900
B: ABS=10000000003
B: MSC=10
```
`cat /proc/bus/input/devices` output when tablet works fine:
```
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Pen"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input11
U: Uniq=OEM02_T18e_200919
H: Handlers=mouse2 event8
B: PROP=1
B: EV=1b
B: KEY=1c01 0 0 0 0 0
B: ABS=d000003
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Pad"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input12
U: Uniq=OEM02_T18e_200919
H: Handlers=event9 js0
B: PROP=0
B: EV=1b
B: KEY=800 3ff0000000003ff 0 0 0 0
B: ABS=3
B: MSC=10
I: Bus=0003 Vendor=256c Product=006d Version=0111
N: Name="GAOMON Gaomon Tablet Touch Strip"
P: Phys=usb-0000:00:1d.0-1.5/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:256C:006D.0004/input/input13
U: Uniq=OEM02_T18e_200919
H: Handlers=event10 js1
B: PROP=0
B: EV=b
B: KEY=1 0 0 0 0
B: ABS=1000000001b
```
It turns out that for some reason, the pen and pad parameters necessary for identifying the device are now missing from this file. Simply replacing the old names `GAOMON Gaomon Tablet Pen` and `GAOMON Gaomon Tablet Pad` with the new `GAOMON Gaomon Tablet` in the configuration didn't solve the problem. It leads to the recognition of the tablet
```
devices:
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event11: 'GAOMON Gaomon Tablet Dial'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event10: 'GAOMON Gaomon Tablet Touch Strip'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
- name: 'GAOMON S620'
bus: 'usb'
vid: 0x256c
pid: 0x006d
nodes:
- /dev/input/event9: 'GAOMON Gaomon Tablet'
- /dev/input/event8: 'GAOMON Gaomon Tablet'
styli:
- id: 0xffffd
vid: 0x0000
name: 'General Pen with no Eraser'
type: 'general'
axes: ['x', 'y' , 'pressure']
buttons: 2
erasers: []
```
Although an option to assign key combinations for the tablet buttons now appears, the physical buttons themselves are not detected and do not react when pressed.
For some reason, starting after version 6.14.6, the pen and pad pointers disappear during device initialization. There is also at least one other known case of the [same issue](https://github.com/linuxwacom/libwacom/issues/914). Unlike me, the user's problem no longer occurs after renaming DeviceMatch. I have also opened an [issue](https://github.com/linuxwacom/libwacom/issues/928) on libwacom's GitHub.
I'm not a programmer, just an end user, I do not know how to write code or solve problems of such type. So I would be grateful for your help
^ permalink raw reply
* Re: [PATCH 08/10] arm64: dts: add description for solidrun imx8mp hummingboard-iiot
From: Josua Mayer @ 2025-10-28 12:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20251027-imx8mp-hb-iiot-v1-8-683f86357818@solid-run.com>
Am 27.10.25 um 18:48 schrieb Josua Mayer:
> Add description for the SolidRun i.MX8MP HummingBoard IIoT.
> The board is a new design around the i.MX8MP System on Module, not
> sharing much with previous HummingBoards.
>
> It comes with some common features:
> - 3x USB-3.0 Type A connector
> - 2x 1Gbps RJ45 Ethernet
> - USB Type-C Console Port
> - microSD connector
> - RTC with backup battery
> - RGB Status LED
> - 1x M.2 M-Key connector with PCI-E Gen. 3 x1
> - 1x M.2 B-Key connector with USB-2.0/3.0 + SIM card holder
> - 1x LVDS Display Connector
> - 1x DSI Display Connector
> - GPIO header
> - 2x RS232/RS485 ports (configurable)
> - 2x CAN
>
> In addition there is a board-to-board expansion connector to support
> custom daughter boards with access to SPI, a range of GPIOs and -
> notably - CAN and UART. Both 2x CAN and 2x UART can be muxed either
> to this b2b connector, or a termianl block connector on the base board.
>
> The routing choice for UART and CAN is expressed through gpio
> mux-controllers in DT and can be changed by applying dtb addons.
>
> Four dtb addons are provided:
>
> - dsi panel Winstar WJ70N3TYJHMNG0
> - lvds panel Winstar WF70A8SYJHLNGA
> - RS485 on UART port "A" (default rs232)
> - RS485 on UART port "B" (default rs232)
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 6 +
> ...hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso | 70 ++
> ...ummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso | 105 +++
> .../imx8mp-hummingboard-iiot-rs485-a.dtso | 18 +
> .../imx8mp-hummingboard-iiot-rs485-b.dtso | 18 +
> .../dts/freescale/imx8mp-hummingboard-iiot.dts | 710 +++++++++++++++++++++
> 6 files changed, 927 insertions(+)
cut
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts
> new file mode 100644
> index 0000000000000..2e4cb676bc9da
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts
cut
> + led-controller@30 {
> + compatible = "ti,lp5562";
> + reg = <0x30>;
> + /* use internal clock, could use external generated by rtc */
> + clock-mode = /bits/ 8 <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + multi-led@0 {
> + reg = <0x0>;
> + color = <LED_COLOR_ID_RGB>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0x0>;
> + color = <LED_COLOR_ID_RED>;
> + led-cur = /bits/ 8 <0x32>;
> + max-cur = /bits/ 8 <0x64>;
> + };
> +
> + led@1 {
> + reg = <0x1>;
> + color = <LED_COLOR_ID_GREEN>;
> + led-cur = /bits/ 8 <0x19>;
> + max-cur = /bits/ 8 <0x32>;
> + };
> +
> + led@2 {
> + reg = <0x2>;
> + color = <LED_COLOR_ID_BLUE>;
> + led-cur = /bits/ 8 <0x19>;
> + max-cur = /bits/ 8 <0x32>;
> + };
> + };
> +
> + led@3 {
> + reg = <3>;
> + chan-name = "D8";
chan-name gives the led the name D6 in sysfs.
The bindings do not allow however setting chan-name on
the multi-led, and it has an auto-generated name in sysfs.
Am I missing something? Can multi-leds have a custom name?
In v6.6 leds-lp5562 driver if I set in each multi-led led@[0-2] sub-node
chan-name to the same string "D7" - then the sysfs name becomes D7.
> + color = <LED_COLOR_ID_GREEN>;
> + led-cur = /bits/ 8 <0x19>;
> + max-cur = /bits/ 8 <0x64>;
> + };
> + };
^ permalink raw reply
* Re: [PATCH 06/10] arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference
From: Josua Mayer @ 2025-10-28 12:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20251027-imx8mp-hb-iiot-v1-6-683f86357818@solid-run.com>
Am 27.10.25 um 18:48 schrieb Josua Mayer:
> imx8mp.dtsi includes a default port@1 node with and empty placeholder
s/and/an
> endpoint intended for linking to a dsi bridge or panel.
> HummingBoard Pulse mini-hdmi dtsi added and linked hdmi brodge to yet
> another endpoint.
>
> This duplicate endpoint can cause dsi_attach to fail.
>
> Remove the duplicate node and link to the one defined in soc dtsi.
> Further remove the unnecessary attach-bridge property.
>
> Fixes: 2a222aa2bee9 ("arm64: dts: add description for solidrun imx8mp hummingboard variants")
> Signed-off-by Josua Mayer <josua@solid-run.com>
> ---
> .../dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
> index 46916ddc05335..0e5f4607c7c1b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
> @@ -41,7 +41,7 @@ port@0 {
> reg = <0>;
>
> adv7535_from_dsim: endpoint {
> - remote-endpoint = <&dsim_to_adv7535>;
> + remote-endpoint = <&mipi_dsi_out>;
> };
> };
>
> @@ -71,11 +71,8 @@ &lcdif1 {
> &mipi_dsi {
> samsung,esc-clock-frequency = <10000000>;
> status = "okay";
> +};
>
> - port@1 {
> - dsim_to_adv7535: endpoint {
> - remote-endpoint = <&adv7535_from_dsim>;
> - attach-bridge;
> - };
> - };
> +&mipi_dsi_out {
> + remote-endpoint = <&adv7535_from_dsim>;
> };
>
^ permalink raw reply
* Re: [PATCH 09/10] arm64: dts: add description for solidrun solidsense-n8 board
From: Josua Mayer @ 2025-10-28 12:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20251027-imx8mp-hb-iiot-v1-9-683f86357818@solid-run.com>
Am 27.10.25 um 18:48 schrieb Josua Mayer:
> Add description for the SolidRun SolidSense N8 Compact SVC.
drop " SVC":
Add description for the SolidRun SolidSense N8 Compact.
@Krzysztof Is "description for" implied, too - like in bindings? Can I change subject?:
arm64: dts: add solidrun solidsense-n8 board
> The board is designed around the i.MX8MN SoC and comes as a compelte
s/compelte/complete
> product including enclosure and labels.
>
> Features:
> - USB-2.0 Type A connector
> - 1Gbps RJ45 Ethernet with PoE
> - microSD connector
> - eMMC
> - Cellular Modem + SIM holder
> - WiFi + Bluetooth
> - RS485
> - CAN
> - 802.15.1 radio
> - supercapacitor backup power supply
>
> This is a headless design without display.
> The board includes an internal expansion connector for daughterboards
> which may be described by dt addon.
>
> The supercap is not currently modeled due to lack of suitable bindings.
s/modeled/described
> Vendor BSP uses gpio-keys driver to trigger shutdown on power loss.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> .../dts/freescale/imx8mn-solidsense-n8-compact.dts | 852 +++++++++++++++++++++
> 2 files changed, 854 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index d414d0efe5e74..c56137097da3b 100644
cut
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: display: panel: ronbo,rb070d30: add port property
From: Josua Mayer @ 2025-10-28 12:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jon Nettleton, Mikhail Anikin, Yazan Shhady,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20251028-premium-sunfish-of-feminism-2bc6ab@kuoka>
Am 28.10.25 um 10:03 schrieb Krzysztof Kozlowski:
> On Mon, Oct 27, 2025 at 06:48:11PM +0100, Josua Mayer wrote:
>> port property is used for linking dsi ports with dsi panels.
>> Add port property to ronbo dsi panel binding.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>> index 04f86e0cbac91..a2dc67a87fa3b 100644
>> --- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>> +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
>> @@ -13,6 +13,7 @@ properties:
>> compatible:
>> const: ronbo,rb070d30
>>
>> + port: true
> Port is never the second property. Please look at other bindings.
Some places did that ...., e.g.:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- compatible:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- enum:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- - mantix,mlaf057we51-x
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- - ys,ys57pss36bh5gq
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml-
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml: port: true
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml- reg:
>
> Also, missing blank line
Okay
> and missing top-level ref for panel-common.
Does this impact which properties are considered required / valid?
Ronbo panel has different gpios / names from panel-common:
power-gpios: similar to panel-common enable-gpios
reset-gpios: common to panel-common
shlr-gpios: special to ronbo
updn-gpios: special to ronbo
vcc-lcd-supply: similar to panel-common power-supply
backlight: common to panel-common
There are some other gpios in panel-common that ronbo panel does not use.
Is the above relevant?
Would it be correct adding the below?:
maintainers:
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: panel-common.yaml#
+
properties:
compatible:
const: ronbo,rb070d30
@@ -48,5 +50,6 @@ required:
- shlr-gpios
- updn-gpios
- vcc-lcd-supply
+ - port
additionalProperties: false
sincerely
Josua Mayer
^ 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