[PATCH v2 0/2] input: add GPIO-based charlieplex keypad

[PATCH v2 0/2] input: add GPIO-based charlieplex keypad

[Hugo Villeneuve]

From: Hugo Villeneuve <hvilleneuve@dimonoff.com>

Hello,
this patch series add a new GPIO charlieplex keypad driver.

I have tested the driver on a custom board with a Solidrun RZ/G2LC SOM
with three charlieplex keyboards, all connected thru a a PCA9416 I2C GPIO
expander.

Link: [v1] https://lore.kernel.org/linux-serial/20250924153740.806444-1-hugo@hugovil.com/raw

Changes for v2:
- Fix yamllint error for example
- Remove unused debug variable (nkeys)
- Remove support for custom linux,no-autorepeat DT property
- Remove support for custom gpio-activelow DT property

Thank you.

Hugo Villeneuve (2):
  dt-bindings: input: add GPIO charlieplex keypad
  Input: charlieplex_keypad: add GPIO charlieplex keypad

 .../input/gpio-charlieplex-keypad.yaml        |  82 +++++++
 MAINTAINERS                                   |   7 +
 drivers/input/keyboard/Kconfig                |  14 ++
 drivers/input/keyboard/Makefile               |   1 +
 drivers/input/keyboard/charlieplex_keypad.c   | 213 ++++++++++++++++++
 5 files changed, 317 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
 create mode 100644 drivers/input/keyboard/charlieplex_keypad.c


base-commit: ed8a4ef29da3821ee3155d3b1925fa67fc92aae2
-- 
2.47.3

[PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Hugo Villeneuve]

From: Hugo Villeneuve <hvilleneuve@dimonoff.com>

Add DT bindings for GPIO charlieplex keypad.

Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
 .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml

diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
new file mode 100644
index 0000000000000..1672491a75a85
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO charlieplex keypad
+
+maintainers:
+  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+description:
+  The charlieplex keypad supports N^2)-N different key combinations (where N is
+  the number of lines). Key presses and releases are detected by configuring
+  only one line as output at a time, and reading other line states. This process
+  is repeated for each line.
+  This mechanism doesn't allow to detect simultaneous key presses.
+
+allOf:
+  - $ref: input.yaml#
+  - $ref: /schemas/input/matrix-keymap.yaml#
+
+properties:
+  compatible:
+    const: gpio-charlieplex-keypad
+
+  autorepeat: true
+
+  line-scan-delay-us:
+    description:
+      Delay, measured in microseconds, that is needed
+      before we can scan keypad after activating one line.
+    default: 0
+
+  line-gpios:
+    description:
+      List of GPIOs used as lines. The gpio specifier for this property
+      depends on the gpio controller to which these lines are connected.
+
+  linux,keymap: true
+
+  debounce-delay-ms:
+    description: Debounce interval in milliseconds.
+    default: 5
+
+  poll-interval: true
+
+  wakeup-source: true
+
+required:
+  - compatible
+  - line-gpios
+  - linux,keymap
+  - poll-interval
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/input/input.h>
+
+    charlieplex-keypad {
+        compatible = "gpio-charlieplex-keypad";
+        debounce-delay-ms = <20>;
+        poll-interval = <5>;
+        line-scan-delay-us = <2>;
+
+        line-gpios = <&gpio2 25 0
+                      &gpio2 26 0
+                      &gpio2 27 0>;
+
+        /* MATRIX_KEY(output, input, key-code) */
+        linux,keymap = <
+            MATRIX_KEY(0, 1, KEY_F1)
+            MATRIX_KEY(0, 2, KEY_F2)
+            MATRIX_KEY(1, 0, KEY_F3)
+            MATRIX_KEY(1, 2, KEY_F4)
+            MATRIX_KEY(2, 0, KEY_F5)
+            MATRIX_KEY(2, 1, KEY_F6)
+        >;
+    };
-- 
2.47.3

[PATCH v2 2/2] Input: charlieplex_keypad: add GPIO charlieplex keypad

[Hugo Villeneuve]

From: Hugo Villeneuve <hvilleneuve@dimonoff.com>

Add support for GPIO-based charlieplex keypad, allowing to control
N^2-N keys using N GPIO lines.

Reuse matrix keypad keymap to simplify, even if there is no concept
of rows and columns in this type of keyboard.

Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
 MAINTAINERS                                 |   7 +
 drivers/input/keyboard/Kconfig              |  14 ++
 drivers/input/keyboard/Makefile             |   1 +
 drivers/input/keyboard/charlieplex_keypad.c | 213 ++++++++++++++++++++
 4 files changed, 235 insertions(+)
 create mode 100644 drivers/input/keyboard/charlieplex_keypad.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ed6d11a77466..0b2d71f32b400 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5765,6 +5765,13 @@ S:	Maintained
 F:	Documentation/hwmon/powerz.rst
 F:	drivers/hwmon/powerz.c
 
+CHARLIEPLEX KEYPAD DRIVER
+M:	Hugo Villeneuve <hvilleneuve@dimonoff.com>
+S:	Supported
+W:	http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/matrix-keypad-scan-decode
+F:	Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
+F:	drivers/input/keyboard/charlieplex_keypad.c
+
 CHECKPATCH
 M:	Andy Whitcroft <apw@canonical.com>
 M:	Joe Perches <joe@perches.com>
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 2ff4fef322c24..ae54b4b7e2d8a 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -289,6 +289,20 @@ config KEYBOARD_MATRIX
 	  To compile this driver as a module, choose M here: the
 	  module will be called matrix_keypad.
 
+config KEYBOARD_CHARLIEPLEX
+	tristate "GPIO driven chearlieplex keypad support"
+	depends on GPIOLIB || COMPILE_TEST
+	select INPUT_MATRIXKMAP
+	help
+	  Enable support for GPIO driven charlieplex keypad. A charlieplex
+	  keypad allows to use fewer GPIO lines to interface to key switches.
+	  For example, an N lines charlieplex keypad can be used to interface
+	  to N^2-N different key switches. However, this type of keypad
+	  cannot detect more than one key press at a time.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called charlieplex_keypad.
+
 config KEYBOARD_HIL_OLD
 	tristate "HP HIL keyboard support (simple driver)"
 	depends on GSC || HP300
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 2d906e14f3e27..40b5cf5d374d2 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_KEYBOARD_LOCOMO)		+= locomokbd.o
 obj-$(CONFIG_KEYBOARD_LPC32XX)		+= lpc32xx-keys.o
 obj-$(CONFIG_KEYBOARD_MAPLE)		+= maple_keyb.o
 obj-$(CONFIG_KEYBOARD_MATRIX)		+= matrix_keypad.o
+obj-$(CONFIG_KEYBOARD_CHARLIEPLEX)	+= charlieplex_keypad.o
 obj-$(CONFIG_KEYBOARD_MAX7359)		+= max7359_keypad.o
 obj-$(CONFIG_KEYBOARD_MAX7360)		+= max7360-keypad.o
 obj-$(CONFIG_KEYBOARD_MPR121)		+= mpr121_touchkey.o
diff --git a/drivers/input/keyboard/charlieplex_keypad.c b/drivers/input/keyboard/charlieplex_keypad.c
new file mode 100644
index 0000000000000..81e8b6b96dab1
--- /dev/null
+++ b/drivers/input/keyboard/charlieplex_keypad.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ *  GPIO driven charlieplex keypad driver
+ *
+ *  Copyright (c) 2025 Hugo Villeneuve <hvilleneuve@dimonoff.com>
+ *
+ *  Based on matrix_keyboard.c
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/input.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/types.h>
+
+struct charlieplex_keypad {
+	struct input_dev *input_dev;
+	struct gpio_descs *line_gpios;
+	unsigned int nlines;
+	unsigned int line_scan_delay_us;
+	unsigned int debounce_threshold;
+	unsigned int debounce_count;
+	int debounce_code;
+	int current_code;
+};
+
+static void charlieplex_keypad_report_key(struct input_dev *input)
+{
+	struct charlieplex_keypad *keypad = input_get_drvdata(input);
+	const unsigned short *keycodes = input->keycode;
+
+	if (keypad->current_code > 0) {
+		input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
+		input_report_key(input, keycodes[keypad->current_code], 0);
+	}
+
+	if (keypad->debounce_code) {
+		input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
+		input_report_key(input, keycodes[keypad->debounce_code], 1);
+	}
+
+	input_sync(input);
+	keypad->current_code = keypad->debounce_code;
+}
+
+static void charlieplex_keypad_check_switch_change(struct input_dev *input,
+						   int code)
+{
+	struct charlieplex_keypad *keypad = input_get_drvdata(input);
+
+	if (code != keypad->debounce_code) {
+		keypad->debounce_count = 0;
+		keypad->debounce_code = code;
+	} else if (keypad->debounce_count < keypad->debounce_threshold) {
+		keypad->debounce_count++;
+
+		if (keypad->debounce_count >= keypad->debounce_threshold &&
+		    keypad->debounce_code != keypad->current_code)
+			charlieplex_keypad_report_key(input);
+	}
+}
+
+static void charlieplex_keypad_poll(struct input_dev *input)
+{
+	struct charlieplex_keypad *keypad = input_get_drvdata(input);
+	int oline;
+	int code;
+
+	for (code = 0, oline = 0; oline < keypad->nlines; oline++) {
+		DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
+		int iline;
+		int rc;
+
+		/* Activate only one line as output at a time. */
+		gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
+
+		if (keypad->line_scan_delay_us)
+			fsleep(keypad->line_scan_delay_us);
+
+		/* Read input on all other lines. */
+		rc = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
+						    keypad->line_gpios->desc,
+						    keypad->line_gpios->info, values);
+		if (rc)
+			return;
+
+		for (iline = 0; iline < keypad->nlines; iline++) {
+			if (iline == oline)
+				continue; /* Do not read active output line. */
+
+			/* Check if GPIO is asserted. */
+			if (test_bit(iline, values)) {
+				code = MATRIX_SCAN_CODE(oline, iline,
+							get_count_order(keypad->nlines));
+				/*
+				 * Exit loop immediately since we cannot detect
+				 * more than one key press at a time.
+				 */
+				break;
+			}
+		}
+
+		gpiod_direction_input(keypad->line_gpios->desc[oline]);
+
+		if (code)
+			break;
+	}
+
+	charlieplex_keypad_check_switch_change(input, code);
+}
+
+static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
+					struct charlieplex_keypad *keypad)
+{
+	int i;
+
+	keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
+	if (IS_ERR(keypad->line_gpios))
+		return PTR_ERR(keypad->line_gpios);
+
+	keypad->nlines = keypad->line_gpios->ndescs;
+
+	if (keypad->nlines > MATRIX_MAX_ROWS)
+		return -EINVAL;
+
+	for (i = 0; i < keypad->nlines; i++)
+		gpiod_set_consumer_name(keypad->line_gpios->desc[i], "charlieplex_kbd_line");
+
+	return 0;
+}
+
+static int charlieplex_keypad_probe(struct platform_device *pdev)
+{
+	struct charlieplex_keypad *keypad;
+	unsigned int debounce_interval_ms;
+	unsigned int poll_interval_ms;
+	struct input_dev *input_dev;
+	int err;
+
+	keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
+	if (!keypad)
+		return -ENOMEM;
+
+	input_dev = devm_input_allocate_device(&pdev->dev);
+	if (!input_dev)
+		return -ENOMEM;
+
+	keypad->input_dev = input_dev;
+
+	device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
+	device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
+	device_property_read_u32(&pdev->dev, "line-scan-delay-us", &keypad->line_scan_delay_us);
+
+	keypad->current_code = -1;
+	keypad->debounce_code = -1;
+	keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
+
+	err = charlieplex_keypad_init_gpio(pdev, keypad);
+	if (err)
+		return err;
+
+	input_dev->name		= pdev->name;
+	input_dev->id.bustype	= BUS_HOST;
+
+	err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
+					 keypad->nlines, NULL, input_dev);
+	if (err)
+		dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
+
+	if (device_property_read_bool(&pdev->dev, "autorepeat"))
+		__set_bit(EV_REP, input_dev->evbit);
+
+	input_set_capability(input_dev, EV_MSC, MSC_SCAN);
+
+	err = input_setup_polling(input_dev, charlieplex_keypad_poll);
+	if (err)
+		dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
+
+	input_set_poll_interval(input_dev, poll_interval_ms);
+
+	input_set_drvdata(input_dev, keypad);
+
+	err = input_register_device(keypad->input_dev);
+	if (err)
+		return err;
+
+	platform_set_drvdata(pdev, keypad);
+
+	return 0;
+}
+
+static const struct of_device_id charlieplex_keypad_dt_match[] = {
+	{ .compatible = "gpio-charlieplex-keypad" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, charlieplex_keypad_dt_match);
+
+static struct platform_driver charlieplex_keypad_driver = {
+	.probe		= charlieplex_keypad_probe,
+	.driver		= {
+		.name	= "charlieplex-keypad",
+		.of_match_table = of_match_ptr(charlieplex_keypad_dt_match),
+	},
+};
+module_platform_driver(charlieplex_keypad_driver);
+
+MODULE_AUTHOR("Hugo Villeneuve <hvilleneuve@dimonoff.com>");
+MODULE_DESCRIPTION("GPIO driven charlieplex keypad driver");
+MODULE_LICENSE("GPL");
-- 
2.47.3

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Rob Herring]

