[PATCH 3/4] spi: cadence: Use reset_reset_bulk() for proper reset cycling

[Simon Glass]

Hi Michal,

On 2026-04-30T12:20:00, Michal Simek <michal.simek at amd.com> wrote:
> spi: cadence: Use reset_reset_bulk() for proper reset cycling
>
> Use the new reset_reset_bulk() API to properly cycle reset signals
> during probe instead of just deasserting them. This ensures the
> controller is properly reset before initialization.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>
>
> drivers/spi/cadence_qspi.c | 19 ++-----------------
>  1 file changed, 2 insertions(+), 17 deletions(-)

> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
> -             udelay(10);
> -
> -             /* Deassert all OSPI reset lines */
> -             ret = reset_deassert_bulk(priv->resets);
> -             if (ret) {
> -                     dev_err(bus, "Failed to deassert OSPI reset: %d\n", ret);
> -                     return ret;
> -             }
> -     }
> +     if (priv->resets)
> +             reset_reset_bulk(priv->resets);

This silently drops the 10us delay that commit 834d589b8f1 ('spi:
cadence_qspi: pulse controller reset at probe') deliberately added
between assert and deassert. Is that intended?

> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
> +     if (priv->resets)
> +             reset_reset_bulk(priv->resets);

The return value is now discarded - is that intended?

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon