[PATCH] arm64: dts: exynos: tm2: fix wm5110 reset/ldoena GPIO properties

[PATCH] arm64: dts: exynos: tm2: fix wm5110 reset/ldoena GPIO properties

[Marek Szyprowski]

The wm5110 audio-codec node uses the legacy "wlf,reset" and
"wlf,ldoena" property names without the standard "-gpios" suffix.
gpiolib-of.c only recognizes these bare names as aliases for the
correct "wlf,reset-gpios"/"wlf,ldoena-gpios" properties, and that
alias support is compiled in only when CONFIG_MFD_ARIZONA and
CONFIG_REGULATOR_ARIZONA_LDO1 are enabled. When those options are
disabled, devm_gpiod_get() fails to find the GPIOs, leaving the
codec without a working reset/LDO enable line.

Rename the properties to the proper "-gpios" suffixed form so the
GPIOs are found unconditionally via the standard gpiolib lookup,
matching what drivers/mfd/arizona-core.c and
drivers/regulator/arizona-ldo1.c actually request.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 79eb47441819..e9ff42c4764c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -1374,8 +1374,8 @@ wm5110: audio-codec@0 {
 		wlf,gpsw = <0x1>;
 		wlf,inmode = <2 0 2 0>;
 
-		wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>;
-		wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>;
+		wlf,reset-gpios = <&gpc0 7 GPIO_ACTIVE_HIGH>;
+		wlf,ldoena-gpios = <&gpf0 0 GPIO_ACTIVE_HIGH>;
 
 		/* core supplies */
 		AVDD-supply = <&ldo18_reg>;
-- 
2.43.0

Re: [PATCH] arm64: dts: exynos: tm2: fix wm5110 reset/ldoena GPIO properties

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: exynos: undocumented wlf,reset-gpios and wlf,ldoena-gpios in tm2
--

commit d7eced1233f0545ac05280c98b1abea17e17ed8c
Author: Marek Szyprowski <m.szyprowski@samsung.com>

arm64: dts: exynos: tm2: fix wm5110 reset/ldoena GPIO properties

This commit renames the wlf,reset and wlf,ldoena properties in the wm5110
audio-codec node of exynos5433-tm2-common.dtsi to wlf,reset-gpios and
wlf,ldoena-gpios.

> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 0ad02a098765d..44e03e38c2c43 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -1346,8 +1346,8 @@ wm5110: audio-codec@0 {
>  		wlf,gpsw = <0x1>;
>  		wlf,inmode = <2 0 2 0>;
>  
> -		wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>;
> -		wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>;
> +		wlf,reset-gpios = <&gpc0 7 GPIO_ACTIVE_HIGH>;
> +		wlf,ldoena-gpios = <&gpf0 0 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Does renaming these properties to wlf,reset-gpios and wlf,ldoena-gpios cause
a dtbs_check schema validation regression for exynos5433-tm2.dtb and
exynos5433-tm2e.dtb?

The wm5110 node (compatible = "wlf,wm5110") is validated against
Documentation/devicetree/bindings/mfd/wlf,arizona.yaml, which references
Documentation/devicetree/bindings/regulator/wlf,arizona.yaml and sets
unevaluatedProperties: false.

In Documentation/devicetree/bindings/mfd/wlf,arizona.yaml, the standard
reset property is reset-gpios (without the vendor prefix), while wlf,reset
is marked deprecated:

  reset-gpios:
    maxItems: 1

  wlf,reset:
    description:
      GPIO specifier for the GPIO controlling RESET
    deprecated: true
    $ref: /schemas/types.yaml#/definitions/phandle-array
    maxItems: 1

Similarly, Documentation/devicetree/bindings/regulator/wlf,arizona.yaml only
defines wlf,ldoena:

  wlf,ldoena:
    description:
      GPIO specifier for the GPIO controlling LDOENA.
    $ref: /schemas/types.yaml#/definitions/phandle-array
    maxItems: 1

Neither schema defines wlf,reset-gpios or wlf,ldoena-gpios. In
drivers/mfd/arizona-core.c, arizona_dev_init() requests "reset" for the
standard reset-gpios binding:

	if (!arizona->pdata.reset) {
		/* Start out with /RESET low to put the chip into reset */
		arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset",
						      GPIOD_OUT_LOW);

while arizona_of_get_core_pdata() only requests "wlf,reset" as a fallback for
the old non-standard wlf,reset property via of_find_gpio_rename() in
drivers/gpio/gpiolib-of.c.

Also, can the Kconfig mismatch described in the commit message actually
occur? In drivers/gpio/gpiolib-of.c, of_find_gpio_rename() guards the
"wlf,reset" and "wlf,ldoena" rename entries with:

#if IS_ENABLED(CONFIG_MFD_ARIZONA)
		{ "wlf,reset",	NULL,		NULL },
#endif

and:

#if IS_ENABLED(CONFIG_REGULATOR_ARIZONA_LDO1)
		{ "wlf,ldoena",	NULL,		NULL },
#endif

The consumers in drivers/mfd/arizona-core.c and
drivers/regulator/arizona-ldo1.c are built under the exact same Kconfig
options in drivers/mfd/Makefile and drivers/regulator/Makefile:

obj-$(CONFIG_MFD_ARIZONA)	+= arizona.o
obj-$(CONFIG_REGULATOR_ARIZONA_LDO1) += arizona-ldo1.o

When CONFIG_MFD_ARIZONA or CONFIG_REGULATOR_ARIZONA_LDO1 is disabled, the
corresponding driver is not built at all, and when enabled (either built-in
or as a module), IS_ENABLED() evaluates to true in gpiolib-of.c.

Should wlf,reset instead be replaced with the documented reset-gpios property
 while keeping wlf,ldoena matching the binding schema?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261026102658.968138-1-m.szyprowski@samsung.com?part=1