Re: [PATCH v2 03/11] dt-bindings: gpio: Add Cortina Systems CS7542 GPIO controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: gpio: direct mapping of shared global control block
--

commit f730ed90fa497531db852f78666a6a8d9be45f40
Author: Fil Dunsky <filipp.dunsky@gmail.com>

dt-bindings: gpio: Add Cortina Systems CS7542 GPIO controller

This commit introduces a device tree binding for the Cortina Systems CS75xx
GPIO controller. It specifies five banks of 32 GPIO lines, each with its
own interrupt. The pins are shared between GPIO and peripheral functions
configured via a multiplexing register within a global control block.

> diff --git a/Documentation/devicetree/bindings/gpio/cortina,cs7542-gpio.yaml b/Documentation/devicetree/bindings/gpio/cortina,cs7542-gpio.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/cortina,cs7542-gpio.yaml
[ ... ]
> +properties:
> +  compatible:
> +    const: cortina,cs7542-gpio
> +
> +  reg:
> +    items:
> +      - description: GPIO bank registers
> +      - description: GPIO_MUX register of the bank

[Severity: Medium]
Does directly mapping the shared global control block in the reg property
risk resource request collisions at runtime?

If multiple drivers attempt to map the shared global control block, it can
lead to request_mem_region failures. Additionally, handling pin multiplexing
directly in the GPIO controller binding appears to bypass the pinctrl
subsystem.

Should the global control block be defined as a syscon node instead, with
the GPIO controller referencing it via a phandle (for example,
cortina,syscon = <&gcb>)? This would allow safe register modifications,
leaving pin multiplexing logic to be managed by the pinctrl subsystem.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-b4-cs75xx-s2-v2-0-94f8c0a90cda@gmail.com?part=3