[PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

devm_gpiod_get_optional() may return -EPROBE_DEFER or other errors,
but mcp23s08_probe_one() currently ignores them.

Check the return value and propagate errors from the reset GPIO lookup.

Fixes: 4e73bfa3ee37 ("pinctrl: mcp23s08: Add optional reset GPIO")
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v2:
 -return ERR_PTR(-EPROBE_DEFER) instead of uninitialized ret variable

 drivers/pinctrl/pinctrl-mcp23s08.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c
index cc668f84bf8b..259ac02134c6 100644
--- a/drivers/pinctrl/pinctrl-mcp23s08.c
+++ b/drivers/pinctrl/pinctrl-mcp23s08.c
@@ -613,6 +613,9 @@ int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
 	mcp->chip.owner = THIS_MODULE;
 
 	mcp->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(mcp->reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(mcp->reset_gpio),
+				     "failed to get reset GPIO\n");
 
 	/* verify MCP_IOCON.SEQOP = 0, so sequential reads work,
 	 * and MCP_IOCON.HAEN = 1, so we work with all chips.
-- 
2.43.0

Re: [PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pinctrl: mcp23s08: multi-device probe failure due to duplicate reset GPIO request
--

commit 95196894afec909a218e9bd99fc8884c93869fc7
Author: bui duc phuc <phucduc.bui@gmail.com>

pinctrl: mcp23s08: Propagate reset GPIO errors

This commit adds a check for the return value of devm_gpiod_get_optional() in
mcp23s08_probe_one() to propagate errors instead of ignoring them.

> diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c
> index cc668f84bf8bc..259ac02134c64 100644
> --- a/drivers/pinctrl/pinctrl-mcp23s08.c
> +++ b/drivers/pinctrl/pinctrl-mcp23s08.c
> @@ -613,6 +613,9 @@ int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
>  	mcp->chip.owner = THIS_MODULE;
>  
>  	mcp->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> +	if (IS_ERR(mcp->reset_gpio))
> +		return dev_err_probe(dev, PTR_ERR(mcp->reset_gpio),
> +				     "failed to get reset GPIO\n");

[Severity: High]
Does this cause a regression for multi-chip SPI configurations by aborting the
probe due to -EBUSY?

In the SPI driver, multiple physical chips can share a single SPI chip select.
This is handled in drivers/pinctrl/pinctrl-mcp23s08_spi.c:mcp23s08_probe() by
iterating over spi_present_mask and calling mcp23s08_probe_one() for each:

drivers/pinctrl/pinctrl-mcp23s08_spi.c:mcp23s08_probe() {
	...
	for_each_set_bit(addr, &spi_present_mask, MCP_MAX_DEV_PER_CS) {
		...
		ret = mcp23s08_probe_one(data->mcp[addr], dev, MCP23S08_SPI_BASE | (addr << 1),
					 info->type, -1);
		if (ret < 0)
			return ret;
	}
	...
}

Because all logical chips share the same SPI device, the same struct device
*dev pointer is passed to every mcp23s08_probe_one() call.

During the first iteration, the reset GPIO is successfully requested
exclusively.

During the second iteration, devm_gpiod_get_optional() is called again on the
same dev pointer for the same "reset" connection ID. The GPIO core will
attempt to request the same descriptor again, which will return -EBUSY because
it is already requested and does not use GPIOD_FLAGS_BIT_NONEXCLUSIVE.

Prior to this patch, the -EBUSY error was ignored, allowing the second and
subsequent chips to probe successfully (which was safe since the reset line
was already asserted and deasserted by the first chip).

>  
>  	/* verify MCP_IOCON.SEQOP = 0, so sequential reads work,
>  	 * and MCP_IOCON.HAEN = 1, so we work with all chips.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012015433.6155-1-phucduc.bui@gmail.com?part=1

Re: [PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[Bui Duc Phuc]

>
> [Severity: High]
> Does this cause a regression for multi-chip SPI configurations by aborting the
> probe due to -EBUSY?
>
> In the SPI driver, multiple physical chips can share a single SPI chip select.
> This is handled in drivers/pinctrl/pinctrl-mcp23s08_spi.c:mcp23s08_probe() by
> iterating over spi_present_mask and calling mcp23s08_probe_one() for each:
>
> drivers/pinctrl/pinctrl-mcp23s08_spi.c:mcp23s08_probe() {
>         ...
>         for_each_set_bit(addr, &spi_present_mask, MCP_MAX_DEV_PER_CS) {
>                 ...
>                 ret = mcp23s08_probe_one(data->mcp[addr], dev, MCP23S08_SPI_BASE | (addr << 1),
>                                          info->type, -1);
>                 if (ret < 0)
>                         return ret;
>         }
>         ...
> }
>
> Because all logical chips share the same SPI device, the same struct device
> *dev pointer is passed to every mcp23s08_probe_one() call.
>
> During the first iteration, the reset GPIO is successfully requested
> exclusively.
>
> During the second iteration, devm_gpiod_get_optional() is called again on the
> same dev pointer for the same "reset" connection ID. The GPIO core will
> attempt to request the same descriptor again, which will return -EBUSY because
> it is already requested and does not use GPIOD_FLAGS_BIT_NONEXCLUSIVE.
>
> Prior to this patch, the -EBUSY error was ignored, allowing the second and
> subsequent chips to probe successfully (which was safe since the reset line
> was already asserted and deasserted by the first chip).
>
> >
> >       /* verify MCP_IOCON.SEQOP = 0, so sequential reads work,
> >        * and MCP_IOCON.HAEN = 1, so we work with all chips.
>



I looked at how the cs35l35 and aic3x drivers handle -EBUSY
when the reset GPIO is shared:
- cs35l35: https://elixir.bootlin.com/linux/v7.3-rc6/source/sound/soc/codecs/cs35l35.c#L1524
- aic3x: https://elixir.bootlin.com/linux/v7.3-rc6/source/sound/soc/codecs/tlv320aic3x.c#L1815

I think handling -EBUSY similarly to cs35l35 may be more
appropriate here, preserving the existing behavior for shared
reset GPIOs while propagating other errors.

Linus, could you confirm whether this approach would be OK for
mcp23s08?

Best regards,
Phuc

Re: [PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[Linus Walleij]

On Mon, Oct 12, 2026 at 7:53 AM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:

> Linus, could you confirm whether this approach would be OK for
> mcp23s08?

I don't understand Sashiko's fringe use-case rambling here,
I think the patch is fine.

Yours,
Linus Walleij

Re: [PATCH v2] pinctrl: mcp23s08: Propagate reset GPIO errors

[Bui Duc Phuc]

Hi Linus,

Thanks for confirming.

>
> I don't understand Sashiko's fringe use-case rambling here,
> I think the patch is fine.
>

I'll keep the patch as proposed.

Best regards,
Phuc