[PATCH v7 0/7] Add initial USB support for the Renesas RZ/G3S SoC

[PATCH v7 0/7] Add initial USB support for the Renesas RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Hi,

Series adds initial USB support for the Renesas RZ/G3S SoC.

Series is split as follows:
- patches 1-2/7		- fixes on bindings and driver for USB PHY
- patches 3-5/7		- updates the rzg2l-usbphy-ctrl driver and documentation
			  with support for setting PWRRDY though SYSC
- patches 6-7/7		- add device tree support

Merge strategy, if any:
- patches 1-2/7 can go through the PHY tree
- patches 3-5/7 can go through the reset tree
- patches 6-7/7 can go through Renesas tree

Thank you,
Claudiu Beznea

Changes in v7:
- used proper regmap update value for PWRRDY
- collected tags
- dropped Tb tags from dt-bindings

Changes in v6:
- in patch 2/7 dropped the struct rcar_gen3_chan::rstc as it is not
  used anymore
- in patch 4/7 used syscon_regmap_lookup_by_phandle_args()
- collected tags

Changes in v5:
- dropped patch "soc: renesas: rz-sysc: Add syscon/regmap support" as it
  already modified and pubished also at [2] with the latest review comments
  addressed
- fixed the documentation

Changes in v4:
- replaced "renesas,sysc-signals" DT property with "renesas,sysc-pwrrdy"
- dropped the "renesas,sysc-signals" property from USB PHY (as proposed
  in v3) and let only the USB PHY CTRL driver to handle it as on RZ/G3S
  the USB PHY CTRL driver needs to be probed before any other USB driver
- dropped the signal abstraction from SYSC driver as there is no need
  for reference counting it now
- adjusted the "soc: renesas: rz-sysc: Add syscon/regmap support" to
  comply with the latest review comments

Changes in v3:
- as the basics of the SYSC driver was integrated, only the signal support
  was preserved in this series, in a separate patch; patch 01/12 was
  adjusted (by addressing the review comments received at [1]) as it is
  necessary to build the signal support on top of it
- after long discussions with the internal HW team it has been confirmed
  that the relation b/w individual USB specific HW blocks and signals
  is like:

                                   ┌──────────────────────────────┐
                                   │                              │◄── CPG_CLKON_USB.CLK0_ON
                                   │     USB CH0                  │
    ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
    │                 ┌────────┐   ││host controller registers  │ │
    │                 │        │   ││function controller registers│
    │                 │ PHY0   │◄──┤└───────────────────────────┘ │
    │     USB PHY     │        │   └────────────▲─────────────────┘
    │                 └────────┘                │
    │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
    │┌──────────────┐ ┌────────┐
    ││USBPHY control│ │        │
    ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
    │└──────────────┘ │        │◄──┤     USB CH1                  │
    │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
    └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
      │       │         │          │└───────────────────────────┘ │
      │       │         │          └────────────▲─────────────────┘
      │       │         │                       │
      │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
      │PWRRDY │         │
      │       │   CPG_CLK_ON_USB.CLK3_ON
      │       │
      │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
      │
    ┌────┐
    │SYSC│
    └────┘

  where:
  - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
      of different USB blocks, X in {0, 1, 2, 3}
  - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
    MSTOP of different USB blocks, X in {4, 5, 6, 7}
  - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
    by the USB CH0, USB CH1
  - SYSC is the system controller block controlling the PWRRDY signal
  - USB CHx are individual USB block with host and function capabilities
    (USB CH0 have both host and function capabilities, USB CH1 has only
    host capabilities)

  Due to this, the PWRRDY signal was also passed to the reset-rzg2l-usbphy-ctrl
  reset driver (as it controls the USBPHY control registers) and these
  are in the USB PHY block controlled by PWRRDY signal.

  The PWRRDY signal need to be de-asserted on probe before enabling the module
  clocks and the module MSTOP. To avoid any violation of this configuration
  sequence, the PWRRDY signal is now controlled by USB PHY driver and the
  reset-rzg2l-usbphy-ctrl driver.

  As the PHYs gets reset signals from the USB reset controller driver, the
  reset-rzg2l-usbphy-ctrl is probed before the USB PHY driver and thus,
  in theory, we can drop the signal support (reference counting of the
  USB PWRRDY) and configure the USB PWRRDY just in the reset-rzg2l-usbphy-ctrl.

  However, to have a proper description of the diagram described above in 
  device tree and ensure the configuration sequence b/w PRWRDY, CLK and MSTOP
  is preserved, the PWRRDY signal is controlled in this series in all the
  drivers that work with registers from the USB PHY block.

  Please provide your feedback on this solution.

Thank you,
Claudiu

[1] https://lore.kernel.org/all/20250330214945.185725-2-john.madieu.xa@bp.renesas.com/
[2] https://lore.kernel.org/all/20250818162859.9661-2-john.madieu.xa@bp.renesas.com/

Changes in v2:
- dropped v1 patches already applied
- added fixes patches (07/14 and 09/14)
- dropped the approach of handling the USB PWRRDY though a reset controller
  driver and introduced the signal concept for the SYSC driver; because
  of this, most of the work done in v1 was dropped
- per patch changes are listed in individual patches, if any

Christophe JAILLET (1):
  phy: renesas: rcar-gen3-usb2: Fix an error handling path in
    rcar_gen3_phy_usb2_probe()

Claudiu Beznea (6):
  dt-bindings: phy: renesas,usb2-phy: Mark resets as required for RZ/G3S
  dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support
  reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY
  reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC
  arm64: dts: renesas: r9a08g045: Add USB support
  arm64: dts: renesas: rzg3s-smarc: Enable USB support

 .../bindings/phy/renesas,usb2-phy.yaml        |   1 +
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      |  41 +++++-
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi    | 118 ++++++++++++++++++
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi  |  57 +++++++++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  20 ++-
 drivers/reset/Kconfig                         |   1 +
 drivers/reset/reset-rzg2l-usbphy-ctrl.c       |  66 ++++++++++
 7 files changed, 292 insertions(+), 12 deletions(-)

-- 
2.43.0

[PATCH v7 1/7] dt-bindings: phy: renesas,usb2-phy: Mark resets as required for RZ/G3S

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The reset lines are mandatory for the Renesas RZ/G3S platform and must be
explicitly defined in device tree.

