Re: [PATCH v2 2/2] i2c: rcar: add R-Car Gen5 support

On Mo, 2026-08-03 at 15:14 +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
>=20
> On Mon, 27 Jul 2026 at 14:26, Wolfram Sang
> <[email protected]> wrote:
> > To support the next generation of R-Car SoCs, we need to skip polling
> > the reset status. SCMI doesn't support it and the firmware must take
> > care of this anyhow. Other than that, the driver works fine as-is.
> >=20
> > Signed-off-by: Wolfram Sang <[email protected]>
>=20
> Thanks for your patch, which is now commit 87e713f200481106 ("i2c:
> rcar: add R-Car Gen5 support") in i2c/i2c/i2c-next.
>=20
> > --- a/drivers/i2c/busses/i2c-rcar.c
> > +++ b/drivers/i2c/busses/i2c-rcar.c
>=20
> > @@ -900,8 +901,12 @@ static int rcar_i2c_do_reset(struct rcar_i2c_priv =
*priv)
> >         if (ret)
> >                 return ret;
> >=20
> > -       return read_poll_timeout_atomic(reset_control_status, ret, ret =
=3D=3D 0, 1,
> > -                                       100, false, priv->rstc);
> > +       /* SCMI based resets don't need to poll for success */
> > +       if (priv->devtype < I2C_RCAR_GEN5)
> > +               return read_poll_timeout_atomic(reset_control_status, r=
et, ret =3D=3D 0,
> > +                                               1, 100, false, priv->rs=
tc);
>=20
> How to differentiate between using SCMI and running on bare metal?
> The latter still needs polling.
>=20
> I think you should call reset_control_status() first, and check for
> -ENOTSUPP, which would indicate that reset status is not available.

Ah, I suppose this driver is what you need .reset and .status for in
the R-Car X5H MDLC driver?

Seeing this, I wonder: could the status poll be moved into the reset
controller driver(s)? That would leave this driver with a simple,
unconditional reset_control_reset().

regards
Philipp
>=20