Re: [PATCH 1/2] dt-bindings: gpio: Add CAT9532 GPIO

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dt-bindings: gpio: fragmenting LED dimmer binding by isolating CAT9532 as pure GPIO
- [Low] dt-bindings: gpio: redundant ngpios requirement for fixed-pin hardware
--

commit 5e8f0055659d78276b37db0fd1e766db66fdb2f8
Author: Alban Bedel <alban.bedel@lht.dlh.de>

dt-bindings: gpio: Add CAT9532 GPIO

This commit adds a devicetree binding document for the CAT9532 LED dimmer
as a GPIO controller.

> diff --git a/Documentation/devicetree/bindings/gpio/onnn,cat9532.yaml b/Documentation/devicetree/bindings/gpio/onnn,cat9532.yaml
> new file mode 100644
> index 0000000000000..6f3e3d0f4f29b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/onnn,cat9532.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/onnn,cat9532.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: On Semiconductor CAT9532 LED dimmer as GPIO controller

[Severity: Medium]
The title explicitly acknowledges the hardware is an LED dimmer, but does
this binding intentionally strip away all LED functionality by isolating it
in the GPIO subsystem?

The ON Semiconductor CAT9532 is functionally identical to the NXP PCA9532
LED dimmer. A comprehensive binding for this hardware family already exists
in Documentation/devicetree/bindings/leds/nxp,pca953x.yaml, fully supporting
both its LED and GPIO capabilities.

Could the onnn,cat9532 compatible instead be integrated into the existing
nxp,pca953x.yaml binding to avoid fragmenting the devicetree representation
of the hardware?

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - gpio-controller
> +  - "#gpio-cells"
> +  - ngpios

[Severity: Low]
Does this erroneously force ngpios to be provided in all devicetree nodes
using this binding, despite the pin count being fixed?

The CAT9532 hardware inherently possesses exactly 16 pins, and the driver
implemented in the follow-up patch completely ignores the ngpios property
from devicetree, instead hardcoding chip->ngpio = 16. Making ngpios a
required property forces devicetree authors to specify redundant, fixed
hardware parameters.

Could this redundant requirement be removed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915092046.931449-1-alban.bedel@lht.dlh.de?part=1