On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> 
> Add DT bindings for GPIO charlieplex keypad.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
>  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> 
> diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> new file mode 100644
> index 0000000000000..1672491a75a85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO charlieplex keypad
> +
> +maintainers:
> +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> +
> +description:
> +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> +  the number of lines). Key presses and releases are detected by configuring
> +  only one line as output at a time, and reading other line states. This process
> +  is repeated for each line.
> +  This mechanism doesn't allow to detect simultaneous key presses.
> +
> +allOf:
> +  - $ref: input.yaml#
> +  - $ref: /schemas/input/matrix-keymap.yaml#
> +
> +properties:
> +  compatible:
> +    const: gpio-charlieplex-keypad
> +
> +  autorepeat: true
> +
> +  line-scan-delay-us:
> +    description:
> +      Delay, measured in microseconds, that is needed
> +      before we can scan keypad after activating one line.
> +    default: 0

Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? 
If so, move it to matrix-keymap.yaml to re-use it here.

If not, there's a bunch of other scan delay properties just from 
grepping "delay" in the input bindings. Surely we can define something 
common.

Rob

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Hugo Villeneuve]

Hi Rob,

On Mon, 23 Feb 2026 11:57:06 -0600
Rob Herring <robh@kernel.org> wrote:

> On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > 
> > Add DT bindings for GPIO charlieplex keypad.
> > 
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> >  1 file changed, 82 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > new file mode 100644
> > index 0000000000000..1672491a75a85
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > @@ -0,0 +1,82 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO charlieplex keypad
> > +
> > +maintainers:
> > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > +
> > +description:
> > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > +  the number of lines). Key presses and releases are detected by configuring
> > +  only one line as output at a time, and reading other line states. This process
> > +  is repeated for each line.
> > +  This mechanism doesn't allow to detect simultaneous key presses.
> > +
> > +allOf:
> > +  - $ref: input.yaml#
> > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: gpio-charlieplex-keypad
> > +
> > +  autorepeat: true
> > +
> > +  line-scan-delay-us:
> > +    description:
> > +      Delay, measured in microseconds, that is needed
> > +      before we can scan keypad after activating one line.
> > +    default: 0
> 
> Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? 
> If so, move it to matrix-keymap.yaml to re-use it here.

It is used in a similar fashion, but for charlieplex keyboard, there is
no concept of "rows" and "columns". There are only
lines, which are all equivalent in functionality.

> If not, there's a bunch of other scan delay properties just from 
> grepping "delay" in the input bindings. Surely we can define something 
> common.

Most of those delays refer to something quite different than what
"col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
that we wait when activating a GPIO before we can safely/reliably read
other GPIOs connected thru its circuitry).

Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
combined into a common "line-scan-delay-us" ("line" is more generic
than column), and defined in matrix-keymap.yaml.

Then would it be ok to remove "col-scan-delay-us" from
gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ?

Hugo.

-- 
Hugo Villeneuve <hugo@hugovil.com>

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Rob Herring]

On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> Hi Rob,
>
> On Mon, 23 Feb 2026 11:57:06 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > >
> > > Add DT bindings for GPIO charlieplex keypad.
> > >
> > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > ---
> > >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> > >  1 file changed, 82 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > new file mode 100644
> > > index 0000000000000..1672491a75a85
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > @@ -0,0 +1,82 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +
> > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: GPIO charlieplex keypad
> > > +
> > > +maintainers:
> > > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > +
> > > +description:
> > > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > +  the number of lines). Key presses and releases are detected by configuring
> > > +  only one line as output at a time, and reading other line states. This process
> > > +  is repeated for each line.
> > > +  This mechanism doesn't allow to detect simultaneous key presses.
> > > +
> > > +allOf:
> > > +  - $ref: input.yaml#
> > > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: gpio-charlieplex-keypad
> > > +
> > > +  autorepeat: true
> > > +
> > > +  line-scan-delay-us:
> > > +    description:
> > > +      Delay, measured in microseconds, that is needed
> > > +      before we can scan keypad after activating one line.
> > > +    default: 0
> >
> > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > If so, move it to matrix-keymap.yaml to re-use it here.
>
> It is used in a similar fashion, but for charlieplex keyboard, there is
> no concept of "rows" and "columns". There are only
> lines, which are all equivalent in functionality.
>
> > If not, there's a bunch of other scan delay properties just from
> > grepping "delay" in the input bindings. Surely we can define something
> > common.
>
> Most of those delays refer to something quite different than what
> "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> that we wait when activating a GPIO before we can safely/reliably read
> other GPIOs connected thru its circuitry).
>
> Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> combined into a common "line-scan-delay-us" ("line" is more generic
> than column), and defined in matrix-keymap.yaml.

What about "scan-delay-us"? I would assume all the scan delay
properties are just the delay after changing the outputs to reading
the inputs.

> Then would it be ok to remove "col-scan-delay-us" from
> gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ?

No!

Rob

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Hugo Villeneuve]

Hi Rob,

On Mon, 23 Feb 2026 17:23:33 -0600
Rob Herring <robh@kernel.org> wrote:

> On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> >
> > Hi Rob,
> >
> > On Mon, 23 Feb 2026 11:57:06 -0600
> > Rob Herring <robh@kernel.org> wrote:
> >
> > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > >
> > > > Add DT bindings for GPIO charlieplex keypad.
> > > >
> > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > ---
> > > >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> > > >  1 file changed, 82 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > new file mode 100644
> > > > index 0000000000000..1672491a75a85
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > @@ -0,0 +1,82 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +
> > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: GPIO charlieplex keypad
> > > > +
> > > > +maintainers:
> > > > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > +
> > > > +description:
> > > > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > > +  the number of lines). Key presses and releases are detected by configuring
> > > > +  only one line as output at a time, and reading other line states. This process
> > > > +  is repeated for each line.
> > > > +  This mechanism doesn't allow to detect simultaneous key presses.
> > > > +
> > > > +allOf:
> > > > +  - $ref: input.yaml#
> > > > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: gpio-charlieplex-keypad
> > > > +
> > > > +  autorepeat: true
> > > > +
> > > > +  line-scan-delay-us:
> > > > +    description:
> > > > +      Delay, measured in microseconds, that is needed
> > > > +      before we can scan keypad after activating one line.
> > > > +    default: 0
> > >
> > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > > If so, move it to matrix-keymap.yaml to re-use it here.
> >
> > It is used in a similar fashion, but for charlieplex keyboard, there is
> > no concept of "rows" and "columns". There are only
> > lines, which are all equivalent in functionality.
> >
> > > If not, there's a bunch of other scan delay properties just from
> > > grepping "delay" in the input bindings. Surely we can define something
> > > common.
> >
> > Most of those delays refer to something quite different than what
> > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> > that we wait when activating a GPIO before we can safely/reliably read
> > other GPIOs connected thru its circuitry).
> >
> > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> > combined into a common "line-scan-delay-us" ("line" is more generic
> > than column), and defined in matrix-keymap.yaml.
> 
> What about "scan-delay-us"? I would assume all the scan delay
> properties are just the delay after changing the outputs to reading
> the inputs.

They are for gpio-matrix-keypad.yaml and this binding, but not for
others. Most scan delay properties refer to the period or
interval between successive scans.

So for my binding, "settling-time-us" would be more accurate and a
better property name (it is also used in adc.yaml).

Looking into a common place to define this new property, I stumbled
upon gpio-delay.yaml, so maybe I do not need this new property at all
and simply define a gpio-delay node if needed (and add it to this
binding example)?

I tested this and it works, although it requires a patch to the
gpio-aggregator driver, because for now it respect the delay only
when changing the output value, not when switching between input and
output like I do in my driver.

With my patch, it works ok.

> > Then would it be ok to remove "col-scan-delay-us" from
> > gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ?
> 
> No!
> 
> Rob

-- 
Hugo Villeneuve

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Rob Herring]

On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> Hi Rob,
>
> On Mon, 23 Feb 2026 17:23:33 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, 23 Feb 2026 11:57:06 -0600
> > > Rob Herring <robh@kernel.org> wrote:
> > >
> > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > >
> > > > > Add DT bindings for GPIO charlieplex keypad.
> > > > >
> > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > ---
> > > > >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> > > > >  1 file changed, 82 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000..1672491a75a85
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > @@ -0,0 +1,82 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +
> > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: GPIO charlieplex keypad
> > > > > +
> > > > > +maintainers:
> > > > > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > +
> > > > > +description:
> > > > > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > > > +  the number of lines). Key presses and releases are detected by configuring
> > > > > +  only one line as output at a time, and reading other line states. This process
> > > > > +  is repeated for each line.
> > > > > +  This mechanism doesn't allow to detect simultaneous key presses.
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: input.yaml#
> > > > > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: gpio-charlieplex-keypad
> > > > > +
> > > > > +  autorepeat: true
> > > > > +
> > > > > +  line-scan-delay-us:
> > > > > +    description:
> > > > > +      Delay, measured in microseconds, that is needed
> > > > > +      before we can scan keypad after activating one line.
> > > > > +    default: 0
> > > >
> > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > > > If so, move it to matrix-keymap.yaml to re-use it here.
> > >
> > > It is used in a similar fashion, but for charlieplex keyboard, there is
> > > no concept of "rows" and "columns". There are only
> > > lines, which are all equivalent in functionality.
> > >
> > > > If not, there's a bunch of other scan delay properties just from
> > > > grepping "delay" in the input bindings. Surely we can define something
> > > > common.
> > >
> > > Most of those delays refer to something quite different than what
> > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> > > that we wait when activating a GPIO before we can safely/reliably read
> > > other GPIOs connected thru its circuitry).
> > >
> > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> > > combined into a common "line-scan-delay-us" ("line" is more generic
> > > than column), and defined in matrix-keymap.yaml.
> >
> > What about "scan-delay-us"? I would assume all the scan delay
> > properties are just the delay after changing the outputs to reading
> > the inputs.
>
> They are for gpio-matrix-keypad.yaml and this binding, but not for
> others. Most scan delay properties refer to the period or
> interval between successive scans.
>
> So for my binding, "settling-time-us" would be more accurate and a
> better property name (it is also used in adc.yaml).

Let's go with that.

>
> Looking into a common place to define this new property, I stumbled
> upon gpio-delay.yaml, so maybe I do not need this new property at all
> and simply define a gpio-delay node if needed (and add it to this
> binding example)?
>
> I tested this and it works, although it requires a patch to the
> gpio-aggregator driver, because for now it respect the delay only
> when changing the output value, not when switching between input and
> output like I do in my driver.
>
> With my patch, it works ok.

I would not use gpio-delay here.

Rob

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Hugo Villeneuve]

On Tue, 24 Feb 2026 15:06:40 -0600
Rob Herring <robh@kernel.org> wrote:

> On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> >
> > Hi Rob,
> >
> > On Mon, 23 Feb 2026 17:23:33 -0600
> > Rob Herring <robh@kernel.org> wrote:
> >
> > > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Mon, 23 Feb 2026 11:57:06 -0600
> > > > Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > >
> > > > > > Add DT bindings for GPIO charlieplex keypad.
> > > > > >
> > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > > ---
> > > > > >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> > > > > >  1 file changed, 82 insertions(+)
> > > > > >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000000000..1672491a75a85
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > > @@ -0,0 +1,82 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +
> > > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: GPIO charlieplex keypad
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > > +
> > > > > > +description:
> > > > > > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > > > > +  the number of lines). Key presses and releases are detected by configuring
> > > > > > +  only one line as output at a time, and reading other line states. This process
> > > > > > +  is repeated for each line.
> > > > > > +  This mechanism doesn't allow to detect simultaneous key presses.
> > > > > > +
> > > > > > +allOf:
> > > > > > +  - $ref: input.yaml#
> > > > > > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: gpio-charlieplex-keypad
> > > > > > +
> > > > > > +  autorepeat: true
> > > > > > +
> > > > > > +  line-scan-delay-us:
> > > > > > +    description:
> > > > > > +      Delay, measured in microseconds, that is needed
> > > > > > +      before we can scan keypad after activating one line.
> > > > > > +    default: 0
> > > > >
> > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > > > > If so, move it to matrix-keymap.yaml to re-use it here.
> > > >
> > > > It is used in a similar fashion, but for charlieplex keyboard, there is
> > > > no concept of "rows" and "columns". There are only
> > > > lines, which are all equivalent in functionality.
> > > >
> > > > > If not, there's a bunch of other scan delay properties just from
> > > > > grepping "delay" in the input bindings. Surely we can define something
> > > > > common.
> > > >
> > > > Most of those delays refer to something quite different than what
> > > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> > > > that we wait when activating a GPIO before we can safely/reliably read
> > > > other GPIOs connected thru its circuitry).
> > > >
> > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> > > > combined into a common "line-scan-delay-us" ("line" is more generic
> > > > than column), and defined in matrix-keymap.yaml.
> > >
> > > What about "scan-delay-us"? I would assume all the scan delay
> > > properties are just the delay after changing the outputs to reading
> > > the inputs.
> >
> > They are for gpio-matrix-keypad.yaml and this binding, but not for
> > others. Most scan delay properties refer to the period or
> > interval between successive scans.
> >
> > So for my binding, "settling-time-us" would be more accurate and a
> > better property name (it is also used in adc.yaml).
> 
> Let's go with that.

Ok, will do.

> 
> >
> > Looking into a common place to define this new property, I stumbled
> > upon gpio-delay.yaml, so maybe I do not need this new property at all
> > and simply define a gpio-delay node if needed (and add it to this
> > binding example)?
> >
> > I tested this and it works, although it requires a patch to the
> > gpio-aggregator driver, because for now it respect the delay only
> > when changing the output value, not when switching between input and
> > output like I do in my driver.
> >
> > With my patch, it works ok.
> 
> I would not use gpio-delay here.

Ok.

I also observed that debounce-delay-ms is re-defined by a few bindings,
including mine. I assume that I could move all these identical
definitions to input.yaml and reduce duplication (in a separate patch,
of course).

While testing that, I found an odd situation: if I reference these four
dummy (undefined anywhere) properties in the gpio-matrix-keypad
binding, I am expecting four warnings when validating it. However I get
just three:

==================
diff --git
a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml index
20b5371fa21c..733458bf4d13 100644
--- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
+++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
@@ -36,7 +36,10 @@ properties:
 
   linux,keymap: true
 
+  bogus1-delay-ms: true
+  bogus2-delay-ms-bogus2: true
+  bogus3-my-property: true
+  bogus4: true
 
   linux,no-autorepeat:
     type: boolean
==================

Validation result:

...
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
...
...input/gpio-matrix-keypad.yaml:
  bogus2-delay-ms-bogus2: missing type definition
...input/gpio-matrix-keypad.yaml:
  bogus3-my-property: missing type definition
...input/gpio-matrix-keypad.yaml:
  bogus4: missing type definition

any idea why?

Thank you,
Hugo.

-- 
Hugo Villeneuve

Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad

[Rob Herring]

