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.3On 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
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>
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.