Fixes: f3c849855114 ("dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- dropped Tb tag as it was reported that it is not valid on bindings

Changes in v6:
- collected tags

Changes in v5:
- none

Changes in v4:
- none

Changes in v3:
- collected tags
- rebased on top of latest version of renesas,usb2-phy.yaml;
  Conor, Geert: I kept your tags; please let me know if you consider it
  otherwise

Changes in v2:
- none; this patch is new

 Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index 179cb4bfc424..2bbec8702a1e 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -118,6 +118,7 @@ allOf:
           contains:
             enum:
               - renesas,usb2-phy-r9a09g057
+              - renesas,usb2-phy-r9a08g045
               - renesas,rzg2l-usb2-phy
     then:
       properties:
-- 
2.43.0

[PATCH v7 2/7] phy: renesas: rcar-gen3-usb2: Fix an error handling path in rcar_gen3_phy_usb2_probe()

[Claudiu]

From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

If an error occurs after the reset_control_deassert(),
reset_control_assert() must be called, as already done in the remove
function.

Use devm_add_action_or_reset() to add the missing call and simplify the
.remove() function accordingly.

While at it, drop struct rcar_gen3_chan::rstc as it is not used aymore.

Fixes: 4eae16375357 ("phy: renesas: rcar-gen3-usb2: Add support to initialize the bus")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[claudiu.beznea: removed "struct reset_control *rstc = data;" from
 rcar_gen3_reset_assert(), dropped struct rcar_gen3_chan::rstc]
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- none

Changes in v6:
- dropped struct rcar_gen3_chan::rstc; updated the patch description
  to reflect it
- collected tags

Changes in v5:
- none

Changes in v4:
- none

Changes in v3:
- collected tags

Changes in v2:
- none; this patch is new; re-spinned the Christophe's work at
  https://lore.kernel.org/all/TYCPR01MB113329930BA5E2149C9BE2A1986672@TYCPR01MB11332.jpnprd01.prod.outlook.com/
  
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 3f6b480e1092..a38ead7c8055 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -134,7 +134,6 @@ struct rcar_gen3_chan {
 	struct extcon_dev *extcon;
 	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
 	struct regulator *vbus;
-	struct reset_control *rstc;
 	struct work_struct work;
 	spinlock_t lock;	/* protects access to hardware and driver data structure. */
 	enum usb_dr_mode dr_mode;
@@ -771,21 +770,31 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
 	return candidate;
 }
 
+static void rcar_gen3_reset_assert(void *data)
+{
+	reset_control_assert(data);
+}
+
 static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
 {
 	struct device *dev = channel->dev;
+	struct reset_control *rstc;
 	int ret;
 	u32 val;
 
-	channel->rstc = devm_reset_control_array_get_shared(dev);
-	if (IS_ERR(channel->rstc))
-		return PTR_ERR(channel->rstc);
+	rstc = devm_reset_control_array_get_shared(dev);
+	if (IS_ERR(rstc))
+		return PTR_ERR(rstc);
 
 	ret = pm_runtime_resume_and_get(dev);
 	if (ret)
 		return ret;
 
-	ret = reset_control_deassert(channel->rstc);
+	ret = reset_control_deassert(rstc);
+	if (ret)
+		goto rpm_put;
+
+	ret = devm_add_action_or_reset(dev, rcar_gen3_reset_assert, rstc);
 	if (ret)
 		goto rpm_put;
 
@@ -924,7 +933,6 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
 	if (channel->is_otg_channel)
 		device_remove_file(&pdev->dev, &dev_attr_role);
 
-	reset_control_assert(channel->rstc);
 	pm_runtime_disable(&pdev->dev);
 };
 
-- 
2.43.0

[PATCH v7 3/7] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas USB PHY hardware block needs to have the PWRRDY bit in the
system controller set before applying any other settings. The PWRRDY bit
must be controlled during power-on, power-off, and system suspend/resume
sequences as follows:
- during power-on/resume, it must be set to zero before enabling clocks and
  modules
- during power-off/suspend, it must be set to one after disabling clocks
  and modules

Add the renesas,sysc-pwrrdy device tree property, which allows the
reset-rzg2l-usbphy-ctrl driver to parse, map, and control the system
controller PWRRDY bit at the appropriate time. Along with it add a new
compatible for the RZ/G3S SoC.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- dropped Tb tag as it was reported that it is not valid on bindings

Changes in v6:
- collected tags

Changes in v5:
- fixed description formatting
- collected tags

Changes in v4:
- dropped blank line from compatible section
- s/renesas,sysc-signals/renesas,sysc-pwrrdy/g
- dropped description from renesas,sysc-pwrrdy
- updated description of renesas,sysc-pwrrdy items
- updated patch description

Changes in v3:
- none; this patch is new

 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      | 41 ++++++++++++++++---
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
index b0b20af15313..c83469a1b379 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
@@ -15,12 +15,14 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
-          - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
-          - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
-      - const: renesas,rzg2l-usbphy-ctrl
+    oneOf:
+      - items:
+          - enum:
+              - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
+              - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
+              - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
+          - const: renesas,rzg2l-usbphy-ctrl
+      - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
 
   reg:
     maxItems: 1
@@ -48,6 +50,20 @@ properties:
     $ref: /schemas/regulator/regulator.yaml#
     unevaluatedProperties: false
 
+  renesas,sysc-pwrrdy:
+    description:
+      The system controller PWRRDY indicates to the USB PHY if the power supply
+      is ready. PWRRDY needs to be set during power-on before applying any
+      other settings. It also needs to be set before powering off the USB.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      - items:
+          - description:
+              System controller phandle required by USB PHY CTRL driver to set
+              PWRRDY
+          - description: Register offset associated with PWRRDY
+          - description: Register bitmask associated with PWRRDY
+
 required:
   - compatible
   - reg
@@ -57,6 +73,19 @@ required:
   - '#reset-cells'
   - regulator-vbus
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-usbphy-ctrl
+    then:
+      required:
+        - renesas,sysc-pwrrdy
+    else:
+      properties:
+        renesas,sysc-pwrrdy: false
+
 additionalProperties: false
 
 examples:
-- 
2.43.0

[PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
PWRRDY. This signal is managed by the system controller and must be
de-asserted after powering on the area where USB PHY resides and asserted
before powering it off.

On power-on the USB PWRRDY signal need to be de-asserted before enabling
clock and switching the module to normal state (through MSTOP support). The
power-on configuration sequence must be:

1/ PWRRDY=0
2/ CLK_ON=1
3/ MSTOP=0

On power-off the configuration sequence should be:

1/ MSTOP=1
2/ CLK_ON=0
3/ PWRRDY=1

The CLK_ON and MSTOP functionalities are controlled by clock drivers.

After long discussions with the internal HW team, it has been confirmed
that the HW connection b/w USB PHY block, the USB channels, the system
controller, clock, MSTOP, PWRRDY signal is as follows:

                               ┌──────────────────────────────┐
                               │                              │◄── CPG_CLKON_USB.CLK0_ON
                               │     USB CH0                  │
┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
│                 ┌────────┐   ││host controller registers  │ │
│                 │        │   ││function controller registers│
│                 │ PHY0   │◄──┤└───────────────────────────┘ │
│     USB PHY     │        │   └────────────▲─────────────────┘
│                 └────────┘                │
│                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
│┌──────────────┐ ┌────────┐
││USHPHY control│ │        │
││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
│└──────────────┘ │        │◄──┤     USB CH1                  │
│                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
└─▲───────▲─────────▲──────┘   ││ host controller registers │ │
  │       │         │          │└───────────────────────────┘ │
  │       │         │          └────────────▲─────────────────┘
  │       │         │                       │
  │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
  │PWRRDY │         │
  │       │   CPG_CLK_ON_USB.CLK3_ON
  │       │
  │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
  │
┌────┐
│SYSC│
└────┘

where:
- CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
  of different USB blocks, X in {0, 1, 2, 3}
- CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
  MSTOP of different USB blocks, X in {4, 5, 6, 7}
- USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
  by the USB CH0, USB CH1
- SYSC is the system controller block controlling the PWRRDY signal
- USB CHx are individual USB block with host and function capabilities
  (USB CH0 have both host and function capabilities, USB CH1 has only
  host capabilities)

The USBPHY control registers are controlled though the
reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.

The connection b/w the system controller and the USB PHY CTRL driver is
implemented through the renesas,sysc-pwrrdy device tree property
proposed in this patch. This property specifies the register offset and the
bitmask required to control the PWRRDY signal.

Since the USB PHY CTRL driver needs to be probed before any other
USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
to it. This guarantees the correct configuration sequence between clocks,
MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
by avoiding modifications to the USB PHY driver to also handle the PWRRDY
itself.

Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()

Changes in v6:
- used syscon_regmap_lookup_by_phandle_args() to simplify the code
- collected tags

Changes in v5:
- none

Changes in v4:
- updated patch description
- updated rzg2l_usbphy_ctrl_pwrrdy_init() to map directly the
  "renesas,sysc-pwrrdy" as the SYSC signal abstraction was dropped
  in this version, along with rz_sysc_get_signal_map()
- dropped priv member of rzg2l_usbphy_ctrl_pwrrdy_init() as it is
  not needed in this version
- shift left !power_on with pwrrdy->mask as this is how the
  regmap_update_bits() needs the last member to be
- selected MFD_SYSCON

Changes in v3:
- none; this patch is new


 drivers/reset/Kconfig                   |  1 +
 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 62 +++++++++++++++++++++++++
 2 files changed, 63 insertions(+)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 78b7078478d4..329730cbcfb9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -237,6 +237,7 @@ config RESET_RASPBERRYPI
 config RESET_RZG2L_USBPHY_CTRL
 	tristate "Renesas RZ/G2L USBPHY control driver"
 	depends on ARCH_RZG2L || COMPILE_TEST
+	select MFD_SYSCON
 	help
 	  Support for USBPHY Control found on RZ/G2L family. It mainly
 	  controls reset and power down of the USB/PHY.
diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index 8a7f167e405e..be315199e2b0 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -13,6 +13,7 @@
 #include <linux/regmap.h>
 #include <linux/reset.h>
 #include <linux/reset-controller.h>
+#include <linux/mfd/syscon.h>
 
 #define RESET			0x000
 #define VBENCTL			0x03c
@@ -41,6 +42,18 @@ struct rzg2l_usbphy_ctrl_priv {
 
 #define rcdev_to_priv(x)	container_of(x, struct rzg2l_usbphy_ctrl_priv, rcdev)
 
+/**
+ * struct rzg2l_usbphy_ctrl_pwrrdy - SYSC PWRRDY signal descriptor
+ * @regmap: SYSC regmap
+ * @offset: offset into the SYSC address space for accessing PWRRDY
+ * @mask: mask into the register at offset for accessing PWRRDY
+ */
+struct rzg2l_usbphy_ctrl_pwrrdy {
+	struct regmap *regmap;
+	u32 offset;
+	u32 mask;
+};
+
 static int rzg2l_usbphy_ctrl_assert(struct reset_controller_dev *rcdev,
 				    unsigned long id)
 {
@@ -91,6 +104,8 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
 	return !!(readl(priv->base + RESET) & port_mask);
 }
 
+#define RZG2L_USBPHY_CTRL_PWRRDY	1
+
 static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
 	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
 	{ /* Sentinel */ }
@@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
 	.max_register = 1,
 };
 
+static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
+					 bool power_on)
+{
+	u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;
+
+	regmap_update_bits(pwrrdy->regmap, pwrrdy->offset, pwrrdy->mask, val);
+}
+
+static void rzg2l_usbphy_ctrl_pwrrdy_off(void *data)
+{
+	rzg2l_usbphy_ctrl_set_pwrrdy(data, false);
+}
+
+static int rzg2l_usbphy_ctrl_pwrrdy_init(struct device *dev)
+{
+	struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy;
+	struct regmap *regmap;
+	const int *data;
+	u32 args[2];
+
+	data = device_get_match_data(dev);
+	if (data != (int *)RZG2L_USBPHY_CTRL_PWRRDY)
+		return 0;
+
+	regmap = syscon_regmap_lookup_by_phandle_args(dev->of_node,
+						      "renesas,sysc-pwrrdy",
+						      ARRAY_SIZE(args), args);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	pwrrdy = devm_kzalloc(dev, sizeof(*pwrrdy), GFP_KERNEL);
+	if (!pwrrdy)
+		return -ENOMEM;
+
+	pwrrdy->regmap = regmap;
+	pwrrdy->offset = args[0];
+	pwrrdy->mask = args[1];
+
+	rzg2l_usbphy_ctrl_set_pwrrdy(pwrrdy, true);
+
+	return devm_add_action_or_reset(dev, rzg2l_usbphy_ctrl_pwrrdy_off, pwrrdy);
+}
+
 static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -132,6 +190,10 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
 	if (IS_ERR(regmap))
 		return PTR_ERR(regmap);
 
+	error = rzg2l_usbphy_ctrl_pwrrdy_init(dev);
+	if (error)
+		return error;
+
 	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
 	if (IS_ERR(priv->rstc))
 		return dev_err_probe(dev, PTR_ERR(priv->rstc),
-- 
2.43.0

[PATCH v7 5/7] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas RZ/G3S SoC USB PHY HW block receives as input the USB PWRRDY
signal from the system controller. Add support for the Renesas RZ/G3S SoC.

Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- none

Changes in v6:
- collected tags

Changes in v5:
- none

Changes in v4:
- none

Changes in v3:
- none; this patch is new


 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index be315199e2b0..b623a511e505 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -108,6 +108,10 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
 
 static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
 	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
+	{
+		.compatible = "renesas,r9a08g045-usbphy-ctrl",
+		.data = (void *)RZG2L_USBPHY_CTRL_PWRRDY
+	},
 	{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
-- 
2.43.0

[PATCH v7 6/7] arm64: dts: renesas: r9a08g045: Add USB support

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add USB nodes for the Renesas RZ/G3S SoC. This consists of PHY reset,
host and device support.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- collected tags

Changes in v6:
- collected tags

Changes in v5:
- none

Changes in v4:
- dropped renesas,sysc-signals from usb2_phy0, usb2_phy1 nodes
- s/renesas,sysc-signals/renesas,sysc-pwrrdy/g

Changes in v3:
- changed the nodes order to keep similar nodes toghether

 arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 118 +++++++++++++++++++++
 1 file changed, 118 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index 16e6ac614417..ab29b8365e26 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -717,6 +717,124 @@ eth1: ethernet@11c40000 {
 			status = "disabled";
 		};
 
+		phyrst: usbphy-ctrl@11e00000 {
+			compatible = "renesas,r9a08g045-usbphy-ctrl";
+			reg = <0 0x11e00000 0 0x10000>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+			resets = <&cpg R9A08G045_USB_PRESETN>;
+			power-domains = <&cpg>;
+			#reset-cells = <1>;
+			renesas,sysc-pwrrdy = <&sysc 0xd70 0x1>;
+			status = "disabled";
+
+			usb0_vbus_otg: regulator-vbus {
+				regulator-name = "vbus";
+			};
+		};
+
+		ohci0: usb@11e10000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e10000 0 0x100>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci1: usb@11e30000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e30000 0 0x100>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci0: usb@11e10100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e10100 0 0x100>;
+			interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 2>;
+			phy-names = "usb";
+			companion = <&ohci0>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci1: usb@11e30100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e30100 0 0x100>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 2>;
+			phy-names = "usb";
+			companion = <&ohci1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy0: usb-phy@11e10200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e10200 0 0x700>;
+			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy1: usb-phy@11e30200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e30200 0 0x700>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		hsusb: usb@11e20000 {
+			compatible = "renesas,usbhs-r9a08g045",
+				     "renesas,rzg2l-usbhs";
+			reg = <0 0x11e20000 0 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2P_EXR_CPUCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2P_EXL_SYSRST>;
+			renesas,buswait = <7>;
+			phys = <&usb2_phy0 3>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
 		gic: interrupt-controller@12400000 {
 			compatible = "arm,gic-v3";
 			#interrupt-cells = <3>;
-- 
2.43.0

[PATCH v7 7/7] arm64: dts: renesas: rzg3s-smarc: Enable USB support

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Enable USB support (host, device, USB PHYs).

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Changes in v7:
- none

Changes in v6:
- collected tags

Changes in v5:
- none

Changes in v4:
- none

Changes in v3:
- collected tags

Changes in v2:
- this was patch 15/16 in v1:
- dropped sysc enablement as it is now done in SoC dtsi file

 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi | 57 ++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
index 5e044a4d0234..5586dd43c4d5 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
@@ -92,6 +92,20 @@ &audio_clk2 {
 	clock-frequency = <12288000>;
 };
 
+&ehci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&hsusb {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &i2c0 {
 	status = "okay";
 
@@ -132,6 +146,15 @@ power-monitor@44 {
 	};
 };
 
+&ohci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
 &pinctrl {
 	audio_clock_pins: audio-clock {
 		pins = "AUDIO_CLK1", "AUDIO_CLK2";
@@ -207,6 +230,27 @@ ssi3_pins: ssi3 {
 			 <RZG2L_PORT_PINMUX(18, 4, 8)>, /* TXD */
 			 <RZG2L_PORT_PINMUX(18, 5, 8)>; /* RXD */
 	};
+
+	usb0_pins: usb0 {
+		peri {
+			pinmux = <RZG2L_PORT_PINMUX(5, 0, 1)>, /* VBUS */
+				 <RZG2L_PORT_PINMUX(5, 2, 1)>; /* OVC */
+		};
+
+		otg {
+			pinmux = <RZG2L_PORT_PINMUX(5, 3, 1)>; /* OTG_ID */
+			bias-pull-up;
+		};
+	};
+
+	usb1_pins: usb1 {
+		pinmux = <RZG2L_PORT_PINMUX(5, 4, 5)>, /* OVC */
+			 <RZG2L_PORT_PINMUX(6, 0, 1)>; /* VBUS */
+	};
+};
+
+&phyrst {
+	status = "okay";
 };
 
 &scif0 {
@@ -242,3 +286,16 @@ &ssi3 {
 	pinctrl-0 = <&ssi3_pins>, <&audio_clock_pins>;
 	status = "okay";
 };
+
+&usb2_phy0 {
+	pinctrl-0 = <&usb0_pins>;
+	pinctrl-names = "default";
+	vbus-supply = <&usb0_vbus_otg>;
+	status = "okay";
+};
+
+&usb2_phy1 {
+	pinctrl-0 = <&usb1_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
-- 
2.43.0

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, 25 Sept 2025 at 12:04, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
> PWRRDY. This signal is managed by the system controller and must be
> de-asserted after powering on the area where USB PHY resides and asserted
> before powering it off.
>
> On power-on the USB PWRRDY signal need to be de-asserted before enabling
> clock and switching the module to normal state (through MSTOP support). The
> power-on configuration sequence must be:
>
> 1/ PWRRDY=0
> 2/ CLK_ON=1
> 3/ MSTOP=0
>
> On power-off the configuration sequence should be:
>
> 1/ MSTOP=1
> 2/ CLK_ON=0
> 3/ PWRRDY=1
>
> The CLK_ON and MSTOP functionalities are controlled by clock drivers.
>
> After long discussions with the internal HW team, it has been confirmed
> that the HW connection b/w USB PHY block, the USB channels, the system
> controller, clock, MSTOP, PWRRDY signal is as follows:
>
>                                ┌──────────────────────────────┐
>                                │                              │◄── CPG_CLKON_USB.CLK0_ON
>                                │     USB CH0                  │
> ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
> │                 ┌────────┐   ││host controller registers  │ │
> │                 │        │   ││function controller registers│
> │                 │ PHY0   │◄──┤└───────────────────────────┘ │
> │     USB PHY     │        │   └────────────▲─────────────────┘
> │                 └────────┘                │
> │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
> │┌──────────────┐ ┌────────┐
> ││USHPHY control│ │        │
> ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
> │└──────────────┘ │        │◄──┤     USB CH1                  │
> │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
> └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>   │       │         │          │└───────────────────────────┘ │
>   │       │         │          └────────────▲─────────────────┘
>   │       │         │                       │
>   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>   │PWRRDY │         │
>   │       │   CPG_CLK_ON_USB.CLK3_ON
>   │       │
>   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>   │
> ┌────┐
> │SYSC│
> └────┘
>
> where:
> - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>   of different USB blocks, X in {0, 1, 2, 3}
> - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>   MSTOP of different USB blocks, X in {4, 5, 6, 7}
> - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>   by the USB CH0, USB CH1
> - SYSC is the system controller block controlling the PWRRDY signal
> - USB CHx are individual USB block with host and function capabilities
>   (USB CH0 have both host and function capabilities, USB CH1 has only
>   host capabilities)
>
> The USBPHY control registers are controlled though the
> reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
> phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
> USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
>
> The connection b/w the system controller and the USB PHY CTRL driver is
> implemented through the renesas,sysc-pwrrdy device tree property
> proposed in this patch. This property specifies the register offset and the
> bitmask required to control the PWRRDY signal.
>
> Since the USB PHY CTRL driver needs to be probed before any other
> USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
> to it. This guarantees the correct configuration sequence between clocks,
> MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
> by avoiding modifications to the USB PHY driver to also handle the PWRRDY
> itself.
>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>
> Changes in v7:
> - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()

Thanks for the update!

> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c

> @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
>         .max_register = 1,
>  };
>
> +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
> +                                        bool power_on)
> +{
> +       u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;

ffs(x) - 1 == __ffs(x)

> +
> +       regmap_update_bits(pwrrdy->regmap, pwrrdy->offset, pwrrdy->mask, val);
> +}

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 v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Geert,

On 9/25/25 13:15, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, 25 Sept 2025 at 12:04, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>> PWRRDY. This signal is managed by the system controller and must be
>> de-asserted after powering on the area where USB PHY resides and asserted
>> before powering it off.
>>
>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>> clock and switching the module to normal state (through MSTOP support). The
>> power-on configuration sequence must be:
>>
>> 1/ PWRRDY=0
>> 2/ CLK_ON=1
>> 3/ MSTOP=0
>>
>> On power-off the configuration sequence should be:
>>
>> 1/ MSTOP=1
>> 2/ CLK_ON=0
>> 3/ PWRRDY=1
>>
>> The CLK_ON and MSTOP functionalities are controlled by clock drivers.
>>
>> After long discussions with the internal HW team, it has been confirmed
>> that the HW connection b/w USB PHY block, the USB channels, the system
>> controller, clock, MSTOP, PWRRDY signal is as follows:
>>
>>                                ┌──────────────────────────────┐
>>                                │                              │◄── CPG_CLKON_USB.CLK0_ON
>>                                │     USB CH0                  │
>> ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
>> │                 ┌────────┐   ││host controller registers  │ │
>> │                 │        │   ││function controller registers│
>> │                 │ PHY0   │◄──┤└───────────────────────────┘ │
>> │     USB PHY     │        │   └────────────▲─────────────────┘
>> │                 └────────┘                │
>> │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
>> │┌──────────────┐ ┌────────┐
>> ││USHPHY control│ │        │
>> ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
>> │└──────────────┘ │        │◄──┤     USB CH1                  │
>> │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
>> └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>>   │       │         │          │└───────────────────────────┘ │
>>   │       │         │          └────────────▲─────────────────┘
>>   │       │         │                       │
>>   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>>   │PWRRDY │         │
>>   │       │   CPG_CLK_ON_USB.CLK3_ON
>>   │       │
>>   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>>   │
>> ┌────┐
>> │SYSC│
>> └────┘
>>
>> where:
>> - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>>   of different USB blocks, X in {0, 1, 2, 3}
>> - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>>   MSTOP of different USB blocks, X in {4, 5, 6, 7}
>> - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>>   by the USB CH0, USB CH1
>> - SYSC is the system controller block controlling the PWRRDY signal
>> - USB CHx are individual USB block with host and function capabilities
>>   (USB CH0 have both host and function capabilities, USB CH1 has only
>>   host capabilities)
>>
>> The USBPHY control registers are controlled though the
>> reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
>> phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
>> USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
>>
>> The connection b/w the system controller and the USB PHY CTRL driver is
>> implemented through the renesas,sysc-pwrrdy device tree property
>> proposed in this patch. This property specifies the register offset and the
>> bitmask required to control the PWRRDY signal.
>>
>> Since the USB PHY CTRL driver needs to be probed before any other
>> USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
>> to it. This guarantees the correct configuration sequence between clocks,
>> MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
>> by avoiding modifications to the USB PHY driver to also handle the PWRRDY
>> itself.
>>
>> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>
>> Changes in v7:
>> - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()
> 
> Thanks for the update!
> 
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> 
>> @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
>>         .max_register = 1,
>>  };
>>
>> +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
>> +                                        bool power_on)
>> +{
>> +       u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;
> 
> ffs(x) - 1 == __ffs(x)

OK, thank you! I'm going to wait for more feedback before updating it in a
new version.

Thank you for your review,
Claudiu

> 
>> +
>> +       regmap_update_bits(pwrrdy->regmap, pwrrdy->offset, pwrrdy->mask, val);
>> +}
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH v7 0/7] Add initial USB support for the Renesas RZ/G3S SoC

[Claudiu Beznea]

Hi,

Gentle ping. Apart from Geert's comment, could you please let me know if
there are other comments on this series?

Thank you,
Claudiu

On 9/25/25 13:02, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Hi,
> 
> Series adds initial USB support for the Renesas RZ/G3S SoC.
> 
> Series is split as follows:
> - patches 1-2/7		- fixes on bindings and driver for USB PHY
> - patches 3-5/7		- updates the rzg2l-usbphy-ctrl driver and documentation
> 			  with support for setting PWRRDY though SYSC
> - patches 6-7/7		- add device tree support
> 
> Merge strategy, if any:
> - patches 1-2/7 can go through the PHY tree
> - patches 3-5/7 can go through the reset tree
> - patches 6-7/7 can go through Renesas tree
> 
> Thank you,
> Claudiu Beznea
> 
> Changes in v7:
> - used proper regmap update value for PWRRDY
> - collected tags
> - dropped Tb tags from dt-bindings
> 
> Changes in v6:
> - in patch 2/7 dropped the struct rcar_gen3_chan::rstc as it is not
>   used anymore
> - in patch 4/7 used syscon_regmap_lookup_by_phandle_args()
> - collected tags
> 
> Changes in v5:
> - dropped patch "soc: renesas: rz-sysc: Add syscon/regmap support" as it
>   already modified and pubished also at [2] with the latest review comments
>   addressed
> - fixed the documentation
> 
> Changes in v4:
> - replaced "renesas,sysc-signals" DT property with "renesas,sysc-pwrrdy"
> - dropped the "renesas,sysc-signals" property from USB PHY (as proposed
>   in v3) and let only the USB PHY CTRL driver to handle it as on RZ/G3S
>   the USB PHY CTRL driver needs to be probed before any other USB driver
> - dropped the signal abstraction from SYSC driver as there is no need
>   for reference counting it now
> - adjusted the "soc: renesas: rz-sysc: Add syscon/regmap support" to
>   comply with the latest review comments
> 
> Changes in v3:
> - as the basics of the SYSC driver was integrated, only the signal support
>   was preserved in this series, in a separate patch; patch 01/12 was
>   adjusted (by addressing the review comments received at [1]) as it is
>   necessary to build the signal support on top of it
> - after long discussions with the internal HW team it has been confirmed
>   that the relation b/w individual USB specific HW blocks and signals
>   is like:
> 
>                                    ┌──────────────────────────────┐
>                                    │                              │◄── CPG_CLKON_USB.CLK0_ON
>                                    │     USB CH0                  │
>     ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
>     │                 ┌────────┐   ││host controller registers  │ │
>     │                 │        │   ││function controller registers│
>     │                 │ PHY0   │◄──┤└───────────────────────────┘ │
>     │     USB PHY     │        │   └────────────▲─────────────────┘
>     │                 └────────┘                │
>     │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
>     │┌──────────────┐ ┌────────┐
>     ││USBPHY control│ │        │
>     ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
>     │└──────────────┘ │        │◄──┤     USB CH1                  │
>     │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
>     └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>       │       │         │          │└───────────────────────────┘ │
>       │       │         │          └────────────▲─────────────────┘
>       │       │         │                       │
>       │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>       │PWRRDY │         │
>       │       │   CPG_CLK_ON_USB.CLK3_ON
>       │       │
>       │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>       │
>     ┌────┐
>     │SYSC│
>     └────┘
> 
>   where:
>   - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>       of different USB blocks, X in {0, 1, 2, 3}
>   - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>     MSTOP of different USB blocks, X in {4, 5, 6, 7}
>   - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>     by the USB CH0, USB CH1
>   - SYSC is the system controller block controlling the PWRRDY signal
>   - USB CHx are individual USB block with host and function capabilities
>     (USB CH0 have both host and function capabilities, USB CH1 has only
>     host capabilities)
> 
>   Due to this, the PWRRDY signal was also passed to the reset-rzg2l-usbphy-ctrl
>   reset driver (as it controls the USBPHY control registers) and these
>   are in the USB PHY block controlled by PWRRDY signal.
> 
>   The PWRRDY signal need to be de-asserted on probe before enabling the module
>   clocks and the module MSTOP. To avoid any violation of this configuration
>   sequence, the PWRRDY signal is now controlled by USB PHY driver and the
>   reset-rzg2l-usbphy-ctrl driver.
> 
>   As the PHYs gets reset signals from the USB reset controller driver, the
>   reset-rzg2l-usbphy-ctrl is probed before the USB PHY driver and thus,
>   in theory, we can drop the signal support (reference counting of the
>   USB PWRRDY) and configure the USB PWRRDY just in the reset-rzg2l-usbphy-ctrl.
> 
>   However, to have a proper description of the diagram described above in 
>   device tree and ensure the configuration sequence b/w PRWRDY, CLK and MSTOP
>   is preserved, the PWRRDY signal is controlled in this series in all the
>   drivers that work with registers from the USB PHY block.
> 
>   Please provide your feedback on this solution.
> 
> Thank you,
> Claudiu
> 
> [1] https://lore.kernel.org/all/20250330214945.185725-2-john.madieu.xa@bp.renesas.com/
> [2] https://lore.kernel.org/all/20250818162859.9661-2-john.madieu.xa@bp.renesas.com/
> 
> Changes in v2:
> - dropped v1 patches already applied
> - added fixes patches (07/14 and 09/14)
> - dropped the approach of handling the USB PWRRDY though a reset controller
>   driver and introduced the signal concept for the SYSC driver; because
>   of this, most of the work done in v1 was dropped
> - per patch changes are listed in individual patches, if any
> 
> Christophe JAILLET (1):
>   phy: renesas: rcar-gen3-usb2: Fix an error handling path in
>     rcar_gen3_phy_usb2_probe()
> 
> Claudiu Beznea (6):
>   dt-bindings: phy: renesas,usb2-phy: Mark resets as required for RZ/G3S
>   dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support
>   reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY
>   reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC
>   arm64: dts: renesas: r9a08g045: Add USB support
>   arm64: dts: renesas: rzg3s-smarc: Enable USB support
> 
>  .../bindings/phy/renesas,usb2-phy.yaml        |   1 +
>  .../reset/renesas,rzg2l-usbphy-ctrl.yaml      |  41 +++++-
>  arch/arm64/boot/dts/renesas/r9a08g045.dtsi    | 118 ++++++++++++++++++
>  arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi  |  57 +++++++++
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  20 ++-
>  drivers/reset/Kconfig                         |   1 +
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c       |  66 ++++++++++
>  7 files changed, 292 insertions(+), 12 deletions(-)
> 

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel]

Hi Claudiu,

On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
> PWRRDY. This signal is managed by the system controller and must be
> de-asserted after powering on the area where USB PHY resides and asserted
> before powering it off.
> 
> On power-on the USB PWRRDY signal need to be de-asserted before enabling
> clock and switching the module to normal state (through MSTOP support). The
> power-on configuration sequence

The wording makes me wonder, have you considered implementing this as a
power sequencing driver?

> must be:
> 
> 1/ PWRRDY=0
> 2/ CLK_ON=1
> 3/ MSTOP=0
> 
> On power-off the configuration sequence should be:
> 
> 1/ MSTOP=1
> 2/ CLK_ON=0
> 3/ PWRRDY=1
> 
> The CLK_ON and MSTOP functionalities are controlled by clock drivers.
>
> After long discussions with the internal HW team, it has been confirmed
> that the HW connection b/w USB PHY block, the USB channels, the system
> controller, clock, MSTOP, PWRRDY signal is as follows:
> 
>                                ┌──────────────────────────────┐
>                                │                              │◄── CPG_CLKON_USB.CLK0_ON
>                                │     USB CH0                  │
> ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
> │                 ┌────────┐   ││host controller registers  │ │
> │                 │        │   ││function controller registers│
> │                 │ PHY0   │◄──┤└───────────────────────────┘ │
> │     USB PHY     │        │   └────────────▲─────────────────┘
> │                 └────────┘                │
> │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
> │┌──────────────┐ ┌────────┐
> ││USHPHY control│ │        │
> ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
> │└──────────────┘ │        │◄──┤     USB CH1                  │
> │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
> └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>   │       │         │          │└───────────────────────────┘ │
>   │       │         │          └────────────▲─────────────────┘
>   │       │         │                       │
>   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>   │PWRRDY │         │
>   │       │   CPG_CLK_ON_USB.CLK3_ON
>   │       │
>   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>   │
> ┌────┐
> │SYSC│
> └────┘
> 
> where:
> - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>   of different USB blocks, X in {0, 1, 2, 3}
> - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>   MSTOP of different USB blocks, X in {4, 5, 6, 7}
> - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>   by the USB CH0, USB CH1
> - SYSC is the system controller block controlling the PWRRDY signal
> - USB CHx are individual USB block with host and function capabilities
>   (USB CH0 have both host and function capabilities, USB CH1 has only
>   host capabilities)
> 
> The USBPHY control registers are controlled though the
> reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
> phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
> USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
> 
> The connection b/w the system controller and the USB PHY CTRL driver is
> implemented through the renesas,sysc-pwrrdy device tree property
> proposed in this patch. This property specifies the register offset and the
> bitmask required to control the PWRRDY signal.
> 
> Since the USB PHY CTRL driver needs to be probed before any other
> USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
> to it. This guarantees the correct configuration sequence between clocks,
> MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
> by avoiding modifications to the USB PHY driver to also handle the PWRRDY
> itself.
> 
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
> 
> Changes in v7:
> - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()
> 
> Changes in v6:
> - used syscon_regmap_lookup_by_phandle_args() to simplify the code
> - collected tags
> 
> Changes in v5:
> - none
> 
> Changes in v4:
> - updated patch description
> - updated rzg2l_usbphy_ctrl_pwrrdy_init() to map directly the
>   "renesas,sysc-pwrrdy" as the SYSC signal abstraction was dropped
>   in this version, along with rz_sysc_get_signal_map()
> - dropped priv member of rzg2l_usbphy_ctrl_pwrrdy_init() as it is
>   not needed in this version
> - shift left !power_on with pwrrdy->mask as this is how the
>   regmap_update_bits() needs the last member to be
> - selected MFD_SYSCON
> 
> Changes in v3:
> - none; this patch is new
> 
> 
>  drivers/reset/Kconfig                   |  1 +
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 62 +++++++++++++++++++++++++
>  2 files changed, 63 insertions(+)
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 78b7078478d4..329730cbcfb9 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -237,6 +237,7 @@ config RESET_RASPBERRYPI
>  config RESET_RZG2L_USBPHY_CTRL
>  	tristate "Renesas RZ/G2L USBPHY control driver"
>  	depends on ARCH_RZG2L || COMPILE_TEST
> +	select MFD_SYSCON
>  	help
>  	  Support for USBPHY Control found on RZ/G2L family. It mainly
>  	  controls reset and power down of the USB/PHY.
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 8a7f167e405e..be315199e2b0 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> @@ -13,6 +13,7 @@
>  #include <linux/regmap.h>
>  #include <linux/reset.h>
>  #include <linux/reset-controller.h>
> +#include <linux/mfd/syscon.h>
>  
>  #define RESET			0x000
>  #define VBENCTL			0x03c
> @@ -41,6 +42,18 @@ struct rzg2l_usbphy_ctrl_priv {
>  
>  #define rcdev_to_priv(x)	container_of(x, struct rzg2l_usbphy_ctrl_priv, rcdev)
>  
> +/**
> + * struct rzg2l_usbphy_ctrl_pwrrdy - SYSC PWRRDY signal descriptor
> + * @regmap: SYSC regmap
> + * @offset: offset into the SYSC address space for accessing PWRRDY
> + * @mask: mask into the register at offset for accessing PWRRDY
> + */
> +struct rzg2l_usbphy_ctrl_pwrrdy {
> +	struct regmap *regmap;
> +	u32 offset;
> +	u32 mask;
> +};
> +
>  static int rzg2l_usbphy_ctrl_assert(struct reset_controller_dev *rcdev,
>  				    unsigned long id)
>  {
> @@ -91,6 +104,8 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
>  	return !!(readl(priv->base + RESET) & port_mask);
>  }
>  
> +#define RZG2L_USBPHY_CTRL_PWRRDY	1
> +
>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
>  	{ /* Sentinel */ }
> @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
>  	.max_register = 1,
>  };
>  
> +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
> +					 bool power_on)
> +{
> +	u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;


Why not just:

	u32 val = power_on ? 0 : pwrrdy->mask;

You could simplify this further by using a regmap_field instead of
rzg2l_usbphy_ctrl_pwrrdy.

> +
> +	regmap_update_bits(pwrrdy->regmap, pwrrdy->offset, pwrrdy->mask, val);
> +}
> +
> +static void rzg2l_usbphy_ctrl_pwrrdy_off(void *data)
> +{
> +	rzg2l_usbphy_ctrl_set_pwrrdy(data, false);
> +}
> +
> +static int rzg2l_usbphy_ctrl_pwrrdy_init(struct device *dev)
> +{
> +	struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy;
> +	struct regmap *regmap;
> +	const int *data;
> +	u32 args[2];
> +
> +	data = device_get_match_data(dev);
> +	if (data != (int *)RZG2L_USBPHY_CTRL_PWRRDY)

Better not to compare pointers here:

	if ((uintptr_t)data != RZG2L_USBPHY_CTRL_PWRRDY)

> +		return 0;
> +
> +	regmap = syscon_regmap_lookup_by_phandle_args(dev->of_node,
> +						      "renesas,sysc-pwrrdy",
> +						      ARRAY_SIZE(args), args);
> +	if (IS_ERR(regmap))
> +		return PTR_ERR(regmap);
> +
> +	pwrrdy = devm_kzalloc(dev, sizeof(*pwrrdy), GFP_KERNEL);
> +	if (!pwrrdy)
> +		return -ENOMEM;
> +
> +	pwrrdy->regmap = regmap;
> +	pwrrdy->offset = args[0];
> +	pwrrdy->mask = args[1];
> +
> +	rzg2l_usbphy_ctrl_set_pwrrdy(pwrrdy, true);
> +
> +	return devm_add_action_or_reset(dev, rzg2l_usbphy_ctrl_pwrrdy_off, pwrrdy);
> +}

So we deassert PWRRDY on probe and assert on remove. What about
suspend/resume ordering?

regards
Philipp

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/8/25 11:34, Philipp Zabel wrote:
> Hi Claudiu,
> 
> On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>> PWRRDY. This signal is managed by the system controller and must be
>> de-asserted after powering on the area where USB PHY resides and asserted
>> before powering it off.
>>
>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>> clock and switching the module to normal state (through MSTOP support). The
>> power-on configuration sequence
> 
> The wording makes me wonder, have you considered implementing this as a
> power sequencing driver?

No, haven't tried as power sequencing. At the moment this was started I
think the power sequencing support wasn't merged.

The approaches considered were:
a/ power domain
b/ regulator
c/ as a reference counted bit done through regmap read/writes APIs

a and b failed as a result of discussions in the previous posted versions.

c was abandoned by me after long discussions with Renesas HW team which
revealed the block schema b/w individual USB blocks (presented in the patch
description).

The point is that this bit doesn't actually power anything, at the moment
the bit is set, the power to USB is already applied. Software just need to
set the bit before/after setting the clocks and the associated MSTOP and
applying any USB specific settings. Each clock has an MSTOP associated and
the MSTOP is set though the clock driver when the clock is set.


> 
>> must be:
>>
>> 1/ PWRRDY=0
>> 2/ CLK_ON=1
>> 3/ MSTOP=0
>>
>> On power-off the configuration sequence should be:
>>
>> 1/ MSTOP=1
>> 2/ CLK_ON=0
>> 3/ PWRRDY=1
>>
>> The CLK_ON and MSTOP functionalities are controlled by clock drivers.
>>
>> After long discussions with the internal HW team, it has been confirmed
>> that the HW connection b/w USB PHY block, the USB channels, the system
>> controller, clock, MSTOP, PWRRDY signal is as follows:
>>
>>                                ┌──────────────────────────────┐
>>                                │                              │◄── CPG_CLKON_USB.CLK0_ON
>>                                │     USB CH0                  │
>> ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
>> │                 ┌────────┐   ││host controller registers  │ │
>> │                 │        │   ││function controller registers│
>> │                 │ PHY0   │◄──┤└───────────────────────────┘ │
>> │     USB PHY     │        │   └────────────▲─────────────────┘
>> │                 └────────┘                │
>> │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
>> │┌──────────────┐ ┌────────┐
>> ││USHPHY control│ │        │
>> ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
>> │└──────────────┘ │        │◄──┤     USB CH1                  │
>> │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
>> └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>>   │       │         │          │└───────────────────────────┘ │
>>   │       │         │          └────────────▲─────────────────┘
>>   │       │         │                       │
>>   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>>   │PWRRDY │         │
>>   │       │   CPG_CLK_ON_USB.CLK3_ON
>>   │       │
>>   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>>   │
>> ┌────┐
>> │SYSC│
>> └────┘
>>
>> where:
>> - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>>   of different USB blocks, X in {0, 1, 2, 3}
>> - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>>   MSTOP of different USB blocks, X in {4, 5, 6, 7}
>> - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>>   by the USB CH0, USB CH1
>> - SYSC is the system controller block controlling the PWRRDY signal
>> - USB CHx are individual USB block with host and function capabilities
>>   (USB CH0 have both host and function capabilities, USB CH1 has only
>>   host capabilities)
>>
>> The USBPHY control registers are controlled though the
>> reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
>> phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
>> USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
>>
>> The connection b/w the system controller and the USB PHY CTRL driver is
>> implemented through the renesas,sysc-pwrrdy device tree property
>> proposed in this patch. This property specifies the register offset and the
>> bitmask required to control the PWRRDY signal.
>>
>> Since the USB PHY CTRL driver needs to be probed before any other
>> USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
>> to it. This guarantees the correct configuration sequence between clocks,
>> MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
>> by avoiding modifications to the USB PHY driver to also handle the PWRRDY
>> itself.
>>
>> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>
>> Changes in v7:
>> - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()
>>
>> Changes in v6:
>> - used syscon_regmap_lookup_by_phandle_args() to simplify the code
>> - collected tags
>>
>> Changes in v5:
>> - none
>>
>> Changes in v4:
>> - updated patch description
>> - updated rzg2l_usbphy_ctrl_pwrrdy_init() to map directly the
>>   "renesas,sysc-pwrrdy" as the SYSC signal abstraction was dropped
>>   in this version, along with rz_sysc_get_signal_map()
>> - dropped priv member of rzg2l_usbphy_ctrl_pwrrdy_init() as it is
>>   not needed in this version
>> - shift left !power_on with pwrrdy->mask as this is how the
>>   regmap_update_bits() needs the last member to be
>> - selected MFD_SYSCON
>>
>> Changes in v3:
>> - none; this patch is new
>>
>>
>>  drivers/reset/Kconfig                   |  1 +
>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 62 +++++++++++++++++++++++++
>>  2 files changed, 63 insertions(+)
>>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 78b7078478d4..329730cbcfb9 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -237,6 +237,7 @@ config RESET_RASPBERRYPI
>>  config RESET_RZG2L_USBPHY_CTRL
>>  	tristate "Renesas RZ/G2L USBPHY control driver"
>>  	depends on ARCH_RZG2L || COMPILE_TEST
>> +	select MFD_SYSCON
>>  	help
>>  	  Support for USBPHY Control found on RZ/G2L family. It mainly
>>  	  controls reset and power down of the USB/PHY.
>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> index 8a7f167e405e..be315199e2b0 100644
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/regmap.h>
>>  #include <linux/reset.h>
>>  #include <linux/reset-controller.h>
>> +#include <linux/mfd/syscon.h>
>>  
>>  #define RESET			0x000
>>  #define VBENCTL			0x03c
>> @@ -41,6 +42,18 @@ struct rzg2l_usbphy_ctrl_priv {
>>  
>>  #define rcdev_to_priv(x)	container_of(x, struct rzg2l_usbphy_ctrl_priv, rcdev)
>>  
>> +/**
>> + * struct rzg2l_usbphy_ctrl_pwrrdy - SYSC PWRRDY signal descriptor
>> + * @regmap: SYSC regmap
>> + * @offset: offset into the SYSC address space for accessing PWRRDY
>> + * @mask: mask into the register at offset for accessing PWRRDY
>> + */
>> +struct rzg2l_usbphy_ctrl_pwrrdy {
>> +	struct regmap *regmap;
>> +	u32 offset;
>> +	u32 mask;
>> +};
>> +
>>  static int rzg2l_usbphy_ctrl_assert(struct reset_controller_dev *rcdev,
>>  				    unsigned long id)
>>  {
>> @@ -91,6 +104,8 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
>>  	return !!(readl(priv->base + RESET) & port_mask);
>>  }
>>  
>> +#define RZG2L_USBPHY_CTRL_PWRRDY	1
>> +
>>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
>>  	{ /* Sentinel */ }
>> @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
>>  	.max_register = 1,
>>  };
>>  
>> +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
>> +					 bool power_on)
>> +{
>> +	u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;
> 
> 
> Why not just:
> 
> 	u32 val = power_on ? 0 : pwrrdy->mask;

This would work as well. I wanted to be sure it doesn't fail in case the
mask is more than one bit (as it comes from device tree).

> 
> You could simplify this further by using a regmap_field instead of
> rzg2l_usbphy_ctrl_pwrrdy.

I'll look to it. I wasn't aware of regmap_field :)

> 
>> +
>> +	regmap_update_bits(pwrrdy->regmap, pwrrdy->offset, pwrrdy->mask, val);
>> +}
>> +
>> +static void rzg2l_usbphy_ctrl_pwrrdy_off(void *data)
>> +{
>> +	rzg2l_usbphy_ctrl_set_pwrrdy(data, false);
>> +}
>> +
>> +static int rzg2l_usbphy_ctrl_pwrrdy_init(struct device *dev)
>> +{
>> +	struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy;
>> +	struct regmap *regmap;
>> +	const int *data;
>> +	u32 args[2];
>> +
>> +	data = device_get_match_data(dev);
>> +	if (data != (int *)RZG2L_USBPHY_CTRL_PWRRDY)
> 
> Better not to compare pointers here:
> 
> 	if ((uintptr_t)data != RZG2L_USBPHY_CTRL_PWRRDY)

OK

> 
>> +		return 0;
>> +
>> +	regmap = syscon_regmap_lookup_by_phandle_args(dev->of_node,
>> +						      "renesas,sysc-pwrrdy",
>> +						      ARRAY_SIZE(args), args);
>> +	if (IS_ERR(regmap))
>> +		return PTR_ERR(regmap);
>> +
>> +	pwrrdy = devm_kzalloc(dev, sizeof(*pwrrdy), GFP_KERNEL);
>> +	if (!pwrrdy)
>> +		return -ENOMEM;
>> +
>> +	pwrrdy->regmap = regmap;
>> +	pwrrdy->offset = args[0];
>> +	pwrrdy->mask = args[1];
>> +
>> +	rzg2l_usbphy_ctrl_set_pwrrdy(pwrrdy, true);
>> +
>> +	return devm_add_action_or_reset(dev, rzg2l_usbphy_ctrl_pwrrdy_off, pwrrdy);
>> +}
> 
> So we deassert PWRRDY on probe and assert on remove. What about
> suspend/resume ordering?

As this driver has no suspend/resume support yet, my intention was to take
care of this bit on suspend/resume after it will be established how it is
handled on probe/remove. Adding suspend/resume support to this series will
make it bigger.

Thank you for your review,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel]

Hi Claudiu,

On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/8/25 11:34, Philipp Zabel wrote:
> > Hi Claudiu,
> > 
> > On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
> > > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > 
> > > On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
> > > PWRRDY. This signal is managed by the system controller and must be
> > > de-asserted after powering on the area where USB PHY resides and asserted
> > > before powering it off.
> > > 
> > > On power-on the USB PWRRDY signal need to be de-asserted before enabling
> > > clock and switching the module to normal state (through MSTOP support). The
> > > power-on configuration sequence
> > 
> > The wording makes me wonder, have you considered implementing this as a
> > power sequencing driver?
> 
> No, haven't tried as power sequencing. At the moment this was started I
> think the power sequencing support wasn't merged.
> 
> The approaches considered were:
> a/ power domain

Letting a power domain control a corresponding power ready signal would
have been my first instinct as well.

> b/ regulator
> c/ as a reference counted bit done through regmap read/writes APIs
> 
> a and b failed as a result of discussions in the previous posted versions.

Could you point me to the discussion related to a?

I see v2 and v3 tried to control the bit from the PHY drivers, and in
v4 we were are already back to the reset driver.

> c was abandoned by me after long discussions with Renesas HW team which
> revealed the block schema b/w individual USB blocks (presented in the patch
> description).
> 
> The point is that this bit doesn't actually power anything, at the moment
> the bit is set, the power to USB is already applied. Software just need to
> set the bit before/after setting the clocks and the associated MSTOP and
> applying any USB specific settings. Each clock has an MSTOP associated and
> the MSTOP is set though the clock driver when the clock is set.

I understand.

Apart from having to carry non-reset-related code in reset drivers, I
worry about the implicit ordering that the PHY driver depends on with
this:

The power-up (probe) order is guaranteed by probe order via the
reset_control_get() check in the PHY driver, and power-down (remove)
order is guaranteed by the reset controller device reference that the
reset control holds. That's all very hidden and indirect when the
actual dependency is between a bit being set in SYSC and the clock
handling in (either) PHY driver.

> > 
> > > must be:
> > > 
> > > 1/ PWRRDY=0
> > > 2/ CLK_ON=1
> > > 3/ MSTOP=0
> > > 
> > > On power-off the configuration sequence should be:
> > > 
> > > 1/ MSTOP=1
> > > 2/ CLK_ON=0
> > > 3/ PWRRDY=1
> > > 
> > > The CLK_ON and MSTOP functionalities are controlled by clock drivers.
> > > 
> > > After long discussions with the internal HW team, it has been confirmed
> > > that the HW connection b/w USB PHY block, the USB channels, the system
> > > controller, clock, MSTOP, PWRRDY signal is as follows:
> > > 
> > >                                ┌──────────────────────────────┐
> > >                                │                              │◄── CPG_CLKON_USB.CLK0_ON
> > >                                │     USB CH0                  │
> > > ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
> > > │                 ┌────────┐   ││host controller registers  │ │
> > > │                 │        │   ││function controller registers│
> > > │                 │ PHY0   │◄──┤└───────────────────────────┘ │
> > > │     USB PHY     │        │   └────────────▲─────────────────┘
> > > │                 └────────┘                │
> > > │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
> > > │┌──────────────┐ ┌────────┐
> > > ││USHPHY control│ │        │
> > > ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
> > > │└──────────────┘ │        │◄──┤     USB CH1                  │
> > > │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
> > > └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
> > >   │       │         │          │└───────────────────────────┘ │
> > >   │       │         │          └────────────▲─────────────────┘
> > >   │       │         │                       │
> > >   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
> > >   │PWRRDY │         │
> > >   │       │   CPG_CLK_ON_USB.CLK3_ON
> > >   │       │
> > >   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
> > >   │
> > > ┌────┐
> > > │SYSC│
> > > └────┘
> > > 
> > > where:
> > > - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
> > >   of different USB blocks, X in {0, 1, 2, 3}
> > > - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
> > >   MSTOP of different USB blocks, X in {4, 5, 6, 7}
> > > - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
> > >   by the USB CH0, USB CH1
> > > - SYSC is the system controller block controlling the PWRRDY signal
> > > - USB CHx are individual USB block with host and function capabilities
> > >   (USB CH0 have both host and function capabilities, USB CH1 has only
> > >   host capabilities)
> > > 
> > > The USBPHY control registers are controlled though the
> > > reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
> > > phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
> > > USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
> > > 
> > > The connection b/w the system controller and the USB PHY CTRL driver is
> > > implemented through the renesas,sysc-pwrrdy device tree property
> > > proposed in this patch. This property specifies the register offset and the
> > > bitmask required to control the PWRRDY signal.
> > > 
> > > Since the USB PHY CTRL driver needs to be probed before any other
> > > USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
> > > to it. This guarantees the correct configuration sequence between clocks,
> > > MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
> > > by avoiding modifications to the USB PHY driver to also handle the PWRRDY
> > > itself.
> > > 
> > > Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > ---
> > > 
> > > Changes in v7:
> > > - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()
> > > 
> > > Changes in v6:
> > > - used syscon_regmap_lookup_by_phandle_args() to simplify the code
> > > - collected tags
> > > 
> > > Changes in v5:
> > > - none
> > > 
> > > Changes in v4:
> > > - updated patch description
> > > - updated rzg2l_usbphy_ctrl_pwrrdy_init() to map directly the
> > >   "renesas,sysc-pwrrdy" as the SYSC signal abstraction was dropped
> > >   in this version, along with rz_sysc_get_signal_map()
> > > - dropped priv member of rzg2l_usbphy_ctrl_pwrrdy_init() as it is
> > >   not needed in this version
> > > - shift left !power_on with pwrrdy->mask as this is how the
> > >   regmap_update_bits() needs the last member to be
> > > - selected MFD_SYSCON
> > > 
> > > Changes in v3:
> > > - none; this patch is new
> > > 
> > > 
> > >  drivers/reset/Kconfig                   |  1 +
> > >  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 62 +++++++++++++++++++++++++
> > >  2 files changed, 63 insertions(+)
> > > 
> > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> > > index 78b7078478d4..329730cbcfb9 100644
> > > --- a/drivers/reset/Kconfig
> > > +++ b/drivers/reset/Kconfig
> > > @@ -237,6 +237,7 @@ config RESET_RASPBERRYPI
> > >  config RESET_RZG2L_USBPHY_CTRL
> > >  	tristate "Renesas RZ/G2L USBPHY control driver"
> > >  	depends on ARCH_RZG2L || COMPILE_TEST
> > > +	select MFD_SYSCON
> > >  	help
> > >  	  Support for USBPHY Control found on RZ/G2L family. It mainly
> > >  	  controls reset and power down of the USB/PHY.
> > > diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > > index 8a7f167e405e..be315199e2b0 100644
> > > --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > > +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > > @@ -13,6 +13,7 @@
> > >  #include <linux/regmap.h>
> > >  #include <linux/reset.h>
> > >  #include <linux/reset-controller.h>
> > > +#include <linux/mfd/syscon.h>
> > >  
> > >  #define RESET			0x000
> > >  #define VBENCTL			0x03c
> > > @@ -41,6 +42,18 @@ struct rzg2l_usbphy_ctrl_priv {
> > >  
> > >  #define rcdev_to_priv(x)	container_of(x, struct rzg2l_usbphy_ctrl_priv, rcdev)
> > >  
> > > +/**
> > > + * struct rzg2l_usbphy_ctrl_pwrrdy - SYSC PWRRDY signal descriptor
> > > + * @regmap: SYSC regmap
> > > + * @offset: offset into the SYSC address space for accessing PWRRDY
> > > + * @mask: mask into the register at offset for accessing PWRRDY
> > > + */
> > > +struct rzg2l_usbphy_ctrl_pwrrdy {
> > > +	struct regmap *regmap;
> > > +	u32 offset;
> > > +	u32 mask;
> > > +};
> > > +
> > >  static int rzg2l_usbphy_ctrl_assert(struct reset_controller_dev *rcdev,
> > >  				    unsigned long id)
> > >  {
> > > @@ -91,6 +104,8 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
> > >  	return !!(readl(priv->base + RESET) & port_mask);
> > >  }
> > >  
> > > +#define RZG2L_USBPHY_CTRL_PWRRDY	1
> > > +
> > >  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
> > >  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
> > >  	{ /* Sentinel */ }
> > > @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
> > >  	.max_register = 1,
> > >  };
> > >  
> > > +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
> > > +					 bool power_on)
> > > +{
> > > +	u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;
> > 
> > 
> > Why not just:
> > 
> > 	u32 val = power_on ? 0 : pwrrdy->mask;
> 
> This would work as well. I wanted to be sure it doesn't fail in case the
> mask is more than one bit (as it comes from device tree).

I'd just check this in rzg2l_usbphy_ctrl_pwrrdy_init() and fail if more
than one bit is set.

[...]
> 
> > So we deassert PWRRDY on probe and assert on remove. What about
> > suspend/resume ordering?
> 
> As this driver has no suspend/resume support yet, my intention was to take
> care of this bit on suspend/resume after it will be established how it is
> handled on probe/remove. Adding suspend/resume support to this series will
> make it bigger.

Ok, please add that to the commit description.
I'm just asking because the dt-bindings patch mentions how PWRRDY must
be set during suspend/resume, and then this patch doesn't do it.

regards
Philipp

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/8/25 13:23, Philipp Zabel wrote:
> Hi Claudiu,
> 
> On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
>> Hi, Philipp,
>>
>> On 10/8/25 11:34, Philipp Zabel wrote:
>>> Hi Claudiu,
>>>
>>> On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>>>> PWRRDY. This signal is managed by the system controller and must be
>>>> de-asserted after powering on the area where USB PHY resides and asserted
>>>> before powering it off.
>>>>
>>>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>>>> clock and switching the module to normal state (through MSTOP support). The
>>>> power-on configuration sequence
>>>
>>> The wording makes me wonder, have you considered implementing this as a
>>> power sequencing driver?
>>
>> No, haven't tried as power sequencing. At the moment this was started I
>> think the power sequencing support wasn't merged.
>>
>> The approaches considered were:
>> a/ power domain
> 
> Letting a power domain control a corresponding power ready signal would
> have been my first instinct as well.
> 
>> b/ regulator
>> c/ as a reference counted bit done through regmap read/writes APIs
>>
>> a and b failed as a result of discussions in the previous posted versions.
> 
> Could you point me to the discussion related to a?

It's this one
https://lore.kernel.org/all/CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/


> 
> I see v2 and v3 tried to control the bit from the PHY drivers, and in
> v4 we were are already back to the reset driver.

v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
bit was referenced counted in the SYSC driver though regmap APIs.

v3 used the approach from v2 but passed the renesas,sysc-signals to all the
USB related drivers.

Then, in v4, the PWRRDY refcounting was dropped and passed
renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
is the node that will always be probed first as all the other USB blocks
need it and request resets from it.

v5 and v6 kept the approach from v4 and only addressed misc comments or
things that I noticed.

> 
>> c was abandoned by me after long discussions with Renesas HW team which
>> revealed the block schema b/w individual USB blocks (presented in the patch
>> description).
>>
>> The point is that this bit doesn't actually power anything, at the moment
>> the bit is set, the power to USB is already applied. Software just need to
>> set the bit before/after setting the clocks and the associated MSTOP and
>> applying any USB specific settings. Each clock has an MSTOP associated and
>> the MSTOP is set though the clock driver when the clock is set.
> 
> I understand.
> 
> Apart from having to carry non-reset-related code in reset drivers, I
> worry about the implicit ordering that the PHY driver depends on with
> this:
> 
> The power-up (probe) order is guaranteed by probe order via the
> reset_control_get() check in the PHY driver, and power-down (remove)
> order is guaranteed by the reset controller device reference that the
> reset control holds. That's all very hidden and indirect when the
> actual dependency is between a bit being set in SYSC and the clock
> handling in (either) PHY driver.


The USB PHY CTRL block controlled by this driver is also part of the USB
PHY block:

┌──────────────────────────┐
│                 ┌────────┐
│                 │        │
│                 │ PHY0   │
│     USB PHY     │        │
│                 └────────┘
│                          │
│┌──────────────┐ ┌────────┐
││USHPHY control│ │        │
││  registers   │ │ PHY1   │
│└──────────────┘ │        │
│                 └────────┘
└─▲───────▲─────────▲──────┘
  │       │         │
  │       │         │
  │       │         │
  │PWRRDY │         │
  │       │   CPG_CLK_ON_USB.CLK3_ON
  │       │
  │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
  │
┌────┐
│SYSC│
└────┘

Thus, touching USB PHY CTRL registers, though this driver, will also have
to be done after setting PWRRDY, clk, MSTOP.

In v3 the PWRRDY SYSC phandle was passed to all the drivers in charge of
controlling the blocks from the USB PHY area. And the PWRRDY was referenced
counted through regmap APIs. In v3 I was in the middle of keeping vs
dropping the refcounting and, thus, posted it and asked for feedback on
this approach. I didn't get any input about it, I've dropped in v4.

In v4, I dropped it as I considered it too much and unnecessary taking into
account that the USB PHY CTRL driver will be probed/remove all the time
first/last as all the other drivers depends on it. And, due to this, it
will be last/first in suspend/resume sequence.


> 
>>>
>>>> must be:
>>>>
>>>> 1/ PWRRDY=0
>>>> 2/ CLK_ON=1
>>>> 3/ MSTOP=0
>>>>
>>>> On power-off the configuration sequence should be:
>>>>
>>>> 1/ MSTOP=1
>>>> 2/ CLK_ON=0
>>>> 3/ PWRRDY=1
>>>>
>>>> The CLK_ON and MSTOP functionalities are controlled by clock drivers.
>>>>
>>>> After long discussions with the internal HW team, it has been confirmed
>>>> that the HW connection b/w USB PHY block, the USB channels, the system
>>>> controller, clock, MSTOP, PWRRDY signal is as follows:
>>>>
>>>>                                ┌──────────────────────────────┐
>>>>                                │                              │◄── CPG_CLKON_USB.CLK0_ON
>>>>                                │     USB CH0                  │
>>>> ┌──────────────────────────┐   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON
>>>> │                 ┌────────┐   ││host controller registers  │ │
>>>> │                 │        │   ││function controller registers│
>>>> │                 │ PHY0   │◄──┤└───────────────────────────┘ │
>>>> │     USB PHY     │        │   └────────────▲─────────────────┘
>>>> │                 └────────┘                │
>>>> │                          │    CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON
>>>> │┌──────────────┐ ┌────────┐
>>>> ││USHPHY control│ │        │
>>>> ││  registers   │ │ PHY1   │   ┌──────────────────────────────┐
>>>> │└──────────────┘ │        │◄──┤     USB CH1                  │
>>>> │                 └────────┘   │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON
>>>> └─▲───────▲─────────▲──────┘   ││ host controller registers │ │
>>>>   │       │         │          │└───────────────────────────┘ │
>>>>   │       │         │          └────────────▲─────────────────┘
>>>>   │       │         │                       │
>>>>   │       │         │           CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON
>>>>   │PWRRDY │         │
>>>>   │       │   CPG_CLK_ON_USB.CLK3_ON
>>>>   │       │
>>>>   │  CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON
>>>>   │
>>>> ┌────┐
>>>> │SYSC│
>>>> └────┘
>>>>
>>>> where:
>>>> - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X
>>>>   of different USB blocks, X in {0, 1, 2, 3}
>>>> - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the
>>>>   MSTOP of different USB blocks, X in {4, 5, 6, 7}
>>>> - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used
>>>>   by the USB CH0, USB CH1
>>>> - SYSC is the system controller block controlling the PWRRDY signal
>>>> - USB CHx are individual USB block with host and function capabilities
>>>>   (USB CH0 have both host and function capabilities, USB CH1 has only
>>>>   host capabilities)
>>>>
>>>> The USBPHY control registers are controlled though the
>>>> reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by
>>>> phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The
>>>> USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver.
>>>>
>>>> The connection b/w the system controller and the USB PHY CTRL driver is
>>>> implemented through the renesas,sysc-pwrrdy device tree property
>>>> proposed in this patch. This property specifies the register offset and the
>>>> bitmask required to control the PWRRDY signal.
>>>>
>>>> Since the USB PHY CTRL driver needs to be probed before any other
>>>> USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively
>>>> to it. This guarantees the correct configuration sequence between clocks,
>>>> MSTOP bits, and the PWRRDY bit. At the same time, changes are kept minimal
>>>> by avoiding modifications to the USB PHY driver to also handle the PWRRDY
>>>> itself.
>>>>
>>>> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>> ---
>>>>
>>>> Changes in v7:
>>>> - used proper regmap update value on rzg2l_usbphy_ctrl_set_pwrrdy()
>>>>
>>>> Changes in v6:
>>>> - used syscon_regmap_lookup_by_phandle_args() to simplify the code
>>>> - collected tags
>>>>
>>>> Changes in v5:
>>>> - none
>>>>
>>>> Changes in v4:
>>>> - updated patch description
>>>> - updated rzg2l_usbphy_ctrl_pwrrdy_init() to map directly the
>>>>   "renesas,sysc-pwrrdy" as the SYSC signal abstraction was dropped
>>>>   in this version, along with rz_sysc_get_signal_map()
>>>> - dropped priv member of rzg2l_usbphy_ctrl_pwrrdy_init() as it is
>>>>   not needed in this version
>>>> - shift left !power_on with pwrrdy->mask as this is how the
>>>>   regmap_update_bits() needs the last member to be
>>>> - selected MFD_SYSCON
>>>>
>>>> Changes in v3:
>>>> - none; this patch is new
>>>>
>>>>
>>>>  drivers/reset/Kconfig                   |  1 +
>>>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 62 +++++++++++++++++++++++++
>>>>  2 files changed, 63 insertions(+)
>>>>
>>>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>>>> index 78b7078478d4..329730cbcfb9 100644
>>>> --- a/drivers/reset/Kconfig
>>>> +++ b/drivers/reset/Kconfig
>>>> @@ -237,6 +237,7 @@ config RESET_RASPBERRYPI
>>>>  config RESET_RZG2L_USBPHY_CTRL
>>>>  	tristate "Renesas RZ/G2L USBPHY control driver"
>>>>  	depends on ARCH_RZG2L || COMPILE_TEST
>>>> +	select MFD_SYSCON
>>>>  	help
>>>>  	  Support for USBPHY Control found on RZ/G2L family. It mainly
>>>>  	  controls reset and power down of the USB/PHY.
>>>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>>>> index 8a7f167e405e..be315199e2b0 100644
>>>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>>>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>>>> @@ -13,6 +13,7 @@
>>>>  #include <linux/regmap.h>
>>>>  #include <linux/reset.h>
>>>>  #include <linux/reset-controller.h>
>>>> +#include <linux/mfd/syscon.h>
>>>>  
>>>>  #define RESET			0x000
>>>>  #define VBENCTL			0x03c
>>>> @@ -41,6 +42,18 @@ struct rzg2l_usbphy_ctrl_priv {
>>>>  
>>>>  #define rcdev_to_priv(x)	container_of(x, struct rzg2l_usbphy_ctrl_priv, rcdev)
>>>>  
>>>> +/**
>>>> + * struct rzg2l_usbphy_ctrl_pwrrdy - SYSC PWRRDY signal descriptor
>>>> + * @regmap: SYSC regmap
>>>> + * @offset: offset into the SYSC address space for accessing PWRRDY
>>>> + * @mask: mask into the register at offset for accessing PWRRDY
>>>> + */
>>>> +struct rzg2l_usbphy_ctrl_pwrrdy {
>>>> +	struct regmap *regmap;
>>>> +	u32 offset;
>>>> +	u32 mask;
>>>> +};
>>>> +
>>>>  static int rzg2l_usbphy_ctrl_assert(struct reset_controller_dev *rcdev,
>>>>  				    unsigned long id)
>>>>  {
>>>> @@ -91,6 +104,8 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
>>>>  	return !!(readl(priv->base + RESET) & port_mask);
>>>>  }
>>>>  
>>>> +#define RZG2L_USBPHY_CTRL_PWRRDY	1
>>>> +
>>>>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>>>>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
>>>>  	{ /* Sentinel */ }
>>>> @@ -110,6 +125,49 @@ static const struct regmap_config rzg2l_usb_regconf = {
>>>>  	.max_register = 1,
>>>>  };
>>>>  
>>>> +static void rzg2l_usbphy_ctrl_set_pwrrdy(struct rzg2l_usbphy_ctrl_pwrrdy *pwrrdy,
>>>> +					 bool power_on)
>>>> +{
>>>> +	u32 val = (!power_on << (ffs(pwrrdy->mask) - 1)) & pwrrdy->mask;
>>>
>>>
>>> Why not just:
>>>
>>> 	u32 val = power_on ? 0 : pwrrdy->mask;
>>
>> This would work as well. I wanted to be sure it doesn't fail in case the
>> mask is more than one bit (as it comes from device tree).
> 
> I'd just check this in rzg2l_usbphy_ctrl_pwrrdy_init() and fail if more
> than one bit is set.

OK

> 
> [...]
>>
>>> So we deassert PWRRDY on probe and assert on remove. What about
>>> suspend/resume ordering?
>>
>> As this driver has no suspend/resume support yet, my intention was to take
>> care of this bit on suspend/resume after it will be established how it is
>> handled on probe/remove. Adding suspend/resume support to this series will
>> make it bigger.
> 
> Ok, please add that to the commit description.

OK

> I'm just asking because the dt-bindings patch mentions how PWRRDY must
> be set during suspend/resume, and then this patch doesn't do it.

OK

Thank you for your review,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

On 10/8/25 15:16, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/8/25 13:23, Philipp Zabel wrote:
>> Hi Claudiu,
>>
>> On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
>>> Hi, Philipp,
>>>
>>> On 10/8/25 11:34, Philipp Zabel wrote:
>>>> Hi Claudiu,
>>>>
>>>> On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>
>>>>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>>>>> PWRRDY. This signal is managed by the system controller and must be
>>>>> de-asserted after powering on the area where USB PHY resides and asserted
>>>>> before powering it off.
>>>>>
>>>>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>>>>> clock and switching the module to normal state (through MSTOP support). The
>>>>> power-on configuration sequence
>>>>
>>>> The wording makes me wonder, have you considered implementing this as a
>>>> power sequencing driver?
>>>
>>> No, haven't tried as power sequencing. At the moment this was started I
>>> think the power sequencing support wasn't merged.
>>>
>>> The approaches considered were:
>>> a/ power domain
>>
>> Letting a power domain control a corresponding power ready signal would
>> have been my first instinct as well.
>>
>>> b/ regulator
>>> c/ as a reference counted bit done through regmap read/writes APIs
>>>
>>> a and b failed as a result of discussions in the previous posted versions.
>>
>> Could you point me to the discussion related to a?
> 
> It's this one
> https://lore.kernel.org/all/CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/
> 
> 
>>
>> I see v2 and v3 tried to control the bit from the PHY drivers, and in
>> v4 we were are already back to the reset driver.
> 
> v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> bit was referenced counted in the SYSC driver though regmap APIs.

Sorry, I forgot to mention: in v2, the SYSC phandle was passed to the PHYs
only as I wasn't aware of the block diagram presented in this patch
description. I got aware of the block diagram starting with v3.

Thank you,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/8/25 15:16, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/8/25 13:23, Philipp Zabel wrote:
>> Hi Claudiu,
>>
>> On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
>>> Hi, Philipp,
>>>
>>> On 10/8/25 11:34, Philipp Zabel wrote:
>>>> Hi Claudiu,
>>>>
>>>> On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>
>>>>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>>>>> PWRRDY. This signal is managed by the system controller and must be
>>>>> de-asserted after powering on the area where USB PHY resides and asserted
>>>>> before powering it off.
>>>>>
>>>>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>>>>> clock and switching the module to normal state (through MSTOP support). The
>>>>> power-on configuration sequence
>>>> The wording makes me wonder, have you considered implementing this as a
>>>> power sequencing driver?
>>> No, haven't tried as power sequencing. At the moment this was started I
>>> think the power sequencing support wasn't merged.
>>>
>>> The approaches considered were:
>>> a/ power domain
>> Letting a power domain control a corresponding power ready signal would
>> have been my first instinct as well.
>>
>>> b/ regulator
>>> c/ as a reference counted bit done through regmap read/writes APIs
>>>
>>> a and b failed as a result of discussions in the previous posted versions.
>> Could you point me to the discussion related to a?
> It's this one
> https://lore.kernel.org/all/
> CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/
> 
> 
>> I see v2 and v3 tried to control the bit from the PHY drivers, and in
>> v4 we were are already back to the reset driver.
> v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> bit was referenced counted in the SYSC driver though regmap APIs.
> 
> v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> USB related drivers.
> 
> Then, in v4, the PWRRDY refcounting was dropped and passed
> renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> is the node that will always be probed first as all the other USB blocks
> need it and request resets from it.
> 
> v5 and v6 kept the approach from v4 and only addressed misc comments or
> things that I noticed.

Could you please let me know if you are OK with the approach proposed in
v7, so that I can start preparing a new version addressing your comments?

Thank you,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel]

Hi Claudiu,

On Fr, 2025-10-10 at 14:26 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/8/25 15:16, Claudiu Beznea wrote:
> > Hi, Philipp,
> > 
> > On 10/8/25 13:23, Philipp Zabel wrote:
> > > Hi Claudiu,
> > > 
> > > On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
> > > > Hi, Philipp,
> > > > 
> > > > On 10/8/25 11:34, Philipp Zabel wrote:
> > > > > Hi Claudiu,
> > > > > 
> > > > > On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
> > > > > > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > > > 
> > > > > > On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
> > > > > > PWRRDY. This signal is managed by the system controller and must be
> > > > > > de-asserted after powering on the area where USB PHY resides and asserted
> > > > > > before powering it off.
> > > > > > 
> > > > > > On power-on the USB PWRRDY signal need to be de-asserted before enabling
> > > > > > clock and switching the module to normal state (through MSTOP support). The
> > > > > > power-on configuration sequence
> > > > > The wording makes me wonder, have you considered implementing this as a
> > > > > power sequencing driver?
> > > > No, haven't tried as power sequencing. At the moment this was started I
> > > > think the power sequencing support wasn't merged.
> > > > 
> > > > The approaches considered were:
> > > > a/ power domain
> > > Letting a power domain control a corresponding power ready signal would
> > > have been my first instinct as well.
> > > 
> > > > b/ regulator
> > > > c/ as a reference counted bit done through regmap read/writes APIs
> > > > 
> > > > a and b failed as a result of discussions in the previous posted versions.
> > > Could you point me to the discussion related to a?
> > It's this one
> > https://lore.kernel.org/all/
> > CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/

Thank you! From this discussion it still isn't clear to me whether
Ulf's suggestion of using genpd on/off notifiers was considered and why
it was dismissed.

From the DT patches it looks like there is no actual separate power
domain for USB, just the single always-on CPG power domain (in rzg2l-
cpg.c). Is that correct? In the thread it sounded like there were
multiple domains.

Is the issue that you need the PWRRDY signal to be (de)asserted
independently from the CPG power domain enable/disable? (Why?)

Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy
property and set the signal together with the power domain?

> > > I see v2 and v3 tried to control the bit from the PHY drivers, and in
> > > v4 we were are already back to the reset driver.
> > v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> > renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> > bit was referenced counted in the SYSC driver though regmap APIs.
> > 
> > v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> > USB related drivers.
> > 
> > Then, in v4, the PWRRDY refcounting was dropped and passed
> > renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> > is the node that will always be probed first as all the other USB blocks
> > need it and request resets from it.
> > 
> > v5 and v6 kept the approach from v4 and only addressed misc comments or
> > things that I noticed.
> 
> Could you please let me know if you are OK with the approach proposed in
> v7, so that I can start preparing a new version addressing your comments?

If the PWRRDY signal is an input to the USB2PHY control block, and not
only to the PHY blocks, I have no issue with this being handled in the
usb2phy reset driver - iff it is not sensible to just control the
signal from the power domain driver.

If we have to handle it in the reset driver, I'd prefer to see this
controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
I'd like to understand why.

regards
Philipp

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/13/25 17:57, Philipp Zabel wrote:
> Hi Claudiu,
> 
> On Fr, 2025-10-10 at 14:26 +0300, Claudiu Beznea wrote:
>> Hi, Philipp,
>>
>> On 10/8/25 15:16, Claudiu Beznea wrote:
>>> Hi, Philipp,
>>>
>>> On 10/8/25 13:23, Philipp Zabel wrote:
>>>> Hi Claudiu,
>>>>
>>>> On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
>>>>> Hi, Philipp,
>>>>>
>>>>> On 10/8/25 11:34, Philipp Zabel wrote:
>>>>>> Hi Claudiu,
>>>>>>
>>>>>> On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
>>>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>>>
>>>>>>> On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
>>>>>>> PWRRDY. This signal is managed by the system controller and must be
>>>>>>> de-asserted after powering on the area where USB PHY resides and asserted
>>>>>>> before powering it off.
>>>>>>>
>>>>>>> On power-on the USB PWRRDY signal need to be de-asserted before enabling
>>>>>>> clock and switching the module to normal state (through MSTOP support). The
>>>>>>> power-on configuration sequence
>>>>>> The wording makes me wonder, have you considered implementing this as a
>>>>>> power sequencing driver?
>>>>> No, haven't tried as power sequencing. At the moment this was started I
>>>>> think the power sequencing support wasn't merged.
>>>>>
>>>>> The approaches considered were:
>>>>> a/ power domain
>>>> Letting a power domain control a corresponding power ready signal would
>>>> have been my first instinct as well.
>>>>
>>>>> b/ regulator
>>>>> c/ as a reference counted bit done through regmap read/writes APIs
>>>>>
>>>>> a and b failed as a result of discussions in the previous posted versions.
>>>> Could you point me to the discussion related to a?
>>> It's this one
>>> https://lore.kernel.org/all/
>>> CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/
> 
> Thank you! From this discussion it still isn't clear to me whether
> Ulf's suggestion of using genpd on/off notifiers was considered and why

The genpd on/off notifier suggestion wasn't tried, but only the
implementation of PWRRDY handling through the power domain (what Ulf
suggested though "Move the entire reset handling into the PM domain
provider, as it obviously knows when the domain is getting turned on/off"
in
https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/).
Sorry if I mislead you.

Ulf suggested then here
https://lore.kernel.org/all/CAPDyKFpLnREr4C=wZ7o8Lb-CZbQa4Nr2VTuYdZHZ26Rcb1Masg@mail.gmail.com/
that he is not agreeing anymore with having it as power domain due to the
discussion in thread
https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/
(I can't remember what made him taking back is ack on this solution and I
can't find something in the thread either).

If I'm not wrong, with the information that we have at the moment, the best
for the notifier would have to register it (before runtime resume) and
implement it in this driver (reset-rzg2l-usbphy-ctrl) so that, when the
pm_runtime_resume_and_get()/pm_runtime_put() in
rzg2l_usbphy_ctrl_probe()/rzg2l_usbphy_ctrl_remove() will be called (or
suspend/resume) the notifier will be called and set the PWRRDY bit. Please
let me know if you see it otherwise.

> it was dismissed.

The power domain approach was dismissed as a result of discussion from this
thread:
https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/

I don't remember exactly what triggered it and can't find it as well, sorry.

> 
> From the DT patches it looks like there is no actual separate power
> domain for USB, just the single always-on CPG power domain (in rzg2l-
> cpg.c). Is that correct?

That is correct, the CPG is a clock power domain. All the clocks that CPG
can be provided (including USB clocks) are part of CPG clock power domain.

> In the thread it sounded like there were
> multiple domains.

You probably refer to this:
https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/

In there, I was trying to present to Ulf how I did implement (locally,
nothing posted) the handling of PWRRDY though power domains. In that case
the SYSC (System Controller), where the PWRRDY resides, was modeled as a
power domain, I passed to the reset-rzg2l-usbphy-ctrl DT node the phandle
to sysc USB power domain as:

power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc R9A08G045_SYSC_PD_USB>;

along with the cpg, and handled it in the reset-rzg2l-usbphy-ctrl probe().

> 
> Is the issue that you need the PWRRDY signal to be (de)asserted
> independently from the CPG power domain enable/disable?

Yes. I need to de-assert it before clocks, MSTOP on probe/resume and assert
it back after clocks, MSTOP, on remove/suspend.

> (Why?)

Due to hardware constraints. This is how Renesas HW team recommended.

> 
> Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy
> property and set the signal together with the power domain?

That can be done but, passing a SYSC phandle to the CPG DT node will not be
valid from the HW description point of view.

> 
>>>> I see v2 and v3 tried to control the bit from the PHY drivers, and in
>>>> v4 we were are already back to the reset driver.
>>> v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
>>> renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
>>> bit was referenced counted in the SYSC driver though regmap APIs.
>>>
>>> v3 used the approach from v2 but passed the renesas,sysc-signals to all the
>>> USB related drivers.
>>>
>>> Then, in v4, the PWRRDY refcounting was dropped and passed
>>> renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
>>> is the node that will always be probed first as all the other USB blocks
>>> need it and request resets from it.
>>>
>>> v5 and v6 kept the approach from v4 and only addressed misc comments or
>>> things that I noticed.
>>
>> Could you please let me know if you are OK with the approach proposed in
>> v7, so that I can start preparing a new version addressing your comments?
> 
> If the PWRRDY signal is an input to the USB2PHY control block, and not
> only to the PHY blocks, I have no issue with this being handled in the
> usb2phy reset driver -

Yes, this is how the Renesas HW team confirmed they are related.

> iff it is not sensible to just control the
> signal from the power domain driver.

As mentioned above, that can be done as well but, passing a SYSC phandle to
the CPG DT node will not be valid from the HW description point of view.

> 
> If we have to handle it in the reset driver, I'd prefer to see this
> controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
> I'd like to understand why.

From the code inspection I did, that can be done. From what I can tell at
the moment, I'll have to register a gepnd notifier from
reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
SYSC PWRRDY from it.

Thank you,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel]

Hi Claudiu,

On Di, 2025-10-14 at 11:36 +0300, Claudiu Beznea wrote:
> On 10/13/25 17:57, Philipp Zabel wrote:
[...]
> > > > On 10/8/25 13:23, Philipp Zabel wrote:
> > > > > On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
[...]
> > > > > > The approaches considered were:
> > > > > > a/ power domain
[...]
> > > > > Could you point me to the discussion related to a?
[...]
> > Thank you! From this discussion it still isn't clear to me whether
> > Ulf's suggestion of using genpd on/off notifiers was considered and why
> 
> The genpd on/off notifier suggestion wasn't tried, but only the
> implementation of PWRRDY handling through the power domain (what Ulf
> suggested though "Move the entire reset handling into the PM domain
> provider, as it obviously knows when the domain is getting turned on/off"
> in
> https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/).
> Sorry if I mislead you.

No worries, misunderstandings happen. Here I assumed the "power domain
approach" meant letting the PWRRDY signal be controlled by power domain
state, not specifically all code in the power domain driver. And I only
learned about the genpd notifier suggestion after reading the thread.

> Ulf suggested then here
> https://lore.kernel.org/all/CAPDyKFpLnREr4C=wZ7o8Lb-CZbQa4Nr2VTuYdZHZ26Rcb1Masg@mail.gmail.com/
> that he is not agreeing anymore with having it as power domain due to the
> discussion in thread
> https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/
> (I can't remember what made him taking back is ack on this solution and I
> can't find something in the thread either).
> 
> If I'm not wrong, with the information that we have at the moment, the best
> for the notifier would have to register it (before runtime resume) and
> implement it in this driver (reset-rzg2l-usbphy-ctrl) so that, when the
> pm_runtime_resume_and_get()/pm_runtime_put() in
> rzg2l_usbphy_ctrl_probe()/rzg2l_usbphy_ctrl_remove() will be called (or
> suspend/resume) the notifier will be called and set the PWRRDY bit. Please
> let me know if you see it otherwise.

That sounds like a clean abstraction to me.

> > it was dismissed.
> 
> The power domain approach was dismissed as a result of discussion from this
> thread:
> https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/
> 
> I don't remember exactly what triggered it and can't find it as well, sorry.

Ok.

> > From the DT patches it looks like there is no actual separate power
> > domain for USB, just the single always-on CPG power domain (in rzg2l-
> > cpg.c). Is that correct?
> 
> That is correct, the CPG is a clock power domain. All the clocks that CPG
> can be provided (including USB clocks) are part of CPG clock power domain.
> 
> > In the thread it sounded like there were
> > multiple domains.
> 
> You probably refer to this:
> https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/

Yes, I was confused by this sentence near the end: "And the USB SYSC PM
domain is parent for all USB PM domains provided by CPG (3 in this
case)."

> In there, I was trying to present to Ulf how I did implement (locally,
> nothing posted) the handling of PWRRDY though power domains. In that case
> the SYSC (System Controller), where the PWRRDY resides, was modeled as a
> power domain, I passed to the reset-rzg2l-usbphy-ctrl DT node the phandle
> to sysc USB power domain as:
> 
> power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc R9A08G045_SYSC_PD_USB>;
> 
> along with the cpg, and handled it in the reset-rzg2l-usbphy-ctrl probe().

Ok, thank you for the clarification.

> > Is the issue that you need the PWRRDY signal to be (de)asserted
> > independently from the CPG power domain enable/disable?
> 
> Yes. I need to de-assert it before clocks, MSTOP on probe/resume and assert
> it back after clocks, MSTOP, on remove/suspend.
> 
> > (Why?)
> 
> Due to hardware constraints. This is how Renesas HW team recommended.

I still haven't understood this part. Isn't CPG the power domain
enabled "before clocks, MSTOP on probe resume" and disabled "after
clocks, MSTOP, on remove/suspend"? So PWRRDY could be toggled from
genpd notifications. If it needs to be (de)asserted independently,
wouldn't that mean the genpd notifier approach can not be used?
The notifiers are called from genpd_power_on/off(), after all.

> > Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy
> > property and set the signal together with the power domain?
> 
> That can be done but, passing a SYSC phandle to the CPG DT node will not be
> valid from the HW description point of view.
>
> > > > > I see v2 and v3 tried to control the bit from the PHY drivers, and in
> > > > > v4 we were are already back to the reset driver.
> > > > v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> > > > renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> > > > bit was referenced counted in the SYSC driver though regmap APIs.
> > > > 
> > > > v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> > > > USB related drivers.
> > > > 
> > > > Then, in v4, the PWRRDY refcounting was dropped and passed
> > > > renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> > > > is the node that will always be probed first as all the other USB blocks
> > > > need it and request resets from it.
> > > > 
> > > > v5 and v6 kept the approach from v4 and only addressed misc comments or
> > > > things that I noticed.
> > > 
> > > Could you please let me know if you are OK with the approach proposed in
> > > v7, so that I can start preparing a new version addressing your comments?
> > 
> > If the PWRRDY signal is an input to the USB2PHY control block, and not
> > only to the PHY blocks, I have no issue with this being handled in the
> > usb2phy reset driver -
> 
> Yes, this is how the Renesas HW team confirmed they are related.

Ok, understood. I concur that usb2phy-ctrl is the right place for the
sysc property then.

> > iff it is not sensible to just control the
> > signal from the power domain driver.
> 
> As mentioned above, that can be done as well but, passing a SYSC phandle to
> the CPG DT node will not be valid from the HW description point of view.
>
> > If we have to handle it in the reset driver, I'd prefer to see this
> > controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
> > I'd like to understand why.
> 
> From the code inspection I did, that can be done. From what I can tell at
> the moment, I'll have to register a gepnd notifier from
> reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
> SYSC PWRRDY from it.

I'd like that.

regards
Philipp

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/14/25 19:42, Philipp Zabel wrote:
> Hi Claudiu,
> 
> On Di, 2025-10-14 at 11:36 +0300, Claudiu Beznea wrote:
>> On 10/13/25 17:57, Philipp Zabel wrote:
> [...]
>>>>> On 10/8/25 13:23, Philipp Zabel wrote:
>>>>>> On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
> [...]
>>>>>>> The approaches considered were:
>>>>>>> a/ power domain
> [...]
>>>>>> Could you point me to the discussion related to a?
> [...]
>>> Thank you! From this discussion it still isn't clear to me whether
>>> Ulf's suggestion of using genpd on/off notifiers was considered and why
>>
>> The genpd on/off notifier suggestion wasn't tried, but only the
>> implementation of PWRRDY handling through the power domain (what Ulf
>> suggested though "Move the entire reset handling into the PM domain
>> provider, as it obviously knows when the domain is getting turned on/off"
>> in
>> https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/).
>> Sorry if I mislead you.
> 
> No worries, misunderstandings happen. Here I assumed the "power domain
> approach" meant letting the PWRRDY signal be controlled by power domain
> state, not specifically all code in the power domain driver.

I had a power domain driver implemented with its own genpd::power_{on,
off}, where the PWRRDY bit was set. I just pushed a branch here [1] with my
trials if you would like to check.

[1] https://github.com/claudiubeznea/linux/tree/usb-bringup%2Bpm-domain-v0

> And I only
> learned about the genpd notifier suggestion after reading the thread.
> 
>> Ulf suggested then here
>> https://lore.kernel.org/all/CAPDyKFpLnREr4C=wZ7o8Lb-CZbQa4Nr2VTuYdZHZ26Rcb1Masg@mail.gmail.com/
>> that he is not agreeing anymore with having it as power domain due to the
>> discussion in thread
>> https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/
>> (I can't remember what made him taking back is ack on this solution and I
>> can't find something in the thread either).
>>
>> If I'm not wrong, with the information that we have at the moment, the best
>> for the notifier would have to register it (before runtime resume) and
>> implement it in this driver (reset-rzg2l-usbphy-ctrl) so that, when the
>> pm_runtime_resume_and_get()/pm_runtime_put() in
>> rzg2l_usbphy_ctrl_probe()/rzg2l_usbphy_ctrl_remove() will be called (or
>> suspend/resume) the notifier will be called and set the PWRRDY bit. Please
>> let me know if you see it otherwise.
> 
> That sounds like a clean abstraction to me.
> 
>>> it was dismissed.
>>
>> The power domain approach was dismissed as a result of discussion from this
>> thread:
>> https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/
>>
>> I don't remember exactly what triggered it and can't find it as well, sorry.
> 
> Ok.
> 
>>> From the DT patches it looks like there is no actual separate power
>>> domain for USB, just the single always-on CPG power domain (in rzg2l-
>>> cpg.c). Is that correct?
>>
>> That is correct, the CPG is a clock power domain. All the clocks that CPG
>> can be provided (including USB clocks) are part of CPG clock power domain.
>>
>>> In the thread it sounded like there were
>>> multiple domains.
>>
>> You probably refer to this:
>> https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/
> 
> Yes, I was confused by this sentence near the end: "And the USB SYSC PM
> domain is parent for all USB PM domains provided by CPG (3 in this
> case)."

There were 2 approaches that I've tried with power domain:

1/ to provide both (cpg and PWRRDY) power domains phandle to the
   reset-rzg2l-usbphy-ctrl DT node as:

power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc R9A08G045_SYSC_PD_USB>;

   branch at [1] is for this approach (except, in there the cpg was used as
   an always on power domain, not providing individual controls for each
   IP, due to early implementation of MSTOP (please see above))

2/ to provide a single power domain phandle to the reset-rzg2l-usbphy-ctrl
   DT node, that being the power domain that handled the PWRRDY, and to
   model the PWRRDY-CPG power domains parent-child relation in the driver
   code (as can be seen in commit 7788bcbc3ebe ("initial") from [2], files:
   - arch/arm64/boot/dts/renesas/r9a08g045.dtsi
   - drivers/clk/renesas/r9a08g045-cpg.c, diff:

+       DEF_PD("usb",           RZG3S_PD_USB,
+                               DEF_REG_CONF_COOKIE(SYS_USB_PWRRDY, BIT(0),
RZG3S_FW_SIP_ID),
+                               RZG2L_PD_PARENT_DEFAULT, RZG2L_PD_F_NONE),
+       DEF_PD("usb0",          R9A08G045_PD_USB0,
+                               DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP,
GENMASK(6, 5)),
+                               RZG2L_PD_PARENT_USB, RZG2L_PD_F_NONE),
+       DEF_PD("usb1",          R9A08G045_PD_USB1,
+                               DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(7)),
+                               RZG2L_PD_PARENT_USB, RZG2L_PD_F_NONE),
+       DEF_PD("usb-phy",       R9A08G045_PD_USB_PHY,
+                               DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(4)),
+                               RZG2L_PD_PARENT_USB, RZG2L_PD_F_NONE),

   - drivers/clk/renesas/rzg2l-cpg.c

Please note that code in [2] is ugly.

By "And the USB SYSC PM domain is parent for all USB PM domains provided by
CPG (3 in this case)." I was referring to the solution 2/, implemented in
branch at [2]

Also, few other aspects that I missed to mention in this discussion, which
are important for the genpd notifier approach:

a/ by the time v1 was posted the MSTOP for each IP was abstracted as a
   power domain; at that time the MSTOP was implemented as power domain
   only in the drivers but it wasn't enabled in device tree due to some
   bugs in the watchdog driver

b/ as a result of discussions with Renesas HW team on the USB PWRRDY it was
   revealed that MSTOP must be strictly configured after/before clocks
   enable/disable. Due to this, the MSTOP power domain abstraction was
   dropped from the drivers code and now we are with a always on power
   domain (CPG) for all the IPs, that is actually a clock power domain.
   Today the MSTOP is set in the clock enable/disable APIs.

[2] https://github.com/claudiubeznea/linux/tree/usb-pwrrdy-parent-of-cpg-usb

> 
>> In there, I was trying to present to Ulf how I did implement (locally,
>> nothing posted) the handling of PWRRDY though power domains. In that case
>> the SYSC (System Controller), where the PWRRDY resides, was modeled as a
>> power domain, I passed to the reset-rzg2l-usbphy-ctrl DT node the phandle
>> to sysc USB power domain as:
>>
>> power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc R9A08G045_SYSC_PD_USB>;
>>
>> along with the cpg, and handled it in the reset-rzg2l-usbphy-ctrl probe().
> 
> Ok, thank you for the clarification.
> 
>>> Is the issue that you need the PWRRDY signal to be (de)asserted
>>> independently from the CPG power domain enable/disable?
>>
>> Yes. I need to de-assert it before clocks, MSTOP on probe/resume and assert
>> it back after clocks, MSTOP, on remove/suspend.
>>
>>> (Why?)
>>
>> Due to hardware constraints. This is how Renesas HW team recommended.
> 
> I still haven't understood this part. Isn't CPG the power domain
> enabled "before clocks, MSTOP on probe resume" and disabled "after
> clocks, MSTOP, on remove/suspend"? So PWRRDY could be toggled from
> genpd notifications. If it needs to be (de)asserted independently,
> wouldn't that mean the genpd notifier approach can not be used?

I did tried on my side yesterday evening to prototype the genpd notifier
solution and, yes, you are right.

Because CPG is an always on clock power domain, shared by all it's clocks,
the _genpd_power_on(), where the notifier are invoked, is called only when
the 1st clock in the system is enabled, as there is genpd_status_on() check
in genpd_power_on(), which I missed when I inspected the code yesterday,
when replying to your email.

Because of this, you're right, we can't use the genpd notifier for this,
either.

> The notifiers are called from genpd_power_on/off(), after all.
> 
>>> Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy
>>> property and set the signal together with the power domain?
>>
>> That can be done but, passing a SYSC phandle to the CPG DT node will not be
>> valid from the HW description point of view.
>>
>>>>>> I see v2 and v3 tried to control the bit from the PHY drivers, and in
>>>>>> v4 we were are already back to the reset driver.
>>>>> v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
>>>>> renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
>>>>> bit was referenced counted in the SYSC driver though regmap APIs.
>>>>>
>>>>> v3 used the approach from v2 but passed the renesas,sysc-signals to all the
>>>>> USB related drivers.
>>>>>
>>>>> Then, in v4, the PWRRDY refcounting was dropped and passed
>>>>> renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
>>>>> is the node that will always be probed first as all the other USB blocks
>>>>> need it and request resets from it.
>>>>>
>>>>> v5 and v6 kept the approach from v4 and only addressed misc comments or
>>>>> things that I noticed.
>>>>
>>>> Could you please let me know if you are OK with the approach proposed in
>>>> v7, so that I can start preparing a new version addressing your comments?
>>>
>>> If the PWRRDY signal is an input to the USB2PHY control block, and not
>>> only to the PHY blocks, I have no issue with this being handled in the
>>> usb2phy reset driver -
>>
>> Yes, this is how the Renesas HW team confirmed they are related.
> 
> Ok, understood. I concur that usb2phy-ctrl is the right place for the
> sysc property then.
> 
>>> iff it is not sensible to just control the
>>> signal from the power domain driver.
>>
>> As mentioned above, that can be done as well but, passing a SYSC phandle to
>> the CPG DT node will not be valid from the HW description point of view.
>>
>>> If we have to handle it in the reset driver, I'd prefer to see this
>>> controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
>>> I'd like to understand why.
>>
>> From the code inspection I did, that can be done. From what I can tell at
>> the moment, I'll have to register a gepnd notifier from
>> reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
>> SYSC PWRRDY from it.
> 
> I'd like that.

Now, that we found the genpd notifier is not a solution, could you please
let me know how would you like me to proceed?

Thank you,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Geert Uytterhoeven]

Hi Philipp,

On Tue, 14 Oct 2025 at 18:42, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Di, 2025-10-14 at 11:36 +0300, Claudiu Beznea wrote:
> > On 10/13/25 17:57, Philipp Zabel wrote:
> > > Is the issue that you need the PWRRDY signal to be (de)asserted
> > > independently from the CPG power domain enable/disable?
> >
> > Yes. I need to de-assert it before clocks, MSTOP on probe/resume and assert
> > it back after clocks, MSTOP, on remove/suspend.
> >
> > > (Why?)
> >
> > Due to hardware constraints. This is how Renesas HW team recommended.
>
> I still haven't understood this part. Isn't CPG the power domain
> enabled "before clocks, MSTOP on probe resume" and disabled "after
> clocks, MSTOP, on remove/suspend"? So PWRRDY could be toggled from
> genpd notifications. If it needs to be (de)asserted independently,
> wouldn't that mean the genpd notifier approach can not be used?
> The notifiers are called from genpd_power_on/off(), after all.

Please let me chime in to clarify...

The CPG is not a power domain in the sense of a power area that can
be powered on or off.
The CPG is a clock domain in the Linux PM Domain abstraction, more
specifically an always-on power domain that contains devices that are
all power-managed similarly, through their module clock(s).
Hence the CPG PM Domain itself cannot be powered on or off (through
the generic_pm_domain.power_o{ff,n}() callbacks), but the individual
devices that are part of it can be started/stopped (through the
generic_pm_domain.dev_ops.{start,stop}() callbacks).

I hope this helps.

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 v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Claudiu Beznea]