On Tue, Feb 24, 2026 at 4:32 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> On Tue, 24 Feb 2026 15:06:40 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, 23 Feb 2026 17:23:33 -0600
> > > Rob Herring <robh@kernel.org> wrote:
> > >
> > > > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Mon, 23 Feb 2026 11:57:06 -0600
> > > > > Rob Herring <robh@kernel.org> wrote:
> > > > >
> > > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > > >
> > > > > > > Add DT bindings for GPIO charlieplex keypad.
> > > > > > >
> > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > > > ---
> > > > > > >  .../input/gpio-charlieplex-keypad.yaml        | 82 +++++++++++++++++++
> > > > > > >  1 file changed, 82 insertions(+)
> > > > > > >  create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000000000..1672491a75a85
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > > > > > @@ -0,0 +1,82 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +
> > > > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: GPIO charlieplex keypad
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > > > > > +
> > > > > > > +description:
> > > > > > > +  The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > > > > > +  the number of lines). Key presses and releases are detected by configuring
> > > > > > > +  only one line as output at a time, and reading other line states. This process
> > > > > > > +  is repeated for each line.
> > > > > > > +  This mechanism doesn't allow to detect simultaneous key presses.
> > > > > > > +
> > > > > > > +allOf:
> > > > > > > +  - $ref: input.yaml#
> > > > > > > +  - $ref: /schemas/input/matrix-keymap.yaml#
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    const: gpio-charlieplex-keypad
> > > > > > > +
> > > > > > > +  autorepeat: true
> > > > > > > +
> > > > > > > +  line-scan-delay-us:
> > > > > > > +    description:
> > > > > > > +      Delay, measured in microseconds, that is needed
> > > > > > > +      before we can scan keypad after activating one line.
> > > > > > > +    default: 0
> > > > > >
> > > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > > > > > If so, move it to matrix-keymap.yaml to re-use it here.
> > > > >
> > > > > It is used in a similar fashion, but for charlieplex keyboard, there is
> > > > > no concept of "rows" and "columns". There are only
> > > > > lines, which are all equivalent in functionality.
> > > > >
> > > > > > If not, there's a bunch of other scan delay properties just from
> > > > > > grepping "delay" in the input bindings. Surely we can define something
> > > > > > common.
> > > > >
> > > > > Most of those delays refer to something quite different than what
> > > > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> > > > > that we wait when activating a GPIO before we can safely/reliably read
> > > > > other GPIOs connected thru its circuitry).
> > > > >
> > > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> > > > > combined into a common "line-scan-delay-us" ("line" is more generic
> > > > > than column), and defined in matrix-keymap.yaml.
> > > >
> > > > What about "scan-delay-us"? I would assume all the scan delay
> > > > properties are just the delay after changing the outputs to reading
> > > > the inputs.
> > >
> > > They are for gpio-matrix-keypad.yaml and this binding, but not for
> > > others. Most scan delay properties refer to the period or
> > > interval between successive scans.
> > >
> > > So for my binding, "settling-time-us" would be more accurate and a
> > > better property name (it is also used in adc.yaml).
> >
> > Let's go with that.
>
> Ok, will do.
>
> >
> > >
> > > Looking into a common place to define this new property, I stumbled
> > > upon gpio-delay.yaml, so maybe I do not need this new property at all
> > > and simply define a gpio-delay node if needed (and add it to this
> > > binding example)?
> > >
> > > I tested this and it works, although it requires a patch to the
> > > gpio-aggregator driver, because for now it respect the delay only
> > > when changing the output value, not when switching between input and
> > > output like I do in my driver.
> > >
> > > With my patch, it works ok.
> >
> > I would not use gpio-delay here.
>
> Ok.
>
> I also observed that debounce-delay-ms is re-defined by a few bindings,
> including mine. I assume that I could move all these identical
> definitions to input.yaml and reduce duplication (in a separate patch,
> of course).

Yes, that would be good.

> While testing that, I found an odd situation: if I reference these four
> dummy (undefined anywhere) properties in the gpio-matrix-keypad
> binding, I am expecting four warnings when validating it. However I get
> just three:
>
> ==================
> diff --git
> a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
> b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml index
> 20b5371fa21c..733458bf4d13 100644
> --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
> +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
> @@ -36,7 +36,10 @@ properties:
>
>    linux,keymap: true
>
> +  bogus1-delay-ms: true
> +  bogus2-delay-ms-bogus2: true
> +  bogus3-my-property: true
> +  bogus4: true
>
>    linux,no-autorepeat:
>      type: boolean
> ==================
>
> Validation result:
>
> ...
>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
> ...
> ...input/gpio-matrix-keypad.yaml:
>   bogus2-delay-ms-bogus2: missing type definition
> ...input/gpio-matrix-keypad.yaml:
>   bogus3-my-property: missing type definition
> ...input/gpio-matrix-keypad.yaml:
>   bogus4: missing type definition
>
> any idea why?

Properties with a unit suffix like "-ms" always have a type hence why
they don't ever define a type.

Rob