Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhengping Zhang" <zhengping.zhang@airoha.com>
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 09/12] pinctrl: airoha: an7583: use force GPIO mode for GPIO requests
Date: Tue, 10 Nov 2026 09:56:54 +0000	[thread overview]
Message-ID: <sashiko-outbox-206817@kernel.org> (raw)
In-Reply-To: <20261110094339.749110-10-zhengping.zhang@airoha.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] pinctrl: airoha: an7583: hsuart and hsuart_cts_rts mux
  conflict
- [Low] pinctrl: airoha: an7583: redundant regmap[2] in PWM_EXT_SEC and
  unused macros
--

commit f7d089a2abc89c3f0877be6d6eb92f87952452c6
Author: Zhengping Zhang <zhengping.zhang@airoha.com>

pinctrl: airoha: an7583: use force GPIO mode for GPIO requests

This commit enables per-pad force GPIO overrides, shared GPIO request
handling, and mux conflict checking on AN7583, while updating peripheral,
PWM, and PON pinmux groups accordingly.

> diff --git a/drivers/pinctrl/airoha/pinctrl-an7583.c b/drivers/pinctrl/airoha/pinctrl-an7583.c
> index 74628a03ca909..e2f629d9d43cd 100644
> --- a/drivers/pinctrl/airoha/pinctrl-an7583.c
> +++ b/drivers/pinctrl/airoha/pinctrl-an7583.c

[ ... ]

> -#define AIROHA_PINCTRL_PWM_EXT_SEC(gpio, mux_val, smux_val)	\
> +#define AIROHA_PINCTRL_PWM_EXT_SEC(gpio, mux_val, smux_val, force_reg, force_mask) \
>  	{							\
>  		.name = (gpio),					\
>  		.regmap[0] = {					\
> @@ -299,10 +308,14 @@
>  			(smux_val),				\
>  			(smux_val)				\
>  		},						\
> -		.regmap_size = 2,				\
> +		.regmap[2] = {					\
> +			AIROHA_FUNC_MUX, (force_reg),		\
> +			(force_mask), (force_mask)			\
> +		},						\
> +		.regmap_size = 3,				\
>  	}

[Severity: Low]
This isn't a bug, but AIROHA_PINCTRL_PWM_EXT_SEC() already sets the
per-pad GPIO selector bit (smux_val) in REG_GPIO_PON_MODE via regmap[1],
and all 13 callers (gpio39 through gpio51 in pwm_func_group) pass 0 for
force_mask, making regmap[2] a no-op entry.  In addition, replacing the
entries in gpio_func_group with AN7583_GPIO_GROUP() leaves
AIROHA_PINCTRL_GPIO() and AIROHA_PINCTRL_GPIO_EXT() unused.

[ ... ]