Hi, Philipp,

On 10/15/25 11:19, Claudiu Beznea wrote:
>>>>>>> I see v2 and v3 tried to control the bit from the PHY drivers, and in
>>>>>>> v4 we were are already back to the reset driver.
>>>>>> v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
>>>>>> renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
>>>>>> bit was referenced counted in the SYSC driver though regmap APIs.
>>>>>>
>>>>>> v3 used the approach from v2 but passed the renesas,sysc-signals to all the
>>>>>> USB related drivers.
>>>>>>
>>>>>> Then, in v4, the PWRRDY refcounting was dropped and passed
>>>>>> renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
>>>>>> is the node that will always be probed first as all the other USB blocks
>>>>>> need it and request resets from it.
>>>>>>
>>>>>> v5 and v6 kept the approach from v4 and only addressed misc comments or
>>>>>> things that I noticed.
>>>>> Could you please let me know if you are OK with the approach proposed in
>>>>> v7, so that I can start preparing a new version addressing your comments?
>>>> If the PWRRDY signal is an input to the USB2PHY control block, and not
>>>> only to the PHY blocks, I have no issue with this being handled in the
>>>> usb2phy reset driver -
>>> Yes, this is how the Renesas HW team confirmed they are related.
>> Ok, understood. I concur that usb2phy-ctrl is the right place for the
>> sysc property then.
>>
>>>> iff it is not sensible to just control the
>>>> signal from the power domain driver.
>>> As mentioned above, that can be done as well but, passing a SYSC phandle to
>>> the CPG DT node will not be valid from the HW description point of view.
>>>
>>>> If we have to handle it in the reset driver, I'd prefer to see this
>>>> controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
>>>> I'd like to understand why.
>>> From the code inspection I did, that can be done. From what I can tell at
>>> the moment, I'll have to register a gepnd notifier from
>>> reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
>>> SYSC PWRRDY from it.
>> I'd like that.
> Now, that we found the genpd notifier is not a solution, could you please
> let me know how would you like me to proceed?

After discussing all the possible (known) solutions, could you please let
me know if you are OK with the approach in this series?

Thank you,
Claudiu

Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel]

Hi Claudiu,

On Di, 2025-10-21 at 11:48 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/15/25 11:19, Claudiu Beznea wrote:
> > > > > > > > I see v2 and v3 tried to control the bit from the PHY drivers, and in
> > > > > > > > v4 we were are already back to the reset driver.
> > > > > > > v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> > > > > > > renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> > > > > > > bit was referenced counted in the SYSC driver though regmap APIs.
> > > > > > > 
> > > > > > > v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> > > > > > > USB related drivers.
> > > > > > > 
> > > > > > > Then, in v4, the PWRRDY refcounting was dropped and passed
> > > > > > > renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> > > > > > > is the node that will always be probed first as all the other USB blocks
> > > > > > > need it and request resets from it.
> > > > > > > 
> > > > > > > v5 and v6 kept the approach from v4 and only addressed misc comments or
> > > > > > > things that I noticed.
> > > > > > Could you please let me know if you are OK with the approach proposed in
> > > > > > v7, so that I can start preparing a new version addressing your comments?
> > > > > If the PWRRDY signal is an input to the USB2PHY control block, and not
> > > > > only to the PHY blocks, I have no issue with this being handled in the
> > > > > usb2phy reset driver -
> > > > Yes, this is how the Renesas HW team confirmed they are related.
> > > Ok, understood. I concur that usb2phy-ctrl is the right place for the
> > > sysc property then.
> > > 
> > > > > iff it is not sensible to just control the
> > > > > signal from the power domain driver.
> > > > As mentioned above, that can be done as well but, passing a SYSC phandle to
> > > > the CPG DT node will not be valid from the HW description point of view.
> > > > 
> > > > > If we have to handle it in the reset driver, I'd prefer to see this
> > > > > controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
> > > > > I'd like to understand why.
> > > > From the code inspection I did, that can be done. From what I can tell at
> > > > the moment, I'll have to register a gepnd notifier from
> > > > reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
> > > > SYSC PWRRDY from it.
> > > I'd like that.
> > Now, that we found the genpd notifier is not a solution, could you please
> > let me know how would you like me to proceed?
> 
> After discussing all the possible (known) solutions, could you please let
> me know if you are OK with the approach in this series?

Yes, I don't have a better idea. Let's revisit the issue of ordering
guarantees when suspend/resume is implemented.

regards
Philipp