[PATCH v2 0/2] i2c: rcar: add Gen5 support

[PATCH v2 0/2] i2c: rcar: add Gen5 support

[Wolfram Sang]

Change since v1: * require resets, too

This small series adds support for the Renesas R-Car X5H SoC to the
i2c-rcar driver. Not much changes needed, only skip polling for reset.
And add some compatibles.

Tested with a Renesas R-Car Gen5 Ironhide board. Branch is here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/x5h/i2c-experimental

'dt_binding_check' also passed.

Happy hacking!


Minh Le (1):
  dt-bindings: i2c: rcar-i2c: Document R-Car X5H support

Wolfram Sang (1):
  i2c: rcar: add R-Car Gen5 support

 .../bindings/i2c/renesas,rcar-i2c.yaml        |  6 +++++
 drivers/i2c/busses/i2c-rcar.c                 | 22 ++++++++++++++-----
 2 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.47.3

[PATCH v2 1/2] dt-bindings: i2c: rcar-i2c: Document R-Car X5H support

[Wolfram Sang]

From: Minh Le <minh.le.aj@renesas.com>

Document support for rcar-i2c on R8A78000 (X5H) SoCs.

Signed-off-by: Minh Le <minh.le.aj@renesas.com>
[wsa: fixed white space issues, added reset requirement]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Change since v1: * require resets, too

 Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
index 6cc60c3f61cd..f9ede03c3287 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
@@ -56,6 +56,11 @@ properties:
               - renesas,i2c-r8a779h0     # R-Car V4M
           - const: renesas,rcar-gen4-i2c # R-Car Gen4
 
+      - items:
+          - enum:
+              - renesas,i2c-r8a78000     # R-Car X5H
+          - const: renesas,rcar-gen5-i2c # R-Car Gen5
+
   reg:
     maxItems: 1
 
@@ -140,6 +145,7 @@ allOf:
               - renesas,rcar-gen2-i2c
               - renesas,rcar-gen3-i2c
               - renesas,rcar-gen4-i2c
+              - renesas,rcar-gen5-i2c
     then:
       required:
         - resets
-- 
2.47.3

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

[Wolfram Sang]

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 <wsa+renesas@sang-engineering.com>
---
Change since v1: * none

 drivers/i2c/busses/i2c-rcar.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 5ce8f8e4856f..46508176712c 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -137,6 +137,7 @@ enum rcar_i2c_type {
 	I2C_RCAR_GEN2,
 	I2C_RCAR_GEN3,
 	I2C_RCAR_GEN4,
+	I2C_RCAR_GEN5,
 };
 
 struct rcar_i2c_priv {
@@ -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);
+
+	return 0;
 }
 
 static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
@@ -1111,6 +1116,7 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
 	{ .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
 	{ .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
 	{ .compatible = "renesas,rcar-gen4-i2c", .data = (void *)I2C_RCAR_GEN4 },
+	{ .compatible = "renesas,rcar-gen5-i2c", .data = (void *)I2C_RCAR_GEN5 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
@@ -1194,9 +1200,15 @@ static int rcar_i2c_probe(struct platform_device *pdev)
 			goto out_pm_put;
 		}
 
-		ret = reset_control_status(priv->rstc);
-		if (ret < 0)
-			goto out_pm_put;
+		/*
+		 * Gen5+ uses SCMI based reset which cannot report status.
+		 * Firmware has to ensure proper reset
+		 */
+		if (priv->devtype < I2C_RCAR_GEN5) {
+			ret = reset_control_status(priv->rstc);
+			if (ret < 0)
+				goto out_pm_put;
+		}
 
 		/* hard reset disturbs HostNotify local target, so disable it */
 		priv->flags &= ~ID_P_HOST_NOTIFY;
-- 
2.47.3

Re: [PATCH v2 0/2] i2c: rcar: add Gen5 support

[Andi Shyti]

Hi Wolfram,

> Minh Le (1):
>   dt-bindings: i2c: rcar-i2c: Document R-Car X5H support
> 
> Wolfram Sang (1):
>   i2c: rcar: add R-Car Gen5 support

merged to i2c/i2c.

Thanks,
Andi

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

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, 27 Jul 2026 at 14:26, Wolfram Sang
<wsa+renesas@sang-engineering.com> 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 <wsa+renesas@sang-engineering.com>

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.

> +
> +       return 0;
>  }
>
>  static int rcar_i2c_master_xfer(struct i2c_adapter *adap,

> @@ -1194,9 +1200,15 @@ static int rcar_i2c_probe(struct platform_device *pdev)
>                         goto out_pm_put;
>                 }
>
> -               ret = reset_control_status(priv->rstc);
> -               if (ret < 0)
> -                       goto out_pm_put;
> +               /*
> +                * Gen5+ uses SCMI based reset which cannot report status.
> +                * Firmware has to ensure proper reset
> +                */
> +               if (priv->devtype < I2C_RCAR_GEN5) {
> +                       ret = reset_control_status(priv->rstc);
> +                       if (ret < 0)
> +                               goto out_pm_put;
> +               }

Likewise, i.e. call reset_control_status() unconditionally, and
ignore -ENOTSUPP.

>
>                 /* hard reset disturbs HostNotify local target, so disable it */
>                 priv->flags &= ~ID_P_HOST_NOTIFY;

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]


> 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.

Okay, will send an incremental patch to handle the bare metal case.

Thank you!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Philipp Zabel]

On Mo, 2026-08-03 at 15:14 +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Mon, 27 Jul 2026 at 14:26, Wolfram Sang
> <wsa+renesas@sang-engineering.com> 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 <wsa+renesas@sang-engineering.com>
> 
> 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().

regards
Philipp
> 

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

[Geert Uytterhoeven]

Hi Philipp,

On Thu, 6 Aug 2026 at 10:18, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Mo, 2026-08-03 at 15:14 +0200, Geert Uytterhoeven wrote:
> > On Mon, 27 Jul 2026 at 14:26, Wolfram Sang
> > <wsa+renesas@sang-engineering.com> 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 <wsa+renesas@sang-engineering.com>
> >
> > 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 -- geert@linux-m68k.org

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