* Re: [PATCH v4 4/5] dt-bindings: touchscreen: convert zet6223 bindings to json schema
From: Rob Herring (Arm) @ 2025-09-18 20:11 UTC (permalink / raw)
To: Dario Binacchi
Cc: Dmitry Torokhov, linux-amarula, linux-input, linux-kernel,
devicetree, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20250918153630.2535208-4-dario.binacchi@amarulasolutions.com>
On Thu, 18 Sep 2025 17:36:09 +0200, Dario Binacchi wrote:
> Convert Zeitec ZET6223 touchscreen controller device tree binding to
> json-schema.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
> Changes in v4:
> - Drop "Phandle to the" from vio-supply and vcc-supply
> - Rename to zeitec,zet6223.yaml
>
> Changes in v2:
> - Added in v2
>
> .../input/touchscreen/zeitec,zet6223.yaml | 62 +++++++++++++++++++
> .../bindings/input/touchscreen/zet6223.txt | 30 ---------
> 2 files changed, 62 insertions(+), 30 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/zeitec,zet6223.yaml
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zet6223.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 3/6] dt-bindings: touchscreen: add touchscreen-glitch-threshold-ns property
From: Dario Binacchi @ 2025-09-18 20:37 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, Frank Li, linux-amarula, Conor Dooley, Conor Dooley,
Dmitry Torokhov, Javier Carrasco, Jeff LaBundy,
Krzysztof Kozlowski, devicetree, linux-input
In-Reply-To: <20250918200445.GA2529753-robh@kernel.org>
On Thu, Sep 18, 2025 at 10:04 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Sep 18, 2025 at 05:52:31PM +0200, Dario Binacchi wrote:
> > Add support for glitch threshold configuration. A detected signal is valid
> > only if it lasts longer than the set threshold; otherwise, it is regarded
> > as a glitch.
> >
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> >
> > ---
> >
> > Changes in v5:
> > - Add Acked-by tag of Conor Dooley
> >
> > Changes in v2:
> > - Added in v2.
> >
> > .../devicetree/bindings/input/touchscreen/touchscreen.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > index 3e3572aa483a..a60b4d08620d 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > @@ -206,6 +206,10 @@ properties:
> >
> > unevaluatedProperties: false
> >
> > + touchscreen-glitch-threshold-ns:
> > + description: Minimum duration in nanoseconds a signal must remain stable
> > + to be considered valid.
>
> What's wrong with debounce-delay-ms?
Do you mean that I should rename touchscreen-glitch-threshold-ns to
debounce-delay-ms?
Thanks and regards,
Dario
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binacchi@amarulasolutions.com
__________________________________
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@amarulasolutions.com
www.amarulasolutions.com
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: touchscreen: convert raspberrypi,firmware-ts bindings to json schema
From: Dario Binacchi @ 2025-09-18 21:00 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, linux-amarula, Broadcom internal kernel review list,
Conor Dooley, Dmitry Torokhov, Florian Fainelli,
Krzysztof Kozlowski, devicetree, linux-arm-kernel, linux-input,
linux-rpi-kernel
In-Reply-To: <20250918201027.GA2547040-robh@kernel.org>
On Thu, Sep 18, 2025 at 10:10 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Sep 18, 2025 at 05:36:08PM +0200, Dario Binacchi wrote:
> > Convert Raspberry Pi firmware 7" touchscreen controller device tree
> > binding to json-schema.
> >
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> >
> > ---
> >
> > (no changes since v3)
> >
> > Changes in v3:
> > - Drop firmware-rpi node and use only touchscreen node to fix warnings
> > you can see in
> > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250913092707.1005616-3-dario.binacchi@amarulasolutions.com/
> >
> > Changes in v2:
> > - Added in v2
> >
> > .../touchscreen/raspberrypi,firmware-ts.txt | 26 ------------
> > .../touchscreen/raspberrypi,firmware-ts.yaml | 40 +++++++++++++++++++
> > 2 files changed, 40 insertions(+), 26 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
> > deleted file mode 100644
> > index 2a1af240ccc3..000000000000
> > --- a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
> > +++ /dev/null
> > @@ -1,26 +0,0 @@
> > -Raspberry Pi firmware based 7" touchscreen
> > -=====================================
> > -
> > -Required properties:
> > - - compatible: "raspberrypi,firmware-ts"
> > -
> > -Optional properties:
> > - - firmware: Reference to RPi's firmware device node
> > - - touchscreen-size-x: See touchscreen.txt
> > - - touchscreen-size-y: See touchscreen.txt
> > - - touchscreen-inverted-x: See touchscreen.txt
> > - - touchscreen-inverted-y: See touchscreen.txt
> > - - touchscreen-swapped-x-y: See touchscreen.txt
> > -
> > -Example:
> > -
> > -firmware: firmware-rpi {
> > - compatible = "raspberrypi,bcm2835-firmware";
> > - mboxes = <&mailbox>;
> > -
> > - ts: touchscreen {
> > - compatible = "raspberrypi,firmware-ts";
> > - touchscreen-size-x = <800>;
> > - touchscreen-size-y = <480>;
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.yaml
> > new file mode 100644
> > index 000000000000..697c508326b3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.yaml
> > @@ -0,0 +1,40 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/touchscreen/raspberrypi,firmware-ts.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Raspberry Pi firmware based 7" touchscreen
> > +
> > +maintainers:
> > + - Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > +
> > +allOf:
> > + - $ref: touchscreen.yaml#
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - raspberrypi,firmware-ts
> > +
> > + firmware:
> > + description: Phandle to RPi's firmware device node.
>
> deprecated: true
>
> It should be a child node.
Should I add the touchscreen node to
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
and remove Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.yaml
from this patch?
Thanks and regards,
Dario
>
> > +
> > + touchscreen-size-x: true
> > + touchscreen-size-y: true
> > + touchscreen-inverted-x: true
> > + touchscreen-inverted-y: true
> > + touchscreen-swapped-x-y: true
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > +
> > +examples:
> > + - |
> > + touchscreen {
> > + compatible = "raspberrypi,firmware-ts";
> > + touchscreen-size-x = <800>;
> > + touchscreen-size-y = <480>;
> > + };
> > --
> > 2.43.0
> >
> > base-commit: 8b789f2b7602a818e7c7488c74414fae21392b63
> > branch: drop-touchscreen.txt
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binacchi@amarulasolutions.com
__________________________________
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@amarulasolutions.com
www.amarulasolutions.com
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: touchscreen: convert eeti bindings to json schema
From: Frank Li @ 2025-09-18 21:06 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Conor Dooley, Dmitry Torokhov,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-input
In-Reply-To: <20250914203812.1055696-2-dario.binacchi@amarulasolutions.com>
On Sun, Sep 14, 2025 at 10:37:53PM +0200, Dario Binacchi wrote:
> Convert EETI touchscreen controller device tree binding to json-schema.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Added in v2
>
> .../bindings/input/touchscreen/eeti.txt | 30 ---------
> .../bindings/input/touchscreen/eeti.yaml | 62 +++++++++++++++++++
I think it should be merged into
Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
Just add new compatible string "eeti,exc3000-i2c"
or direct use eeti,exc3000 and remove .../bindings/input/touchscreen/eeti.txt
Frank
> 2 files changed, 62 insertions(+), 30 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/eeti.txt
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/eeti.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt b/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
> deleted file mode 100644
> index 32b3712c916e..000000000000
> --- a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -Bindings for EETI touchscreen controller
> -
> -Required properties:
> -- compatible: should be "eeti,exc3000-i2c"
> -- reg: I2C address of the chip. Should be set to <0xa>
> -- interrupts: interrupt to which the chip is connected
> -
> -Optional properties:
> -- attn-gpios: A handle to a GPIO to check whether interrupt is still
> - latched. This is necessary for platforms that lack
> - support for level-triggered IRQs.
> -
> -The following optional properties described in touchscreen.txt are
> -also supported:
> -
> -- touchscreen-inverted-x
> -- touchscreen-inverted-y
> -- touchscreen-swapped-x-y
> -
> -Example:
> -
> -i2c-master {
> - touchscreen@a {
> - compatible = "eeti,exc3000-i2c";
> - reg = <0xa>;
> - interrupt-parent = <&gpio>;
> - interrupts = <123 IRQ_TYPE_EDGE_RISING>;
> - attn-gpios = <&gpio 123 GPIO_ACTIVE_HIGH>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti.yaml
> new file mode 100644
> index 000000000000..97027914d6a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/eeti.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/eeti.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: EETI touchscreen controller
> +
> +description:
> + EETI I2C driven touchscreen controller.
> +
> +maintainers:
> + - Dario Binacchi <dario.binacchi@amarulasolutions.com>
> +
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - eeti,exc3000-i2c
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + attn-gpios:
> + maxItems: 1
> + description: Phandle to a GPIO to check whether interrupt is still
> + latched. This is necessary for platforms that lack
> + support for level-triggered IRQs.
> +
> + touchscreen-inverted-x: true
> + touchscreen-inverted-y: true
> + touchscreen-swapped-x-y: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@a {
> + compatible = "eeti,exc3000-i2c";
> + reg = <0xa>;
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <123 IRQ_TYPE_EDGE_RISING>;
> + attn-gpios = <&gpio 123 GPIO_ACTIVE_HIGH>;
> + };
> + };
> --
> 2.43.0
>
> base-commit: df86f912b45c20e236060321c85fe35437e9325d
> branch: drop-touchscreen.txt
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: touchscreen: convert bu21013 bindings to json schema
From: Dmitry Torokhov @ 2025-09-18 21:29 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-input
In-Reply-To: <20250918153630.2535208-1-dario.binacchi@amarulasolutions.com>
On Thu, Sep 18, 2025 at 05:36:06PM +0200, Dario Binacchi wrote:
> Convert Rohm BU21013 I2C touchscreen controller device tree binding to
> json-schema.
>
> Additional changes:
> - Replace <supply_name>-supply with avdd-supply to match example and
> existing DTS.
> - Add reset-gpios in the example because it is required.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 4/5] dt-bindings: touchscreen: convert zet6223 bindings to json schema
From: Dmitry Torokhov @ 2025-09-18 21:29 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Conor Dooley, Krzysztof Kozlowski,
Rob Herring, devicetree, linux-input
In-Reply-To: <20250918153630.2535208-4-dario.binacchi@amarulasolutions.com>
On Thu, Sep 18, 2025 at 05:36:09PM +0200, Dario Binacchi wrote:
> Convert Zeitec ZET6223 touchscreen controller device tree binding to
> json-schema.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH 0/6] HID: intel-ish-hid: Various power management improvements for hibernation
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
This patch series introduces several improvements to the power management and hibernation
handling in the intel-ish-hid driver. Key changes include:
- Separating hibernate callbacks in dev_pm_ops for clearer power state transitions
- Using IPC RESET in ish_wakeup() to ensure reliable device wakeup
- Scheduling firmware reset work on RESET_NOTIFY/ACK for robust recovery
- Resetting client state on resume from D3 to maintain consistency
- Enhancing resume logic in ishtp-hid-client for better stability
These patches enhance reliability, improve power management flow. All changes
have been validated on TwinLake (ISH 5.4), ArrowLake (ISH 5.6), and PantherLake
(ISH 5.8) platforms.
Zhang Lixu (6):
HID: intel-ish-hid: Add ishtp_get_connection_state() interface
HID: intel-ishtp-hid: Clear suspended flag only after connected on
resume
HID: intel-ish-ipc: Reset clients state on resume from D3
HID: intel-ish-hid: ipc: Always schedule FW reset work on
RESET_NOTIFY/ACK
HID: intel-ish-hid: Use IPC RESET instead of void message in
ish_wakeup()
HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_ops
drivers/hid/intel-ish-hid/ipc/ipc.c | 73 +++++++++-----------
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 29 ++++++--
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 11 ++-
drivers/hid/intel-ish-hid/ishtp/client.c | 6 ++
include/linux/intel-ish-client-if.h | 1 +
5 files changed, 72 insertions(+), 48 deletions(-)
base-commit: 8f7f8b1b3f4c613dd886f53f768f82816b41eaa3
--
2.43.0
^ permalink raw reply
* [PATCH 1/6] HID: intel-ish-hid: Add ishtp_get_connection_state() interface
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing
ishtp client drivers to retrieve the current connection state.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ishtp/client.c | 6 ++++++
include/linux/intel-ish-client-if.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/hid/intel-ish-hid/ishtp/client.c b/drivers/hid/intel-ish-hid/ishtp/client.c
index 21a2c0773cc2..40f510b1c072 100644
--- a/drivers/hid/intel-ish-hid/ishtp/client.c
+++ b/drivers/hid/intel-ish-hid/ishtp/client.c
@@ -1261,6 +1261,12 @@ void ishtp_set_connection_state(struct ishtp_cl *cl, int state)
}
EXPORT_SYMBOL(ishtp_set_connection_state);
+int ishtp_get_connection_state(struct ishtp_cl *cl)
+{
+ return cl->state;
+}
+EXPORT_SYMBOL(ishtp_get_connection_state);
+
void ishtp_cl_set_fw_client_id(struct ishtp_cl *cl, int fw_client_id)
{
cl->fw_client_id = fw_client_id;
diff --git a/include/linux/intel-ish-client-if.h b/include/linux/intel-ish-client-if.h
index dfbf7d9d7bb5..cccdf60b0247 100644
--- a/include/linux/intel-ish-client-if.h
+++ b/include/linux/intel-ish-client-if.h
@@ -107,6 +107,7 @@ struct ishtp_device *ishtp_get_ishtp_device(struct ishtp_cl *cl);
void ishtp_set_tx_ring_size(struct ishtp_cl *cl, int size);
void ishtp_set_rx_ring_size(struct ishtp_cl *cl, int size);
void ishtp_set_connection_state(struct ishtp_cl *cl, int state);
+int ishtp_get_connection_state(struct ishtp_cl *cl);
void ishtp_cl_set_fw_client_id(struct ishtp_cl *cl, int fw_client_id);
void ishtp_put_device(struct ishtp_cl_device *cl_dev);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/6] HID: intel-ishtp-hid: Clear suspended flag only after connected on resume
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered
on from D3, causing all previous client connections between the firmware
and driver to be lost. Although the underlying ishtp bus driver initiates a
client reconnection flow, this process is asynchronous. As a result, when
hid_ishtp_cl_resume_handler() is executed, the connection may not have been
re-established yet. Clearing the suspended flag prematurely in this
scenario can lead to a timeout when the upper-layer HID sensor driver set
feature during resume.
To prevent such timeouts, only clear the suspended flag after confirming
that the connection state is ISHTP_CL_CONNECTED.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
index d8c3c54a8c0f..7fb554482100 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -757,8 +757,15 @@ static void hid_ishtp_cl_resume_handler(struct work_struct *work)
struct ishtp_cl *hid_ishtp_cl = client_data->hid_ishtp_cl;
if (ishtp_wait_resume(ishtp_get_ishtp_device(hid_ishtp_cl))) {
- client_data->suspended = false;
- wake_up_interruptible(&client_data->ishtp_resume_wait);
+ /*
+ * Clear the suspended flag only when the connection is established.
+ * If the connection is not established, the suspended flag will be cleared after
+ * the connection is made.
+ */
+ if (ishtp_get_connection_state(hid_ishtp_cl) == ISHTP_CL_CONNECTED) {
+ client_data->suspended = false;
+ wake_up_interruptible(&client_data->ishtp_resume_wait);
+ }
} else {
hid_ishtp_trace(client_data, "hid client: wait for resume timed out");
dev_err(cl_data_to_dev(client_data), "wait for resume timed out");
--
2.43.0
^ permalink raw reply related
* [PATCH 3/6] HID: intel-ish-ipc: Reset clients state on resume from D3
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
When ISH resumes from D3, the connection between ishtp clients and firmware
is lost. The ish_resume() function schedules resume_work asynchronously to
re-initiate the connection and then returns immediately. This can cause a
race where the upper-layer ishtp client driver's .resume() may execute
before the connection is fully restored, leaving the client in a stale
connected state. If the client sends messages during this window, the
firmware cannot respond.
To avoid this, reset the ishtp clients' state before returning from
ish_resume() if ISH is resuming from D3.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 9d150ce234f2..ccd195adbbd6 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -147,6 +147,12 @@ static inline bool ish_should_enter_d0i3(struct pci_dev *pdev)
static inline bool ish_should_leave_d0i3(struct pci_dev *pdev)
{
+ struct ishtp_device *dev = pci_get_drvdata(pdev);
+ u32 fwsts = dev->ops->get_fw_status(dev);
+
+ if (dev->suspend_flag || !IPC_IS_ISH_ILUP(fwsts))
+ return false;
+
return !pm_resume_via_firmware() || pdev->device == PCI_DEVICE_ID_INTEL_ISH_CHV;
}
@@ -277,10 +283,8 @@ static void __maybe_unused ish_resume_handler(struct work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
- uint32_t fwsts = dev->ops->get_fw_status(dev);
- if (ish_should_leave_d0i3(pdev) && !dev->suspend_flag
- && IPC_IS_ISH_ILUP(fwsts)) {
+ if (ish_should_leave_d0i3(pdev)) {
if (device_may_wakeup(&pdev->dev))
disable_irq_wake(pdev->irq);
@@ -384,6 +388,10 @@ static int __maybe_unused ish_resume(struct device *device)
ish_resume_device = device;
dev->resume_flag = 1;
+ /* If ISH resume from D3, reset ishtp clients before return */
+ if (!ish_should_leave_d0i3(pdev))
+ ishtp_reset_handler(dev);
+
schedule_work(&resume_work);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH 4/6] HID: intel-ish-hid: ipc: Always schedule FW reset work on RESET_NOTIFY/ACK
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate
an FW reset handshake. Upon receiving this, the peer should reply with
MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset
handshake work function when receiving either MNG_RESET_NOTIFY or
MNG_RESET_NOTIFY_ACK.
Previously, driver only scheduled the work function on MNG_RESET_NOTIFY.
This patch ensures the work function is scheduled on both messages, but
only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 39 ++++++++++++++---------------
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 3ddaa2cd39d5..740566146f29 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -481,6 +481,20 @@ static int timed_wait_for_timeout(struct ishtp_device *dev, int condition,
return ret;
}
+static void ish_send_reset_notify_ack(struct ishtp_device *dev)
+{
+ /* Read reset ID */
+ u32 reset_id = ish_reg_read(dev, IPC_REG_ISH2HOST_MSG) & 0xFFFF;
+
+ /*
+ * Set HOST2ISH.ILUP. Apparently we need this BEFORE sending
+ * RESET_NOTIFY_ACK - FW will be checking for it
+ */
+ ish_set_host_rdy(dev);
+ /* Send RESET_NOTIFY_ACK (with reset_id) */
+ ipc_send_mng_msg(dev, MNG_RESET_NOTIFY_ACK, &reset_id, sizeof(u32));
+}
+
#define TIME_SLICE_FOR_FW_RDY_MS 100
#define TIME_SLICE_FOR_INPUT_RDY_MS 100
#define TIMEOUT_FOR_FW_RDY_MS 2000
@@ -496,13 +510,9 @@ static int timed_wait_for_timeout(struct ishtp_device *dev, int condition,
*/
static int ish_fw_reset_handler(struct ishtp_device *dev)
{
- uint32_t reset_id;
unsigned long flags;
int ret;
- /* Read reset ID */
- reset_id = ish_reg_read(dev, IPC_REG_ISH2HOST_MSG) & 0xFFFF;
-
/* Clear IPC output queue */
spin_lock_irqsave(&dev->wr_processing_spinlock, flags);
list_splice_init(&dev->wr_processing_list, &dev->wr_free_list);
@@ -521,15 +531,6 @@ static int ish_fw_reset_handler(struct ishtp_device *dev)
/* Send clock sync at once after reset */
ishtp_dev->prev_sync = 0;
- /*
- * Set HOST2ISH.ILUP. Apparently we need this BEFORE sending
- * RESET_NOTIFY_ACK - FW will be checking for it
- */
- ish_set_host_rdy(dev);
- /* Send RESET_NOTIFY_ACK (with reset_id) */
- ipc_send_mng_msg(dev, MNG_RESET_NOTIFY_ACK, &reset_id,
- sizeof(uint32_t));
-
/* Wait for ISH FW'es ILUP and ISHTP_READY */
ret = timed_wait_for_timeout(dev, WAIT_FOR_FW_RDY,
TIME_SLICE_FOR_FW_RDY_MS,
@@ -563,8 +564,6 @@ static void fw_reset_work_fn(struct work_struct *work)
if (!rv) {
/* ISH is ILUP & ISHTP-ready. Restart ISHTP */
msleep_interruptible(TIMEOUT_FOR_HW_RDY_MS);
- ishtp_dev->recvd_hw_ready = 1;
- wake_up_interruptible(&ishtp_dev->wait_hw_ready);
/* ISHTP notification in IPC_RESET sequence completion */
if (!work_pending(work))
@@ -625,15 +624,14 @@ static void recv_ipc(struct ishtp_device *dev, uint32_t doorbell_val)
break;
case MNG_RESET_NOTIFY:
- if (!ishtp_dev) {
- ishtp_dev = dev;
- }
- schedule_work(&fw_reset_work);
- break;
+ ish_send_reset_notify_ack(ishtp_dev);
+ fallthrough;
case MNG_RESET_NOTIFY_ACK:
dev->recvd_hw_ready = 1;
wake_up_interruptible(&dev->wait_hw_ready);
+ if (!work_pending(&fw_reset_work))
+ schedule_work(&fw_reset_work);
break;
}
}
@@ -982,6 +980,7 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
list_add_tail(&tx_buf->link, &dev->wr_free_list);
}
+ ishtp_dev = dev;
ret = devm_work_autocancel(&pdev->dev, &fw_reset_work, fw_reset_work_fn);
if (ret) {
dev_err(dev->devc, "Failed to initialise FW reset work\n");
--
2.43.0
^ permalink raw reply related
* [PATCH 5/6] HID: intel-ish-hid: Use IPC RESET instead of void message in ish_wakeup()
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
On ISH power-up, the bootloader enters sleep after preparing to load the
main firmware, waiting for the driver to be ready. When the driver is
ready, it sends a void message to wake up the bootloader and load the main
firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for
handshake.
This void message-based IPC handshake only works if the main firmware has
not been loaded. During hibernation resume, if the restore kernel has the
ISH driver, the driver wakes up the bootloader to load the main firmware
and perform IPC handshake. However, when switching to the image kernel,
since the main firmware is already loaded, sending a void message in the
.restore() callback does not trigger IPC handshake.
By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of
a void message, we can explicitly wake up the bootloader and perform IPC
handshake, regardless of the firmware state. Additionally, since
ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for
recvd_hw_ready in ish_hw_start() is removed.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 34 ++++++++++-------------------
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 740566146f29..b5cd17994df4 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -728,22 +728,28 @@ int ish_disable_dma(struct ishtp_device *dev)
* ish_wakeup() - wakeup ishfw from waiting-for-host state
* @dev: ishtp device pointer
*
- * Set the dma enable bit and send a void message to FW,
+ * Set the dma enable bit and send a IPC RESET message to FW,
* it wil wakeup FW from waiting-for-host state.
+ *
+ * Return: 0 for success else error code.
*/
-static void ish_wakeup(struct ishtp_device *dev)
+static int ish_wakeup(struct ishtp_device *dev)
{
+ int ret;
+
/* Set dma enable bit */
ish_reg_write(dev, IPC_REG_ISH_RMP2, IPC_RMP2_DMA_ENABLED);
/*
- * Send 0 IPC message so that ISH FW wakes up if it was already
+ * Send IPC RESET message so that ISH FW wakes up if it was already
* asleep.
*/
- ish_reg_write(dev, IPC_REG_HOST2ISH_DRBL, IPC_DRBL_BUSY_BIT);
+ ret = ish_ipc_reset(dev);
/* Flush writes to doorbell and REMAP2 */
ish_reg_read(dev, IPC_REG_ISH_HOST_FWSTS);
+
+ return ret;
}
/**
@@ -792,9 +798,7 @@ static int _ish_hw_reset(struct ishtp_device *dev)
pci_write_config_word(pdev, pdev->pm_cap + PCI_PM_CTRL, csr);
/* Now we can enable ISH DMA operation and wakeup ISHFW */
- ish_wakeup(dev);
-
- return 0;
+ return ish_wakeup(dev);
}
/**
@@ -855,21 +859,7 @@ int ish_hw_start(struct ishtp_device *dev)
set_host_ready(dev);
/* After that we can enable ISH DMA operation and wakeup ISHFW */
- ish_wakeup(dev);
-
- /* wait for FW-initiated reset flow */
- if (!dev->recvd_hw_ready)
- wait_event_interruptible_timeout(dev->wait_hw_ready,
- dev->recvd_hw_ready,
- 10 * HZ);
-
- if (!dev->recvd_hw_ready) {
- dev_err(dev->devc,
- "[ishtp-ish]: Timed out waiting for FW-initiated reset\n");
- return -ENODEV;
- }
-
- return 0;
+ return ish_wakeup(dev);
}
/**
--
2.43.0
^ permalink raw reply related
* [PATCH 6/6] HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_ops
From: Zhang Lixu @ 2025-09-19 1:05 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
The same suspend and resume callbacks are used for both suspend-to-RAM/idle
and hibernation. These callbacks invoke pm_suspend_via_firmware() and
pm_resume_via_firmware(), respectively. In the .freeze() of hibernation,
pm_suspend_via_firmware() returns false, causing the driver to put ISH into
D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true,
leading the driver to treat ISH as resuming from D3 instead of D0i3. The
asymmetric behavior between .freeze() and .thaw() during hibernation can
cause the client connection states on the firmware side and the driver side
to become inconsistent.
To address the inconsistent client connection states issue, separate
hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does
not need to save any firmware-related state when entering hibernation, it
is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus
from changing the ISH power state. No actions are required in .thaw().
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index ccd195adbbd6..36445d2bb927 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -397,7 +397,20 @@ static int __maybe_unused ish_resume(struct device *device)
return 0;
}
-static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
+static int __maybe_unused ish_freeze(struct device *device)
+{
+ struct pci_dev *pdev = to_pci_dev(device);
+
+ return pci_save_state(pdev);
+}
+
+static const struct dev_pm_ops __maybe_unused ish_pm_ops = {
+ .suspend = pm_sleep_ptr(ish_suspend),
+ .resume = pm_sleep_ptr(ish_resume),
+ .freeze = pm_sleep_ptr(ish_freeze),
+ .restore = pm_sleep_ptr(ish_resume),
+ .poweroff = pm_sleep_ptr(ish_suspend),
+};
static ssize_t base_version_show(struct device *cdev,
struct device_attribute *attr, char *buf)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/3] input: mouse: trackpoint: Add doubletap enable/disable support
From: Dmitry Torokhov @ 2025-09-19 1:12 UTC (permalink / raw)
To: Hans de Goede
Cc: Vishnu Sankar, hmh, ilpo.jarvinen, derekjohn.clark,
mpearson-lenovo, linux-input, linux-kernel, ibm-acpi-devel,
platform-driver-x86, vsankar
In-Reply-To: <6e834cb7-565b-4a4b-bf90-4765f5fc9cc9@kernel.org>
On Thu, Sep 18, 2025 at 09:31:47AM +0200, Hans de Goede wrote:
> Hi Vishnu,
>
> On 18-Sep-25 4:37 AM, Vishnu Sankar wrote:
> > Hello all,
> >
> > Do we have any questions or concerns?
> > Thanks in advance!
> >
> > On Mon, Sep 1, 2025 at 10:53 PM Vishnu Sankar <vishnuocv@gmail.com> wrote:
> >>
> >> Add support for enabling and disabling doubletap on TrackPoint devices
> >> that support this functionality. The feature is detected using firmware
> >> ID and exposed via sysfs as `doubletap_enabled`.
>
> Hmm, you seem to be using a firmware ID prefix match, combined with
> a deny list of some firmware IDs with that prefix which do not support
> this. How do we know this deny list is complete?
>
> Also as Dmitry says you really should use the is_visible() callback
> to not show the attribute at all on unsupported systems.
>
> >> The feature is only available on newer ThinkPads (2023 and later).The driver
> >> exposes this capability via a new sysfs attribute:
> >> "/sys/bus/serio/devices/seriox/doubletap_enabled".
> >>
> >> The attribute is only created if the device is detected to be capable of
> >> doubletap via firmware and variant ID checks. This functionality will be
> >> used by platform drivers such as thinkpad_acpi to expose and control doubletap
> >> via user interfaces.
>
> Hmm, you refer to thinkpad_acpi as a possible consumer of this
> functionality. But you only add a sysfs interface.
>
> thinkpad_acpi will need some in kernel interface to use this.
>
> Which brings me to my main question: thinkpad_acpi is the driver
> receiving the doubletap events since these are send out-of-bound
> and not through the ps/2 trackpoint protocol.
>
> thinkpad_acpi already has the capability to filter out these doubletap
> events and report nothing. Why is it necessary / better to disable
> the doubletap at the trackpoint fw-level, rather then just filtering
> it at the thinkpad_acpi level ?
>
> I don't really see a big advantage in filtering these events at
> the fw-level rather then in the kernel and we already have the
> in kernel filtering.
That is an excellent observation, thank you Hans. The frequency of these
events should be extremely low, so cost of simply ignoring events should
be miniscule...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space
From: Dmitry Torokhov @ 2025-09-19 5:12 UTC (permalink / raw)
To: Anton Khirnov
Cc: Corentin Chary, Luke D. Jones, Hans de Goede, Ilpo Järvinen,
platform-driver-x86, linux-kernel, linux-input
In-Reply-To: <20250714150756.21197-2-anton@khirnov.net>
Hi Anton,
On Mon, Jul 14, 2025 at 05:07:57PM +0200, Anton Khirnov wrote:
> The Asus ExpertBook B9 laptop sends a WMI event when Fn+space is
> pressed. Since I could not find any information on what this combination
> is intended to do on this or any other Asus laptop, allocate a
> KEY_FN_SPACE keycode for it.
>
> Signed-off-by: Anton Khirnov <anton@khirnov.net>
> ---
> include/uapi/linux/input-event-codes.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 3b2524e4b667..a49b0782fd8a 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -548,6 +548,7 @@
> #define KEY_FN_S 0x1e3
> #define KEY_FN_B 0x1e4
> #define KEY_FN_RIGHT_SHIFT 0x1e5
> +#define KEY_FN_SPACE 0x1e6
I'd rather we did not add more codes with no defined meaning. I regret
that we have KEY_FN_* (with the exception of KEY_FN itself). Since
nobody knows what this key is supposed to do maybe map it to
KEY_RESERVED and whoever wants to use it can map it to a concrete key
code via udev?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space
From: Mario Limonciello (AMD) (kernel.org) @ 2025-09-19 5:36 UTC (permalink / raw)
To: Dmitry Torokhov, Anton Khirnov
Cc: Corentin Chary, Luke D. Jones, Hans de Goede, Ilpo Järvinen,
platform-driver-x86, linux-kernel, linux-input
In-Reply-To: <u3qzdpgoe2appwnmv2rkcmyg6htrmltna3geymp7llootdwbts@ycmhljii34bz>
On 9/19/2025 12:12 AM, Dmitry Torokhov wrote:
> Hi Anton,
>
> On Mon, Jul 14, 2025 at 05:07:57PM +0200, Anton Khirnov wrote:
>> The Asus ExpertBook B9 laptop sends a WMI event when Fn+space is
>> pressed. Since I could not find any information on what this combination
>> is intended to do on this or any other Asus laptop, allocate a
>> KEY_FN_SPACE keycode for it.
>>
>> Signed-off-by: Anton Khirnov <anton@khirnov.net>
>> ---
>> include/uapi/linux/input-event-codes.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
>> index 3b2524e4b667..a49b0782fd8a 100644
>> --- a/include/uapi/linux/input-event-codes.h
>> +++ b/include/uapi/linux/input-event-codes.h
>> @@ -548,6 +548,7 @@
>> #define KEY_FN_S 0x1e3
>> #define KEY_FN_B 0x1e4
>> #define KEY_FN_RIGHT_SHIFT 0x1e5
>> +#define KEY_FN_SPACE 0x1e6
>
> I'd rather we did not add more codes with no defined meaning. I regret
> that we have KEY_FN_* (with the exception of KEY_FN itself). Since
> nobody knows what this key is supposed to do maybe map it to
> KEY_RESERVED and whoever wants to use it can map it to a concrete key
> code via udev?
>
> Thanks.
>
Any chance you can look at Windows and see what the key actually does
when you have the matching OEM software installed?
I've seen a bunch of laptops that FN+SPACE turns on/off keyboard
backlight. Maybe that's what it does.
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 6e4a5154934f8c7283452651c4d398d34a46e952
From: kernel test robot @ 2025-09-19 6:06 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: 6e4a5154934f8c7283452651c4d398d34a46e952 dt-bindings: touchscreen: resistive-adc-touch: change to unevaluatedProperties
elapsed time: 1407m
configs tested: 142
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc nsimosci_defconfig gcc-15.1.0
arc randconfig-001-20250918 gcc-8.5.0
arc randconfig-002-20250918 gcc-8.5.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm axm55xx_defconfig clang-22
arm defconfig clang-22
arm mps2_defconfig clang-22
arm randconfig-001-20250918 clang-22
arm randconfig-002-20250918 gcc-8.5.0
arm randconfig-003-20250918 clang-22
arm randconfig-004-20250918 gcc-11.5.0
arm vf610m4_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20250918 clang-22
arm64 randconfig-002-20250918 gcc-11.5.0
arm64 randconfig-003-20250918 clang-22
arm64 randconfig-004-20250918 clang-22
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20250918 gcc-15.1.0
csky randconfig-002-20250918 gcc-15.1.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon defconfig clang-22
hexagon randconfig-001-20250918 clang-22
hexagon randconfig-002-20250918 clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20250918 clang-20
i386 buildonly-randconfig-002-20250918 gcc-14
i386 buildonly-randconfig-003-20250918 gcc-14
i386 buildonly-randconfig-004-20250918 clang-20
i386 buildonly-randconfig-005-20250918 gcc-14
i386 buildonly-randconfig-006-20250918 clang-20
i386 defconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch randconfig-001-20250918 clang-18
loongarch randconfig-002-20250918 clang-18
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k defconfig gcc-15.1.0
m68k m5275evb_defconfig gcc-15.1.0
m68k stmark2_defconfig gcc-15.1.0
microblaze allmodconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips bcm63xx_defconfig clang-22
mips loongson1b_defconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250918 gcc-10.5.0
nios2 randconfig-002-20250918 gcc-8.5.0
openrisc allnoconfig gcc-15.1.0
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250918 gcc-12.5.0
parisc randconfig-002-20250918 gcc-8.5.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc mpc834x_itx_defconfig clang-16
powerpc randconfig-001-20250918 gcc-9.5.0
powerpc randconfig-002-20250918 clang-17
powerpc randconfig-003-20250918 clang-19
powerpc64 randconfig-001-20250918 gcc-8.5.0
powerpc64 randconfig-002-20250918 gcc-14.3.0
powerpc64 randconfig-003-20250918 clang-22
riscv allmodconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv nommu_virt_defconfig clang-22
riscv randconfig-001-20250918 clang-22
riscv randconfig-002-20250918 gcc-9.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 randconfig-001-20250918 gcc-11.5.0
s390 randconfig-002-20250918 gcc-8.5.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh randconfig-001-20250918 gcc-15.1.0
sh randconfig-002-20250918 gcc-10.5.0
sh sdk7780_defconfig gcc-15.1.0
sh sh7770_generic_defconfig gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250918 gcc-11.5.0
sparc randconfig-002-20250918 gcc-15.1.0
sparc sparc32_defconfig gcc-15.1.0
sparc64 defconfig clang-20
sparc64 randconfig-001-20250918 clang-20
sparc64 randconfig-002-20250918 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um defconfig clang-22
um i386_defconfig gcc-14
um randconfig-001-20250918 clang-22
um randconfig-002-20250918 clang-18
um x86_64_defconfig clang-22
x86_64 alldefconfig gcc-14
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250918 clang-20
x86_64 buildonly-randconfig-002-20250918 clang-20
x86_64 buildonly-randconfig-003-20250918 clang-20
x86_64 buildonly-randconfig-004-20250918 clang-20
x86_64 buildonly-randconfig-005-20250918 clang-20
x86_64 buildonly-randconfig-006-20250918 clang-20
x86_64 defconfig gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250918 gcc-8.5.0
xtensa randconfig-002-20250918 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from level to edge detection
From: Even Xu @ 2025-09-19 7:09 UTC (permalink / raw)
To: jikos, bentiss, srinivas.pandruvada
Cc: linux-input, linux-kernel, Even Xu, Rui Zhang
The original implementation used level detection for the first interrupt
after device reset to avoid potential interrupt line noise and missed
interrupts during the initialization phase. However, this approach
introduced unintended side effects when tested with certain touch panels,
including:
- Delayed hardware interrupt response
- Multiple spurious interrupt triggers
Switching back to edge detection for the first interrupt resolves these
issues while maintaining reliable interrupt handling.
Extensive testing across multiple platforms with touch panels from
various vendors confirms this change introduces no regressions.
Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation")
Tested-by: Rui Zhang <rui1.zhang@intel.com>
Signed-off-by: Even Xu <even.xu@intel.com>
---
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
index e6ba2ddcc9cb..16f780bc879b 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
@@ -280,8 +280,7 @@ int reset_tic(struct quickspi_device *qsdev)
qsdev->reset_ack = false;
- /* First interrupt uses level trigger to avoid missing interrupt */
- thc_int_trigger_type_select(qsdev->thc_hw, false);
+ thc_int_trigger_type_select(qsdev->thc_hw, true);
ret = acpi_tic_reset(qsdev);
if (ret)
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space
From: Anton Khirnov @ 2025-09-19 7:32 UTC (permalink / raw)
To: Mario Limonciello (AMD) (kernel.org)
Cc: Dmitry Torokhov, Corentin Chary, Luke D. Jones, Hans de Goede,
Ilpo Järvinen, platform-driver-x86, linux-kernel,
linux-input
In-Reply-To: <c49cf225-c508-4e23-8786-5110a166d7c4@kernel.org>
Hi Mario,
Quoting Mario Limonciello (AMD) (kernel.org) (2025-09-19 07:36:31)
> On 9/19/2025 12:12 AM, Dmitry Torokhov wrote:
> > Hi Anton,
> >
> > On Mon, Jul 14, 2025 at 05:07:57PM +0200, Anton Khirnov wrote:
> >> The Asus ExpertBook B9 laptop sends a WMI event when Fn+space is
> >> pressed. Since I could not find any information on what this combination
> >> is intended to do on this or any other Asus laptop, allocate a
> >> KEY_FN_SPACE keycode for it.
> >>
> >> Signed-off-by: Anton Khirnov <anton@khirnov.net>
> >> ---
> >> include/uapi/linux/input-event-codes.h | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> >> index 3b2524e4b667..a49b0782fd8a 100644
> >> --- a/include/uapi/linux/input-event-codes.h
> >> +++ b/include/uapi/linux/input-event-codes.h
> >> @@ -548,6 +548,7 @@
> >> #define KEY_FN_S 0x1e3
> >> #define KEY_FN_B 0x1e4
> >> #define KEY_FN_RIGHT_SHIFT 0x1e5
> >> +#define KEY_FN_SPACE 0x1e6
> >
> > I'd rather we did not add more codes with no defined meaning. I regret
> > that we have KEY_FN_* (with the exception of KEY_FN itself). Since
> > nobody knows what this key is supposed to do maybe map it to
> > KEY_RESERVED and whoever wants to use it can map it to a concrete key
> > code via udev?
> >
> > Thanks.
> >
>
> Any chance you can look at Windows and see what the key actually does
> when you have the matching OEM software installed?
Unfortunately I removed Windows from this machine right after buying it,
and reinstalling it would be too invasive. I did ask someone to test on
a different Asus laptop running Windows, the key did not seem to do
anything.
> I've seen a bunch of laptops that FN+SPACE turns on/off keyboard
> backlight. Maybe that's what it does.
Fn+F7 toggles keyboard backlight on this laptop, so probably not. I'm
willing to believe it's a leftover from older hardware where it did do
something and they just forgot to disable it.
Cheers,
--
Anton Khirnov
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space
From: Anton Khirnov @ 2025-09-19 7:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Corentin Chary, Luke D. Jones, Hans de Goede, Ilpo Järvinen,
platform-driver-x86, linux-kernel, linux-input
In-Reply-To: <u3qzdpgoe2appwnmv2rkcmyg6htrmltna3geymp7llootdwbts@ycmhljii34bz>
Hi Dmitry,
Quoting Dmitry Torokhov (2025-09-19 07:12:38)
> Hi Anton,
>
> On Mon, Jul 14, 2025 at 05:07:57PM +0200, Anton Khirnov wrote:
> > The Asus ExpertBook B9 laptop sends a WMI event when Fn+space is
> > pressed. Since I could not find any information on what this combination
> > is intended to do on this or any other Asus laptop, allocate a
> > KEY_FN_SPACE keycode for it.
> >
> > Signed-off-by: Anton Khirnov <anton@khirnov.net>
> > ---
> > include/uapi/linux/input-event-codes.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> > index 3b2524e4b667..a49b0782fd8a 100644
> > --- a/include/uapi/linux/input-event-codes.h
> > +++ b/include/uapi/linux/input-event-codes.h
> > @@ -548,6 +548,7 @@
> > #define KEY_FN_S 0x1e3
> > #define KEY_FN_B 0x1e4
> > #define KEY_FN_RIGHT_SHIFT 0x1e5
> > +#define KEY_FN_SPACE 0x1e6
>
> I'd rather we did not add more codes with no defined meaning. I regret
> that we have KEY_FN_* (with the exception of KEY_FN itself). Since
> nobody knows what this key is supposed to do maybe map it to
> KEY_RESERVED and whoever wants to use it can map it to a concrete key
> code via udev?
The problem with that approach is that on this laptop we have TWO keys
with unknown meanings - fn+space and fn+f (KEY_FN_F already exists).
Using KEY_RESERVED for one of them would be inconsistent then.
Could you elaborate on why are you against KEY_FN_* codes? I understand
they can be abused, but in some cases (such as this one) it genuinely
seems the least bad way to characterize a key.
Cheers,
--
Anton Khirnov
^ permalink raw reply
* RE: [PATCH v3 RESEND] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: Xu, Even @ 2025-09-19 7:56 UTC (permalink / raw)
To: Sun, Xinpeng, jikos@kernel.org, bentiss@kernel.org
Cc: srinivas.pandruvada@linux.intel.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Zhang, Rui1
In-Reply-To: <20250917015344.1169412-1-xinpeng.sun@intel.com>
> -----Original Message-----
> From: Sun, Xinpeng <xinpeng.sun@intel.com>
> Sent: Wednesday, September 17, 2025 9:54 AM
> To: jikos@kernel.org; bentiss@kernel.org
> Cc: srinivas.pandruvada@linux.intel.com; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; Xu, Even <even.xu@intel.com>; Sun, Xinpeng
> <xinpeng.sun@intel.com>; Zhang, Rui1 <rui1.zhang@intel.com>
> Subject: [PATCH v3 RESEND] hid: intel-thc-hid: intel-quicki2c: support ACPI config
> for advanced features
>
> There is a new BIOS enhancement that adds the capability to configure the
> following two features of I2C subsystem introduced in commit 1ed0b48
> ("Intel-thc: Introduce max input size control") and commit 3f2a921
> ("Intel-thc: Introduce interrupt delay control"):
> - Max input size control
> - Interrupt delay control
>
> As BIOS is used for the configuration of these two features, change driver data
> usage to indicate hardware capability, and add corresponding ACPI configuration
> support in QuickI2C driver.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
> Tested-by: Rui Zhang <rui1.zhang@intel.com>
>
> ---
> Changes in v3:
> - remove unnecessary initialization of local variables Changes in v2:
> - refine the commit message
> ---
> .../intel-quicki2c/pci-quicki2c.c | 39 +++++++++++++++----
> .../intel-quicki2c/quicki2c-dev.h | 24 +++++++++++-
> 2 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 854926b3cfd4..3ce5a692b92b 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -23,6 +23,7 @@
>
> static struct quicki2c_ddata ptl_ddata = {
> .max_detect_size = MAX_RX_DETECT_SIZE_PTL,
> + .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
> };
>
> /* THC QuickI2C ACPI method to get device properties */ @@ -200,6 +201,21
> @@ static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
> return -EOPNOTSUPP;
> }
>
> + if (qcdev->ddata) {
> + qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
> + qcdev->i2c_int_delay_enable = i2c_config.INDE;
> +
> + if (i2c_config.FSVL <= qcdev->ddata->max_detect_size)
> + qcdev->i2c_max_frame_size = i2c_config.FSVL;
> + else
> + qcdev->i2c_max_frame_size = qcdev->ddata-
> >max_detect_size;
> +
> + if (i2c_config.INDV <= qcdev->ddata->max_interrupt_delay)
> + qcdev->i2c_int_delay = i2c_config.INDV;
> + else
> + qcdev->i2c_int_delay = qcdev->ddata-
> >max_interrupt_delay;
> + }
> +
> return 0;
> }
>
> @@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct
> quicki2c_device *qcdev)
> * max input length <= THC detect capability, enable the feature with
> device
> * max input length.
> */
> - if (qcdev->ddata->max_detect_size >=
> - le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> - thc_i2c_set_rx_max_size(qcdev->thc_hw,
> - le16_to_cpu(qcdev-
> >dev_desc.max_input_len));
> + if (qcdev->i2c_max_frame_size_enable) {
> + if (qcdev->i2c_max_frame_size >=
> + le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev-
> >dev_desc.max_input_len));
> + } else {
> + dev_warn(qcdev->dev,
> + "Max frame size is smaller than hid max input
> length!");
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev-
> >i2c_max_frame_size));
> + }
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
> }
>
> /* If platform supports interrupt delay feature, enable it with given delay
> */
> - if (qcdev->ddata->interrupt_delay) {
> + if (qcdev->i2c_int_delay_enable) {
> thc_i2c_set_rx_int_delay(qcdev->thc_hw,
> - qcdev->ddata->interrupt_delay);
> + qcdev->i2c_int_delay * 10);
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
> }
> }
> @@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct
> quicki2c_device *qcdev)
> */
> static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev) {
> - if (qcdev->ddata->max_detect_size)
> + if (qcdev->i2c_max_frame_size_enable)
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
>
> - if (qcdev->ddata->interrupt_delay)
> + if (qcdev->i2c_int_delay_enable)
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false); }
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> index d412eafcf9ea..0d423d5dd7a7 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> @@ -38,6 +38,8 @@
>
> /* PTL Max packet size detection capability is 255 Bytes */
> #define MAX_RX_DETECT_SIZE_PTL 255
> +/* Max interrupt delay capability is 2.56ms */
> +#define MAX_RX_INTERRUPT_DELAY 256
>
> /* Default interrupt delay is 1ms, suitable for most devices */
> #define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
> @@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
> * @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Transmit
> HOLD Period
> * @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Receive HOLD
> Period
> * @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in High Speed
> Mode
> + * @FSEN: Maximum Frame Size Feature Enable Control
> + * @FSVL: Maximum Frame Size Value (unit in Bytes)
> + * @INDE: Interrupt Delay Feature Enable Control
> + * @INDV: Interrupt Delay Value (unit in 10 us)
> *
> * Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method,
> used for
> * I2C timing configure.
> @@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
> u64 HMTD;
> u64 HMRD;
> u64 HMSL;
> +
> + u64 FSEN;
> + u64 FSVL;
> + u64 INDE;
> + u64 INDV;
> u8 reserved;
> };
>
> /**
> * struct quicki2c_ddata - Driver specific data for quicki2c device
> * @max_detect_size: Identify max packet size detect for rx
> - * @interrupt_delay: Identify interrupt detect delay for rx
> + * @interrupt_delay: Identify max interrupt detect delay for rx
> */
> struct quicki2c_ddata {
> u32 max_detect_size;
> - u32 interrupt_delay;
> + u32 max_interrupt_delay;
> };
>
> struct device;
> @@ -170,6 +181,10 @@ struct acpi_device;
> * @report_len: The length of input/output report packet
> * @reset_ack_wq: Workqueue for waiting reset response from device
> * @reset_ack: Indicate reset response received or not
> + * @i2c_max_frame_size_enable: Indicate max frame size feature enabled
> + or not
> + * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
> + * @i2c_int_delay_enable: Indicate interrupt delay feature enabled or
> + not
> + * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
> */
> struct quicki2c_device {
> struct device *dev;
> @@ -200,6 +215,11 @@ struct quicki2c_device {
>
> wait_queue_head_t reset_ack_wq;
> bool reset_ack;
> +
> + u32 i2c_max_frame_size_enable;
> + u32 i2c_max_frame_size;
> + u32 i2c_int_delay_enable;
> + u32 i2c_int_delay;
> };
>
Thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
> #endif /* _QUICKI2C_DEV_H_ */
> --
> 2.40.1
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: touchscreen: convert eeti bindings to json schema
From: Dario Binacchi @ 2025-09-19 7:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Conor Dooley, Dmitry Torokhov,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-input
Convert EETI touchscreen controller device tree binding to json-schema.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
Changes in v5:
- Move bindings into eeti,exc3000.yaml
- Remove eeti.yaml
Changes in v2:
- Added in v2
.../input/touchscreen/eeti,exc3000.yaml | 41 ++++++++++++++++---
.../bindings/input/touchscreen/eeti.txt | 30 --------------
2 files changed, 36 insertions(+), 35 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/eeti.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
index 1c7ae05a8c15..13b865d3ee58 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
@@ -9,15 +9,13 @@ title: EETI EXC3000 series touchscreen controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
-allOf:
- - $ref: touchscreen.yaml#
-
properties:
compatible:
oneOf:
- const: eeti,exc3000
- const: eeti,exc80h60
- const: eeti,exc80h84
+ - const: eeti,exc3000-i2c
- items:
- enum:
- eeti,exc81w32
@@ -30,18 +28,34 @@ properties:
maxItems: 1
vdd-supply:
description: Power supply regulator for the chip
+ attn-gpios:
+ maxItems: 1
+ description: Phandle to a GPIO to check whether interrupt is still
+ latched. This is necessary for platforms that lack
+ support for level-triggered IRQs.
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
+allOf:
+ - $ref: touchscreen.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: eeti,exc3000-i2c
+ then:
+ required:
+ - touchscreen-size-x
+ - touchscreen-size-y
+
required:
- compatible
- reg
- interrupts
- - touchscreen-size-x
- - touchscreen-size-y
additionalProperties: false
@@ -51,6 +65,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
+
touchscreen@2a {
compatible = "eeti,exc3000";
reg = <0x2a>;
@@ -62,3 +77,19 @@ examples:
touchscreen-swapped-x-y;
};
};
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include "dt-bindings/interrupt-controller/irq.h"
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@2a {
+ compatible = "eeti,exc3000-i2c";
+ reg = <0x2a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <123 IRQ_TYPE_EDGE_RISING>;
+ attn-gpios = <&gpio 123 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt b/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
deleted file mode 100644
index 32b3712c916e..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Bindings for EETI touchscreen controller
-
-Required properties:
-- compatible: should be "eeti,exc3000-i2c"
-- reg: I2C address of the chip. Should be set to <0xa>
-- interrupts: interrupt to which the chip is connected
-
-Optional properties:
-- attn-gpios: A handle to a GPIO to check whether interrupt is still
- latched. This is necessary for platforms that lack
- support for level-triggered IRQs.
-
-The following optional properties described in touchscreen.txt are
-also supported:
-
-- touchscreen-inverted-x
-- touchscreen-inverted-y
-- touchscreen-swapped-x-y
-
-Example:
-
-i2c-master {
- touchscreen@a {
- compatible = "eeti,exc3000-i2c";
- reg = <0xa>;
- interrupt-parent = <&gpio>;
- interrupts = <123 IRQ_TYPE_EDGE_RISING>;
- attn-gpios = <&gpio 123 GPIO_ACTIVE_HIGH>;
- };
-};
--
2.43.0
base-commit: 8b789f2b7602a818e7c7488c74414fae21392b63
branch: drop-touchscreen.txt
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add touchscreen child node
From: Dario Binacchi @ 2025-09-19 7:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi,
Broadcom internal kernel review list, Conor Dooley,
Dmitry Torokhov, Eric Anholt, Florian Fainelli,
Krzysztof Kozlowski, Ray Jui, Rob Herring, Scott Branden,
Stefan Wahren, devicetree, linux-arm-kernel, linux-input,
linux-rpi-kernel
In-Reply-To: <20250919075823.2557865-1-dario.binacchi@amarulasolutions.com>
Convert Raspberry Pi firmware 7" touchscreen controller device tree
binding to json-schema.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
Changes in v5:
- Move bindings into raspberrypi,bcm2835-firmware.yaml
- Remove raspberrypi,firmware-ts.yaml
- Update the commit message
Changes in v3:
- Drop firmware-rpi node and use only touchscreen node to fix warnings
you can see in
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250913092707.1005616-3-dario.binacchi@amarulasolutions.com/
Changes in v2:
- Added in v2
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 27 +++++++++++++++++++
.../touchscreen/raspberrypi,firmware-ts.txt | 26 ------------------
2 files changed, 27 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 1f84407a73e4..044544c17e8e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -103,6 +103,27 @@ properties:
- compatible
- "#pwm-cells"
+ touchscreen:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: raspberrypi,firmware-ts
+
+ firmware:
+ deprecated: true
+ description: Phandle to RPi's firmware device node.
+
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+ required:
+ - compatible
+
required:
- compatible
- mboxes
@@ -135,5 +156,11 @@ examples:
compatible = "raspberrypi,firmware-poe-pwm";
#pwm-cells = <2>;
};
+
+ ts: touchscreen {
+ compatible = "raspberrypi,firmware-ts";
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
deleted file mode 100644
index 2a1af240ccc3..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Raspberry Pi firmware based 7" touchscreen
-=====================================
-
-Required properties:
- - compatible: "raspberrypi,firmware-ts"
-
-Optional properties:
- - firmware: Reference to RPi's firmware device node
- - touchscreen-size-x: See touchscreen.txt
- - touchscreen-size-y: See touchscreen.txt
- - touchscreen-inverted-x: See touchscreen.txt
- - touchscreen-inverted-y: See touchscreen.txt
- - touchscreen-swapped-x-y: See touchscreen.txt
-
-Example:
-
-firmware: firmware-rpi {
- compatible = "raspberrypi,bcm2835-firmware";
- mboxes = <&mailbox>;
-
- ts: touchscreen {
- compatible = "raspberrypi,firmware-ts";
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- };
-};
--
2.43.0
base-commit: 8b789f2b7602a818e7c7488c74414fae21392b63
branch: drop-touchscreen.txt
^ permalink raw reply related
* [PATCH v5 3/3] dt-bindings: touchscreen: remove touchscreen.txt
From: Dario Binacchi @ 2025-09-19 7:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Rob Herring, Conor Dooley,
Dmitry Torokhov, Krzysztof Kozlowski, devicetree, linux-input
In-Reply-To: <20250919075823.2557865-1-dario.binacchi@amarulasolutions.com>
With commit 1d6204e2f51f ("dt-bindings: touchscreen: Add touchscreen
schema") touchscreen.txt is no longer needed, and since no other file
refers to it, it can be safely removed.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Changes in v5:
- Drop patches:
- v4 1/5 dt-bindings: touchscreen: convert bu21013 bindings to json schema
- v4 4/5 dt-bindings: touchscreen: convert zet6223 bindings to json schema
because accepted
Changes in v4:
- For rohm,bu21013 bindings:
- Drop description from reset-gpios
- Simplify description of avdd-supply
- Rename bu21013.yaml to rohm,bu21013.yaml
- Add Reviewed-by tag of Krzysztof Kozlowski
- For zeitec,zet6223
- Drop "Phandle to the" from vio-supply and vcc-supply dscription
- Rename zet6223.yaml to zeitec,zet6223.yaml
Changes in v2:
- Update the commit message
- Add Acked-by tag of Rob Herring
- Add patches:
- 1/5 dt-bindings: touchscreen: convert bu21013 bindings to json schema
- 2/5 dt-bindings: touchscreen: convert eeti bindings to json schema
- 3/5 dt-bindings: touchscreen: convert raspberrypi,firmware-ts bindings
to json schema
- 4/5 dt-bindings: touchscreen: convert zet6223 bindings to json schema
.../devicetree/bindings/input/touchscreen/touchscreen.txt | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
deleted file mode 100644
index e1adb902d503..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ /dev/null
@@ -1 +0,0 @@
-See touchscreen.yaml
--
2.43.0
base-commit: 8b789f2b7602a818e7c7488c74414fae21392b63
branch: drop-touchscreen.txt
^ permalink raw reply related
* Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
From: José Expósito @ 2025-09-19 8:40 UTC (permalink / raw)
To: 卢国宏, linux-input, linux-kernel, jikos,
bentiss, dmitry.torokhov
Cc: 李鹏, Fei1 Jiang 蒋飞,
宋密密
In-Reply-To: <d2cada7efe8d4436b6e638fa1e0aaefb@xiaomi.com>
Hi 卢国宏,
Thanks for reporting this issue.
In the furure, when reporting bugs, it is prefered to send them to the
mailing list (linux-input@vger.kernel.org and linux-kernel@vger.kernel.org)
to discuss them in public.
Let me forward your email to the mailing list and also CC Dmitry, the
author of that code, who might help us understand the problem.
On Tue, Sep 16, 2025 at 12:29:32PM +0000, 卢国宏 wrote:
> Hi, jose!
>
> We encountered a problem where the zero battery level of the HID device
> in kernel 6.12 was not reported from the kernel to the upper layer.
> I checked the HID protocol and it doesn't say that there is no need to
> report the zero power of the HID device. For details, see page 381 of
> the HID protocol, 31.4 Battery Measures. "Absolute State Of Charge DV
> The predicted remaining battery capacity expressed as a percentage of
> design capacity. (Units are %. The value may be greater than 100%.)".
> However, in the file hid-input.c in kernel 6.12, the following code：
>
> static void hidinput_update_battery(struct hid_device *dev, unsigned int usage,
> int value)
> {
> int capacity;
>
> if (!dev->battery)
> return;
>
> if (hidinput_update_battery_charge_status(dev, usage, value)) {
> power_supply_changed(dev->battery);
> return;
> }
>
> if (value == 0 || value < dev->battery_min || value > dev->battery_max)
> return;
>
> capacity = hidinput_scale_battery_capacity(dev, value);
>
> ......
>
> }
>
> The parameter value is the power level. When the value is 0, the above code
> returns without reporting.
> Is this a problem?
> We're currently experiencing this issue on Android 16. The upper layer of
> Android needs to receive a zero battery level before it can take appropriate
> action.
> Could you please help me evaluate whether we should remove the behavior of
> returning to zero battery?
>
> Thanks!
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
It indeed looks like it could be problematic.
Values are allowed ot be grater than 100, however, I didn't find
any references to negative values. Since it is a percentage, it
make sense to limit it to 0%, i.e., not allowing negative values.
I think that removing the "value == 0" check, or replacing it with
"value < 0" should fix the issue.
By the way, the "Fully Discharged" value (0x00850047), section 31.3.1,
is not handled by the kernel. Do you know if Android handles that
instead or in addition to a 0% battery?
Jose
^ 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