> @@ -745,7 +840,14 @@ static const struct airoha_pinctrl_func_group uart_func_group[] = {
>  			GPIO_UART2_MODE_MASK | GPIO_UART2_CTS_RTS_MODE_MASK,
>  			GPIO_UART2_MODE_MASK | GPIO_UART2_CTS_RTS_MODE_MASK
>  		},
> -		.regmap_size = 1,
> +		.regmap[1] = {
> +			AIROHA_FUNC_MUX,
> +			REG_FORCE_GPIO_EN,
> +			BIT(30) |
> +			BIT(31),
> +			0
> +		},
> +		.regmap_size = 2,
>  	}, {
>  		.name = "hsuart",
>  		.regmap[0] = {
> @@ -754,7 +856,14 @@ static const struct airoha_pinctrl_func_group uart_func_group[] = {
>  			GPIO_HSUART_MODE_MASK | GPIO_HSUART_CTS_RTS_MODE_MASK,
>  			GPIO_HSUART_MODE_MASK
>  		},
> -		.regmap_size = 1,
> +		.regmap[1] = {
> +			AIROHA_FUNC_MUX,
> +			REG_FORCE_GPIO_EN,
> +			BIT(28) |
> +			BIT(29),
> +			0
> +		},
> +		.regmap_size = 2,
>  	},
>  	{
>  		.name = "hsuart_cts_rts",
> @@ -764,7 +873,14 @@ static const struct airoha_pinctrl_func_group uart_func_group[] = {
>  			GPIO_HSUART_MODE_MASK | GPIO_HSUART_CTS_RTS_MODE_MASK,
>  			GPIO_HSUART_MODE_MASK | GPIO_HSUART_CTS_RTS_MODE_MASK
>  		},
> -		.regmap_size = 1,
> +		.regmap[1] = {
> +			AIROHA_FUNC_MUX,
> +			REG_FORCE_GPIO_EN,
> +			BIT(26) |
> +			BIT(27),
> +			0
> +		},
> +		.regmap_size = 2,
>  	}, {

[Severity: Medium]
Does enabling check_mux_conflicts in pinctrl_match_data cause selecting
both "hsuart" and "hsuart_cts_rts" to fail with -EBUSY?

On AN7583, hsuart_pins covers only the TX/RX pins (30 and 31) and
hsuart_cts_rts_pins covers only the CTS/RTS pins (28 and 29), and their
regmap[1] entries clear the force-GPIO bits for those disjoint pin sets
(BIT(28) | BIT(29) vs BIT(26) | BIT(27)).  Enabling HSUART with flow
control therefore requires selecting both groups, just like "uart2" and
"uart2_cts_rts".  However, unlike "uart2" (whose regmap[0].mask is only
GPIO_UART2_MODE_MASK), "hsuart" includes GPIO_HSUART_CTS_RTS_MODE_MASK in
regmap[0].mask with value 0 while "hsuart_cts_rts" sets that bit to 1, so
airoha_pinmux_check_conflicts() rejects combining them.  Conversely,
selecting "hsuart_cts_rts" alone leaves the TX/RX pins unclaimed and their
force-GPIO overrides (BIT(28) | BIT(29)) uncleared.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110094339.749110-1-zhengping.zhang@airoha.com?part=9

  reply	other threads:[~2026-11-10  9:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  9:43 [PATCH 00/12] pinctrl: airoha: configure GPIO muxes explicitly and fix pad mappings Zhengping Zhang
2026-11-10  9:43 ` [PATCH 01/12] pinctrl: airoha: fix setting of GPIO direction Zhengping Zhang
2026-11-10  9:53   ` sashiko-bot
2026-11-10  9:43 ` [PATCH 02/12] pinctrl: airoha: configure pin muxes on GPIO requests Zhengping Zhang
2026-11-10 10:14   ` sashiko-bot
2026-11-10  9:43 ` [PATCH 03/12] dt-bindings: pinctrl: airoha: describe all EN7581 GPIO mux groups Zhengping Zhang
2026-11-10  9:43 ` [PATCH 04/12] pinctrl: airoha: an7581: fix PHY LED GPIO group assignments Zhengping Zhang
2026-11-10  9:43 ` [PATCH 05/12] pinctrl: airoha: an7581: select force GPIO mode on GPIO requests Zhengping Zhang
2026-11-10 10:00   ` sashiko-bot
2026-11-10  9:43 ` [PATCH 06/12] dt-bindings: pinctrl: airoha: describe all AN7583 GPIO mux groups Zhengping Zhang
2026-11-10  9:43 ` [PATCH 07/12] pinctrl: airoha: an7583: fix SPI pin mux config Zhengping Zhang
2026-11-10  9:43 ` [PATCH 08/12] pinctrl: airoha: an7583: fix eMMC " Zhengping Zhang
2026-11-10  9:43 ` [PATCH 09/12] pinctrl: airoha: an7583: use force GPIO mode for GPIO requests Zhengping Zhang
2026-11-10  9:56   ` sashiko-bot [this message]
2026-11-10  9:43 ` [PATCH 10/12] dt-bindings: pinctrl: airoha: describe all EN7523 GPIO mux groups Zhengping Zhang
2026-11-10  9:43 ` [PATCH 11/12] pinctrl: airoha: en7523: use force GPIO mode for GPIO requests Zhengping Zhang
2026-11-10  9:43 ` [PATCH 12/12] MAINTAINERS: add myself as Airoha pinctrl co-maintainer Zhengping Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-206817@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zhengping.zhang@airoha.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox