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

Hi Philipp,

On Thu, 6 Aug 2026 at 10:18, Philipp Zabel <[email protected]> wrote:
> On Mo, 2026-08-03 at 15:14 +0200, Geert Uytterhoeven wrote:
> > 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.
> > >
> > > Signed-off-by: Wolfram Sang <[email protected]>
> >
> > Thanks for your patch, which is now commit 87e713f200481106 ("i2c:
> > rcar: add R-Car Gen5 support") in i2c/i2c/i2c-next.
> >
> > > --- a/drivers/i2c/busses/i2c-rcar.c
> > > +++ b/drivers/i2c/busses/i2c-rcar.c
> >
> > > @@ -900,8 +901,12 @@ static int rcar_i2c_do_reset(struct rcar_i2c_priv *priv)
> > >         if (ret)
> > >                 return ret;
> > >
> > > -       return read_poll_timeout_atomic(reset_control_status, ret, ret == 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, ret, ret == 0,
> > > +                                               1, 100, false, priv->rstc);
> >
> > How to differentiate between using SCMI and running on bare metal?
> > The latter still needs polling.
> >
> > 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().

This could indeed be moved into the reset driver. However, that
means the reset driver needs to become aware of the peculiarities
of the various target devices on the various SoCs.  We already have
something similar for module stop delays on RZ/V2H, though.
And it means more dependencies to track when adding driver support.

Then there's still the user in the PCIe driver[2], which can't be
handled like that.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=renesas-clk-for-v7.3-tag1&id=0a6643b1a5ee72f76ed0c606c1b34c7cf632cbfb
[2] https://elixir.bootlin.com/linux/v7.1.5/source/drivers/pci/controller/dwc/pcie-rcar-gen4.c#L185

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds