gpio: realtek-otto: add pinctrl support
Subsystems (2)
v2 cover gpio: realtek-otto: add pinctrl support
This series adds pinctrl support for RTL9607C and marks it as required in documentation.
---
Changes in v2:
- Add 'required' property to dt-bindings
- Dropped the ellipsis and added Reviewed-by
- Link to v1: https://patch.msgid.link/amRpvtNAwIQak_9y@gamepc
---
Michael Zavertkin (2):
dt-bindings: gpio: otto-gpio: Add gpio-ranges
gpio: realtek-otto: add pinctrl support
.../bindings/gpio/realtek,otto-gpio.yaml | 14 ++++++++++++++ drivers/gpio/gpio-realtek-otto.c | 10 +++++++++- 2 files changed, 23 insertions(+), 1 deletion(-)
Signature · 1 line
2.54.0
PATCH v2 1/2 dt-bindings: gpio: otto-gpio: Add gpio-ranges
Pinctrl is required for RTL9607C GPIOs to work, otherwise controller won't be routed to SoC pins. Add corresponding requirement to Documentation for realtek,rtl9607-gpio.
--- .../bindings/gpio/realtek,otto-gpio.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +14 -0
@@ -40,6 +40,8 @@ properties: gpio-controller: true + gpio-ranges: false + ngpios: minimum: 1 maximum: 32
@@ -75,6 +77,18 @@ required: - "#gpio-cells" - gpio-controller +allOf: + - if: + properties: + compatible: + contains: + const: realtek,rtl9607-gpio + then: + properties: + gpio-ranges: true + required: + - gpio-ranges + additionalProperties: false dependencies:
Signature · 1 line
2.54.0
[email protected]
AI reviewRe: [PATCH v2 1/2] dt-bindings: gpio: otto-gpio: Add gpio-ranges
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Logical contradiction in JSON schema makes the `realtek,rtl9607-gpio` binding un-satisfiable. --
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Logical contradiction in JSON schema makes the realtek,rtl9607-gpio binding un-satisfiable. --
--- Patch [1]: [PATCH v2 1/2] dt-bindings: gpio: otto-gpio: Add gpio-ranges --- commit dc172e5a62e85037c013247864994cd4ea3bc026
Author: [email protected] <[email protected]>
dt-bindings: gpio: otto-gpio: Add gpio-ranges
This commit updates the realtek,otto-gpio binding documentation to add support for the gpio-ranges property. It specifically requires this property to be present when the realtek,rtl9607-gpio compatible string is used to ensure proper pinctrl routing.
Quoted 10 lines
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +2
-0@@ -40,6 +40,8 @@ properties: gpio-controller: true + gpio-ranges: false +
[ ... ]
Quoted 5 lines
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +1
-0@@ -75,6 +77,18 @@ required: - "#gpio-cells" - gpio-controller +allOf:
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml required: · line 90
Quoted 10 lines
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +10
-0+ - if: + properties: + compatible: + contains: + const: realtek,rtl9607-gpio + then: + properties: + gpio-ranges: true + required: + - gpio-ranges
[Severity: Medium]
Does this create a logical contradiction that makes the schema unsatisfiable for the realtek,rtl9607-gpio compatible string?
Because gpio-ranges is defined as false in the top-level properties list, it unconditionally forbids the property. However, the new allOf conditional block requires the exact same gpio-ranges property to be present.
Will this cause device tree validation to fail every time? If the property is present, it would fail the top-level false constraint, and if it is omitted, it would fail the required constraint in the conditional block.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Re: [PATCH v2 1/2] dt-bindings: gpio: otto-gpio: Add gpio-ranges
In reply to [email protected]Hi,
Quoted 39 lines · On Wed, 2026-08-19 at 22:51 +0700, [email protected] wrote:
Pinctrl is required for RTL9607C GPIOs to work, otherwise controller won't be routed to SoC pins. Add corresponding requirement to Documentation for realtek,rtl9607-gpio.
Signed-off-by Michael Zavertkin <[email protected]>---
.../bindings/gpio/realtek,otto-gpio.yaml | 14 ++++++++++++++1 file changed, 14 insertions(+)Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +0
-0@@ -40,6 +40,8 @@ properties:
gpio-controller: true
+ gpio-ranges: false
+
ngpios:
minimum: 1
maximum: 32Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +0
-0@@ -75,6 +77,18 @@ required:- "#gpio-cells"
- gpio-controllerDocumentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +12
-0+allOf: + - if: + properties: + compatible: + contains: + const: realtek,rtl9607-gpio + then: + properties: + gpio-ranges: true + required: + - gpio-ranges +
Quoted 3 lines
additionalProperties: false
dependencies:
Same remark as for the driver: I would just allow gpio-ranges for all compatibles and keep it optional. Since realtek,rtl9607-gpio was already published, it needs to remain backwards compatible. Making the property required now would theoretically invalidate existing devicetrees.
pinctrl-* properties already serve as an (actively used) alternative way to select GPIO functions e.g. on RTL8380, so that's another reason for me to leave this property optional.
In any case, thanks for the update to the driver!
Best,
Sander
PATCH v2 2/2 gpio: realtek-otto: add pinctrl support
In reply to [email protected]RTL9607C relies on pinctrl to mux SoC pins. Use pinctrl to request pins for GPIO
--- drivers/gpio/gpio-realtek-otto.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/gpio/gpio-realtek-otto.c +9 -1
@@ -97,6 +97,11 @@ enum realtek_gpio_flags {* range, where the per-cpu enable masks are located. */ GPIO_INTERRUPTS_PER_CPU =BIT (2 ), +/* +* Request GPIOs from pinctrl using gpiochip_generic_request() +* and gpiochip_generic_free(). +*/ + GPIO_PINCTRL = BIT(3), };static struct realtek_gpio_ctrl *irq_data_to_ctrl (struct irq_data *data)
@@ -354,7 +359,7 @@ static const struct of_device_id realtek_gpio_of_match[] = { }, { .compatible = "realtek,rtl9607-gpio", - .data = (void *)GPIO_PORTS_REVERSED, + .data = (void *)(GPIO_PORTS_REVERSED | GPIO_PINCTRL), }, {} };
@@ -405,6 +410,9 @@ static int realtek_gpio_probe(struct platform_device *pdev) ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped; } +if (dev_flags &GPIO_PINCTRL ) + gen_gc_flags |=GPIO_GENERIC_PINCTRL_BACKEND ; + config = (struct gpio_generic_chip_config ) { .dev = dev, .sz =4 ,
Signature · 1 line
2.54.0
Hi,
Quoted 44 lines · On Wed, 2026-08-19 at 22:51 +0700, [email protected] wrote:
RTL9607C relies on pinctrl to mux SoC pins. Use pinctrl to request pins for GPIO
Signed-off-by Michael Zavertkin <[email protected]>Reviewed-by Linus Walleij <[email protected]>---
drivers/gpio/gpio-realtek-otto.c | 10 +++++++++-1 file changed, 9 insertions(+), 1 deletion(-)drivers/gpio/gpio-realtek- renamed from drivers/gpio/gpio-realtek-otto.c +0
-0
otto.c
index4a606bad5848..86948da8adec100644drivers/gpio/gpio-realtek-otto.c +5
-0@@ -97,6 +97,11 @@ enum realtek_gpio_flags {* range, where the per-cpu enable masks are located. */ GPIO_INTERRUPTS_PER_CPU = BIT(2), +/* +* Request GPIOs from pinctrl using gpiochip_generic_request() +* and gpiochip_generic_free(). +*/ + GPIO_PINCTRL = BIT(3), };
static structrealtek_gpio_ctrl*irq_data_to_ctrl(structirq_data*data)drivers/gpio/gpio-realtek-otto.c +1
-1@@ -354,7 +359,7 @@ static const struct of_device_id realtek_gpio_of_match[] = { }, { .compatible = "realtek,rtl9607-gpio", - .data = (void *)GPIO_PORTS_REVERSED, + .data = (void *)(GPIO_PORTS_REVERSED | GPIO_PINCTRL), }, {}};
drivers/gpio/gpio-realtek-otto.c +0
-0@@ -405,6 +410,9 @@ static int realtek_gpio_probe(struct platform_device *pdev) ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped; }drivers/gpio/gpio-realtek-otto.c +3
-0+if (dev_flags &GPIO_PINCTRL ) + gen_gc_flags |=GPIO_GENERIC_PINCTRL_BACKEND ; +
Quoted 3 lines
config = (struct
gpio_generic_chip_config) { .dev = dev,
.sz = 4,
Any reason to not just always add GPI_GENERIC_PINCTRL_BACKEND, regardless of the compatible? If there are no gpio_ranges, gpio_generic_request() is a no-op, so there's no harm in enabling this without having that property defined.
The other SoCs use explicit pinctrl properties on the GPIO consumers in their devicetrees for now. If you enable this feature for all instances of this GPIO driver, then only the devicetree needs to be updated later to enable gpio_ranges for them.
Best,
Sander