Add 'wakeup' pinctrl state to support separate pin wakeup
configurations for GPIO. Upon suspend the 'wakeup' pinctrl state is
chosen if it exists. On resume the 'default' pinctrl state is selected.
The 'wakeup' pinctrl state allows wakeup from low-power states if a
specific pin configuration is needed.
On TI K3 AM62 family of devices, the GPIO controller is turned off in
suspend to RAM states, so no interrupt can be received by the
controller. This prevents system wakeup from low-power states.
Alternatively, the pins can wakeup the system if a wakeup flag is set on
the pin by using pinctrl.
A corresponding device tree patch using the 'wakeup' pinctrl state can
be found under "arm64: dts: ti: k3-am62l3-evm: add wakeup-source for GPIO
button".
Tested GPIO wakeup from suspend on AM62L EVM and AM62P EVM.
Signed-off-by: Kendall Willis <redacted>
---
Kendall Willis (2):
dt-bindings: input: gpio-keys: add pinctrl states
Input: gpio-keys - support wakeup pinctrl state on suspend
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
drivers/input/keyboard/gpio_keys.c | 13 +++++++++++++
2 files changed, 29 insertions(+)
---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260904-upstream-gpio-wakeup-52a54080c948
Best regards,
--
Kendall Willis [off-list ref]
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup+patternProperties:"^(button|event|key|switch|(button|event|key|switch)-[a-z0-9-]+|[a-z0-9-]+-(button|event|key|switch))$":$ref:input.yaml#
GPIO can be used as a wakeup source for TI K3 AM62 devices during
suspend to RAM states. The GPIO controller is powered off in these
states, so a wakeup enable flag must be set on the GPIO pin in the
pinctrl in order to allow wakeup.
If the device is wakeup enabled, select the 'wakeup' pinctrl state on
suspend and restore the default pinctrl state on resume.
Signed-off-by: Kendall Willis <redacted>
---
drivers/input/keyboard/gpio_keys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Schema constraint on `pinctrl-names` breaks validation for existing device trees using standard PM states.
--
commit 7cccd8c7baf951e7fe028bb369bca736764010d5
Author: Kendall Willis [off-list ref]
dt-bindings: input: gpio-keys: add pinctrl states
This patch adds pinctrl-0, pinctrl-1, and pinctrl-names properties to the
gpio-keys device tree binding to document the default and wakeup pin
configurations.
+ pinctrl-names:+ description:+ When present should contain at least "default" describing the default pin+ states. The second state called "wakeup" describes the pins in their+ wakeup configuration required to exit sleep states.+ minItems: 1+ items:+ - const: default+ - const: wakeup
[Severity: Medium]
Does this strict schema constraint break validation for existing device trees?
By explicitly restricting the pinctrl-names items to exactly "default" and
"wakeup" in Documentation/devicetree/bindings/input/gpio-keys.yaml, this
generic binding will now cause device tree validation (make dtbs_check) to
fail for existing upstream boards.
Many boards correctly use standard pinctrl power management states like "sleep"
(for example, pinctrl-names = "default", "sleep";) which are now rejected by
this schema.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-upstream-gpio-wakeup-v1-0-f0e12484b836@ti.com?part=1
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing restoration of default pinctrl state on error path in gpio_keys_enable_wakeup().
--
commit 794b05f8c21f23224e4ff7b076c2d675310e6432
Author: Kendall Willis [off-list ref]
Input: gpio-keys - support wakeup pinctrl state on suspend
This commit enables GPIO controllers on TI K3 AM62 devices to act as a wakeup
source during suspend to RAM by selecting a wakeup pinctrl state and restoring
the default on resume.
@@ -1010,6 +1017,9 @@ gpio_keys_enable_wakeup(struct gpio_keys_drvdata *ddata) int error; int i;+ if (!IS_ERR_OR_NULL(ddata->pinctrl_wakeup))+ pinctrl_select_state(ddata->pinctrl, ddata->pinctrl_wakeup);+ for (i = 0; i < ddata->pdata->nbuttons; i++) { bdata = &ddata->data[i]; if (bdata->button->wakeup) {
[Severity: Medium]
Does the error path in this function need to restore the default pinctrl
state?
Looking at gpio_keys_enable_wakeup in drivers/input/keyboard/gpio_keys.c,
the pinctrl state is changed to wakeup at the start of the function.
However, if gpio_keys_button_enable_wakeup fails for any button, the code
jumps to the err_out label:
err_out:
while (i--) {
bdata = &ddata->data[i];
if (bdata->button->wakeup)
gpio_keys_button_disable_wakeup(bdata);
bdata->suspended = false;
}
return error;
Since a failure here aborts the device's suspend transition, the PM core
will not invoke the corresponding resume callback. Could this leave the
hardware pins stuck in the wakeup configuration instead of reverting to the
default state for normal runtime operation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-upstream-gpio-wakeup-v1-0-f0e12484b836@ti.com?part=2
From: Francesco Dolcini <francesco@dolcini.it> Date: 2026-09-14 05:59:44
Hello Kendall,
On Sat, Sep 12, 2026 at 04:33:52PM -0500, Kendall Willis wrote:
Add 'wakeup' pinctrl state to support separate pin wakeup
configurations for GPIO. Upon suspend the 'wakeup' pinctrl state is
chosen if it exists. On resume the 'default' pinctrl state is selected.
The 'wakeup' pinctrl state allows wakeup from low-power states if a
specific pin configuration is needed.
On TI K3 AM62 family of devices, the GPIO controller is turned off in
suspend to RAM states, so no interrupt can be received by the
controller. This prevents system wakeup from low-power states.
Alternatively, the pins can wakeup the system if a wakeup flag is set on
the pin by using pinctrl.
A corresponding device tree patch using the 'wakeup' pinctrl state can
be found under "arm64: dts: ti: k3-am62l3-evm: add wakeup-source for GPIO
button".
Tested GPIO wakeup from suspend on AM62L EVM and AM62P EVM.
Signed-off-by: Kendall Willis <redacted>
This is going to be useful also for verdin am62 (verdin_key_wakeup /
k3-am62-verdin.dtsi).
Thanks,
Francesco
Hi Kendall,
On Sat Sep 12, 2026 at 11:33 PM CEST, Kendall Willis wrote:
quoted hunk
GPIO can be used as a wakeup source for TI K3 AM62 devices during
suspend to RAM states. The GPIO controller is powered off in these
states, so a wakeup enable flag must be set on the GPIO pin in the
pinctrl in order to allow wakeup.
If the device is wakeup enabled, select the 'wakeup' pinctrl state on
suspend and restore the default pinctrl state on resume.
Signed-off-by: Kendall Willis <redacted>
---
drivers/input/keyboard/gpio_keys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-14 10:13:12
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted hunk
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
Best regards,
Krzysztof
On 09:51-20260914, Markus Schneider-Pargmann wrote:
Hi Kendall,
On Sat Sep 12, 2026 at 11:33 PM CEST, Kendall Willis wrote:
quoted
GPIO can be used as a wakeup source for TI K3 AM62 devices during
suspend to RAM states. The GPIO controller is powered off in these
states, so a wakeup enable flag must be set on the GPIO pin in the
pinctrl in order to allow wakeup.
If the device is wakeup enabled, select the 'wakeup' pinctrl state on
suspend and restore the default pinctrl state on resume.
Signed-off-by: Kendall Willis <redacted>
---
drivers/input/keyboard/gpio_keys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/can/bosch%2Cm_can.yaml#L121
Best,
Kendall
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-15 17:05:46
On 15/09/2026 18:48, Kendall Willis wrote:
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
Best regards,
Krzysztof
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-15 17:07:25
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
And about CAN, I see no use of both sleep and wakeup:
git grep pinctrl-names | grep wakeup
So if you use existing code as reason for this change, then existing
code tells they are the same.
Best regards,
Krzysztof
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
And about CAN, I see no use of both sleep and wakeup:
git grep pinctrl-names | grep wakeup
So if you use existing code as reason for this change, then existing
code tells they are the same.
Yes, as of now both are not being used at the same time. I was more
pointing to existing code to show that the 'wakeup' pinctrl state was
being used for wakeup pin configurations.
Best,
Kendall
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-16 07:17:36
On Tue, Sep 15, 2026 at 12:41:03PM -0500, Kendall Willis wrote:
On 19:07-20260915, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
If they cannot be used together, then it is the same state.
We do not define pinctrl states as XOR of "active-high-drive-str" or
"active-no-pull-up" or "active-whatever-other-mode", because these are
defined by the actual values of pincfg of one, single "active" config.
quoted
And about CAN, I see no use of both sleep and wakeup:
git grep pinctrl-names | grep wakeup
So if you use existing code as reason for this change, then existing
code tells they are the same.
Yes, as of now both are not being used at the same time. I was more
On Wed Sep 16, 2026 at 9:17 AM CEST, Krzysztof Kozlowski wrote:
On Tue, Sep 15, 2026 at 12:41:03PM -0500, Kendall Willis wrote:
quoted
On 19:07-20260915, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
If they cannot be used together, then it is the same state.
If I understand this patch correctly, 'sleep' is not relevant here.
But 'sleep' and 'wakeup' serve different purposes and can be
used/defined together in a single device in the devicetree:
- 'sleep' describes the pin state during suspend if wakeup is not
enabled by the user or there is no 'wakeup' pin state defined.
- 'wakeup' describes the pin state during suspend if wakeup is enabled
by the user.
If the user enables wakeup, 'wakeup' is the relevant state and otherwise
'sleep'. Which one applieas is a runtime decision of the the user.
I introduced these two states for m_can for that reason. This was
discussed here:
https://lore.kernel.org/r/DCD1YPX4T779.ADK4JCGW1MU7@baylibre.com
And then reviewed/applied in v10:
https://lore.kernel.org/r/175993598226.3512549.5295923279078928995.robh@kernel.org
Best
Markus
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-20 10:24:42
On 16/09/2026 17:36, Markus Schneider-Pargmann wrote:
On Wed Sep 16, 2026 at 9:17 AM CEST, Krzysztof Kozlowski wrote:
quoted
On Tue, Sep 15, 2026 at 12:41:03PM -0500, Kendall Willis wrote:
quoted
On 19:07-20260915, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
If they cannot be used together, then it is the same state.
If I understand this patch correctly, 'sleep' is not relevant here.
But 'sleep' and 'wakeup' serve different purposes and can be
used/defined together in a single device in the devicetree:
- 'sleep' describes the pin state during suspend if wakeup is not
enabled by the user or there is no 'wakeup' pin state defined.
- 'wakeup' describes the pin state during suspend if wakeup is enabled
by the user.
If the user enables wakeup, 'wakeup' is the relevant state and otherwise
'sleep'. Which one applieas is a runtime decision of the the user.
I introduced these two states for m_can for that reason. This was
discussed here:
https://lore.kernel.org/r/DCD1YPX4T779.ADK4JCGW1MU7@baylibre.com
And then reviewed/applied in v10:
https://lore.kernel.org/r/175993598226.3512549.5295923279078928995.robh@kernel.org
So we seems to be discussing same issue again, because commit msg lacks
proper explanations.
The problem and difference here is that there is no sleep state.
Best regards,
Krzysztof
On Sun, Sep 20, 2026 at 12:24:32PM +0200, Krzysztof Kozlowski wrote:
On 16/09/2026 17:36, Markus Schneider-Pargmann wrote:
quoted
On Wed Sep 16, 2026 at 9:17 AM CEST, Krzysztof Kozlowski wrote:
quoted
On Tue, Sep 15, 2026 at 12:41:03PM -0500, Kendall Willis wrote:
quoted
On 19:07-20260915, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
If they cannot be used together, then it is the same state.
If I understand this patch correctly, 'sleep' is not relevant here.
But 'sleep' and 'wakeup' serve different purposes and can be
used/defined together in a single device in the devicetree:
- 'sleep' describes the pin state during suspend if wakeup is not
enabled by the user or there is no 'wakeup' pin state defined.
- 'wakeup' describes the pin state during suspend if wakeup is enabled
by the user.
If the user enables wakeup, 'wakeup' is the relevant state and otherwise
'sleep'. Which one applieas is a runtime decision of the the user.
I introduced these two states for m_can for that reason. This was
discussed here:
https://lore.kernel.org/r/DCD1YPX4T779.ADK4JCGW1MU7@baylibre.com
And then reviewed/applied in v10:
https://lore.kernel.org/r/175993598226.3512549.5295923279078928995.robh@kernel.org
So we seems to be discussing same issue again, because commit msg lacks
proper explanations.
The problem and difference here is that there is no sleep state.
Isn't there? The wakeup can be controlled from userspace and can't we
possible have 2 distinct pin control states, one for when a device is a
potential wakeup source, and another one when the device is in "off"
state while system is asleep?
Thanks.
--
Dmitry
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-22 08:49:00
On 21/09/2026 21:35, Dmitry Torokhov wrote:
On Sun, Sep 20, 2026 at 12:24:32PM +0200, Krzysztof Kozlowski wrote:
quoted
On 16/09/2026 17:36, Markus Schneider-Pargmann wrote:
quoted
On Wed Sep 16, 2026 at 9:17 AM CEST, Krzysztof Kozlowski wrote:
quoted
On Tue, Sep 15, 2026 at 12:41:03PM -0500, Kendall Willis wrote:
quoted
On 19:07-20260915, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 19:05, Krzysztof Kozlowski wrote:
quoted
On 15/09/2026 18:48, Kendall Willis wrote:
quoted
On 12:13-20260914, Krzysztof Kozlowski wrote:
quoted
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
So you mean sleep would be a separate state? But then aren't both
exactly the same states? IOW, if device is wakeup-source, it will have
for "sleep" state pin configuration allowing to wakeup.
The 'sleep' and 'wakeup' pin states are both used for suspend. They
would just be used separately since only one could be used at a time.
The reason 'wakeup' is separated out is because it is more specific for
allowing wakeup from the device.
If they cannot be used together, then it is the same state.
If I understand this patch correctly, 'sleep' is not relevant here.
But 'sleep' and 'wakeup' serve different purposes and can be
used/defined together in a single device in the devicetree:
- 'sleep' describes the pin state during suspend if wakeup is not
enabled by the user or there is no 'wakeup' pin state defined.
- 'wakeup' describes the pin state during suspend if wakeup is enabled
by the user.
If the user enables wakeup, 'wakeup' is the relevant state and otherwise
'sleep'. Which one applieas is a runtime decision of the the user.
I introduced these two states for m_can for that reason. This was
discussed here:
https://lore.kernel.org/r/DCD1YPX4T779.ADK4JCGW1MU7@baylibre.com
And then reviewed/applied in v10:
https://lore.kernel.org/r/175993598226.3512549.5295923279078928995.robh@kernel.org
So we seems to be discussing same issue again, because commit msg lacks
proper explanations.
The problem and difference here is that there is no sleep state.
Isn't there?
Isn't. Quoting patch:
+ items:
+ - const: default
+ - const: wakeup
No sleep. :( So both the commit msg, rationale and could improve so we
won't be asking the same questions at v2.
The wakeup can be controlled from userspace and can't we
possible have 2 distinct pin control states, one for when a device is a
potential wakeup source, and another one when the device is in "off"
state while system is asleep?
Thanks.
On Sat, Sep 12, 2026 at 04:33:53PM -0500, Kendall Willis wrote:
quoted
Document pinctrl properties on the gpio-keys device node. By using the
wakeup pinctrl state, the pins are able to wakeup the system from a
low-power state. The default pinctrl state describes the default pin
configuration.
Signed-off-by: Kendall Willis <redacted>
---
Documentation/devicetree/bindings/input/gpio-keys.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -22,6 +22,22 @@ properties:poll-interval:true+pinctrl-0:+description:Default pinctrl state++pinctrl-1:+description:Wakeup pinctrl state++pinctrl-names:+description:+When present should contain at least "default" describing the default pin+states. The second state called "wakeup" describes the pins in their+wakeup configuration required to exit sleep states.+minItems:1+items:+-const:default+-const:wakeup
This will introduce new warnings, which should be being fixed in this
patchset (e.g. at91-kizbox3-hs.dts).
Will fix the binding to work with current device trees.
I looked into this more, and the only DTS that I could find that uses
more than one pinctrl is at91-kizbox3-hs.dts. I am not able to add the
wakeup pinctrl state and allow endless pinctrls and constrain the first
pinctrl to be the default state, so I will send v2 of this series
without allowing many default pinctrl states.
When I looked at at91-kizbox3-hs.dts it looks like all the pinctrls
could be consolidated to pinctrl-0 since none of the pins overlap. I can
send a patch consolidating it so that if these bindings do get picked,
that device tree is fixed so no more warnings are generated. It does
look like a bug anyways for there to be multiple default pinctrls since
pinctrl would only configure the first default pinctrl state, and the
others would not be touched.
Best,
Kendall
quoted
But nevertheless, isn't second state the sleep state? How can you
configure pins for the wakeup state - like being in the wakeup? You
configure the pins for given state, which will be a system suspend, so
sleep?
The sleep state usually refers to putting the pins in a state to save
power. The wakeup pinctrl state is for putting the pins in a state to
allow wakeup from suspend for that device. Both 'sleep' and 'wakeup'
are for system suspend, but they fill different functions. The CAN
subsystem also uses the 'wakeup' state in addition to the 'sleep' state
[1].
[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/can/bosch%2Cm_can.yaml#L121
Best,
Kendall