[PATCH v3 0/9] Add RZ/G3L USB2.0 host support

[PATCH v3 0/9] Add RZ/G3L USB2.0 host support

[Biju]

From: Biju Das <biju.das.jz@bp.renesas.com>

Add device tree binding support for the RZ/G3L (r9a08g046) USB PHY
controller. The RZ/G3L USB PHY block is similar to RZ/G3S, but each port
has an OTG controller, unlike RZ/G3S, which has an OTG controller only on
port 1.

v2->v3:
 * Replaced items->enum in reset controller bindings.
 * Collected the tag for reset binding patch.
 * Dropped clock patch as it is accepted.
v1->v2:
 * Dropped patch#6(Introduce helper for regulator registration)
 * Passing pointer to an array of regulators to make it scalable.
 * Dropped regulator1-vbus and added a regulators group node.
 * Updated commit description for patch#1,#4,#6,#7,#8,#9 and #10.
 * Added enum instead of const in the compatible section.
 * Updated schema check.
 * Collected tag for PHY binding patch.
   in the regulator driver.
 * Added regulators group node and its children in SoC dtsi.

Biju Das (9):
  dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
  dt-bindings: phy: renesas,usb2-phy: Document RZ/G3L PHY bindings
  reset: rzg2l-usbphy-ctrl: Introduce info struct for match data
  reset: rzg2l-usbphy-ctrl: Add RZ/G3L support
  regulator: renesas-usb-vbus-regulator: Add RZ/G3L VBUS regulator
    support
  phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support
  phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for
    disabled VBUS regulator
  arm64: dts: renesas: r9a08g046: Add USB2.0 device nodes
  arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support

 .../bindings/phy/renesas,usb2-phy.yaml        |   2 +
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      |  48 +++++++-
 arch/arm64/boot/dts/renesas/r9a08g046.dtsi    | 105 ++++++++++++++++++
 .../boot/dts/renesas/r9a08g046l48-smarc.dts   |  49 ++++++++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  20 ++--
 .../regulator/renesas-usb-vbus-regulator.c    |  53 +++++++++
 drivers/reset/reset-rzg2l-usbphy-ctrl.c       |  44 +++++---
 7 files changed, 296 insertions(+), 25 deletions(-)

-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v3 2/9] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3L PHY bindings

[Biju]

From: Biju Das <biju.das.jz@bp.renesas.com>

Add device tree binding support for the RZ/G3L (r9a08g046) USB2 PHY.
The RZ/G3L USB PHY is almost identical to the RZ/G3S USB PHY, the
difference being 2 OTG blocks on RZ/G3L compared to 1 on RZ/G3S.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * No change
v1->v2:
 * Collected tag.
---
 Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index 9740e5b335f9..d6b9d08ceec6 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -16,6 +16,7 @@ properties:
           - enum:
               - renesas,usb2-phy-r8a77470  # RZ/G1C
               - renesas,usb2-phy-r9a08g045 # RZ/G3S
+              - renesas,usb2-phy-r9a08g046 # RZ/G3L
               - renesas,usb2-phy-r9a09g057 # RZ/V2H(P)
 
       - items:
@@ -132,6 +133,7 @@ allOf:
             enum:
               - renesas,usb2-phy-r9a09g057
               - renesas,usb2-phy-r9a08g045
+              - renesas,usb2-phy-r9a08g046
               - renesas,rzg2l-usb2-phy
     then:
       properties:
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v3 6/9] phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support

[Biju]

From: Biju Das <biju.das.jz@bp.renesas.com>

Add renesas,usb2-phy-r9a08g046 to the OF match table, reusing
rz_g3s_phy_usb2_data as the PHY configuration is shared with RZ/G3S.

While the PHY data is shared, RZ/G3L differs from RZ/G3S in that it has
two OTG controllers, OTG interrupts on port 2, and a controllable
OTG_PERI bit in COMMCTRL for host/device switching on the port 2 USB
controller, which is fixed to host-only on RZ/G3S.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * No change.
v1->v2:
 * Updated commit description.
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 9a45d840efeb..d06fb52ed5f1 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -721,6 +721,10 @@ static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
 		.compatible = "renesas,usb2-phy-r9a08g045",
 		.data = &rz_g3s_phy_usb2_data,
 	},
+	{
+		.compatible = "renesas,usb2-phy-r9a08g046",
+		.data = &rz_g3s_phy_usb2_data,
+	},
 	{
 		.compatible = "renesas,usb2-phy-r9a09g057",
 		.data = &rz_v2h_phy_usb2_data,
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 6/9] phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Sleep-in-atomic bug due to calling regulator_hardware_enable() inside a spinlock and from a hardirq handler.
--

--- Patch [6]: [PATCH v3 6/9] phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support ---
commit 502c90feba61fdb92ccdaff21a3e226e6113ab48
Author: Biju Das <biju.das.jz@bp.renesas.com>

phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support

This commit adds support for the RZ/G3L SoC to the phy-rcar-gen3-usb2 driver
by adding the "renesas,usb2-phy-r9a08g046" compatible string. The PHY data
configuration is shared with RZ/G3S.

> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index 9a45d840efeb2..d06fb52ed5f1b 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -721,6 +721,10 @@ static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
>  		.compatible = "renesas,usb2-phy-r9a08g045",
>  		.data = &rz_g3s_phy_usb2_data,
>  	},
> +	{
> +		.compatible = "renesas,usb2-phy-r9a08g046",
> +		.data = &rz_g3s_phy_usb2_data,
> +	},

[Severity: High]
This is a pre-existing issue, but since this patch exposes this hardware to 
existing code paths, I wanted to ask about a potential sleep-in-atomic bug.

When a user writes to the role sysfs attribute, role_store() acquires a
spinlock and disables interrupts:

drivers/phy/renesas/phy-rcar-gen3-usb2.c:role_store() {
    guard(spinlock_irqsave)(&ch->lock);
    ...
    if (!is_b_device)    /* A-Peripheral */
        rcar_gen3_init_from_a_peri_to_a_host(ch);
}

This calls down to rcar_gen3_enable_vbus_ctrl(), which then triggers the
regulator operations:

drivers/phy/renesas/phy-rcar-gen3-usb2.c:rcar_gen3_enable_vbus_ctrl() {
    ...
    if (ch->otg_internal_reg) {
        regulator_hardware_enable(ch->vbus, vbus);
        return;
    }

    if (ch->phy_data->no_adp_ctrl || ch->phy_data->vblvl_ctrl) {
        if (ch->vbus)
            regulator_hardware_enable(ch->vbus, vbus);
    ...
}

For SoCs using the internal regulator (such as RZ/G3L), the enable callback
invokes pm_runtime_resume_and_get():

drivers/phy/renesas/phy-rcar-gen3-usb2.c:rcar_gen3_phy_usb2_regulator_endisable() {
    ...
    ret = pm_runtime_resume_and_get(dev);
    ...
}

Can this sequence cause a panic? 

If the device state is RPM_SUSPENDING, pm_runtime_resume_and_get() might sleep
waiting for the asynchronous suspend to finish, but we are inside an atomic
section holding ch->lock with interrupts disabled.

Similarly, does the rcar_gen3_phy_usb2_irq() hardirq handler also reach
this regulator_hardware_enable() path on OTG plug/unplug events? If so,
would it hit the same sleep-in-atomic issue?

>  	{
>  		.compatible = "renesas,usb2-phy-r9a09g057",
>  		.data = &rz_v2h_phy_usb2_data,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707143646.245177-1-biju.das.jz@bp.renesas.com?part=6

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v3 7/9] phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator

[Biju]

From: Biju Das <biju.das.jz@bp.renesas.com>

devm_regulator_get_exclusive() initialises the regulator with
enable_count = 1, requiring the consumer to disable it before release.

The devm disable action was previously only registered when the caller
explicitly requested enable, so when the regulator was left in its initial
enabled state without an explicit enable call, the cleanup path skipped
decrementing enable_count, triggering a WARN_ON during regulator
release on device removal.

Fix this by always registering the devm disable action based on the actual
enabled state via regulator_is_enabled(), regardless of whether the
caller requested an explicit enable. This covers both the explicitly-enabled
case and the initial state set by devm_regulator_get_exclusive().

Fixes: 24843404efe4 ("phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCs")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * No change.
v1->v2:
 * Updated commit description.
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index d06fb52ed5f1..ef38c3b365d4 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -905,15 +905,17 @@ static int rcar_gen3_phy_usb2_vbus_regulator_get_exclusive_enable(struct rcar_ge
 	if (IS_ERR(channel->vbus))
 		return PTR_ERR(channel->vbus);
 
-	if (!enable)
-		return 0;
+	if (enable) {
+		ret = regulator_enable(channel->vbus);
+		if (ret)
+			return ret;
+	}
 
-	ret = regulator_enable(channel->vbus);
-	if (ret)
-		return ret;
+	if (regulator_is_enabled(channel->vbus))
+		return devm_add_action_or_reset(dev, rcar_gen3_phy_usb2_vbus_disable_action,
+						channel->vbus);
 
-	return devm_add_action_or_reset(dev, rcar_gen3_phy_usb2_vbus_disable_action,
-					channel->vbus);
+	return 0;
 }
 
 static int rcar_gen3_phy_usb2_vbus_regulator_register(struct rcar_gen3_chan *channel)
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 7/9] phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [Medium] `regulator_is_enabled()` returns a negative error code on failure, which incorrectly evaluates to true and causes an unbalanced disable WARN_ON.

Pre-existing issues:
- [High] If the regulator was initially enabled in hardware AND explicitly enabled by the driver, only one disable action is registered, leading to a resource leak and WARN_ON.
- [High] If `regulator_enable()` fails, the function returns early without registering a disable action, leaking the implicit `enable_count` reference if the regulator was already enabled.
- [High] Missing cancellation of the pending workqueue task (`channel->work`) during device removal leads to a Use-After-Free.
--

--- Patch [7]: [PATCH v3 7/9] phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator ---
commit 30054990ee806fb8d79768ae79587b9acfe0f6a6
Author: Biju Das <biju.das.jz@bp.renesas.com>

phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator

This commit updates the VBUS regulator registration to always add a devm
disable action based on the actual enabled state, rather than only when
an explicit enable was requested. This ensures the regulator's enable_count
is correctly decremented during device removal even if it was left enabled
by the bootloader.

> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index d06fb52ed5f1b..ef38c3b365d42 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -905,15 +905,17 @@ static int rcar_gen3_phy_usb2_vbus_regulator_get_exclusive_enable(struct rcar_ge
>  	if (IS_ERR(channel->vbus))
>  		return PTR_ERR(channel->vbus);
>  
> -	if (!enable)
> -		return 0;
> +	if (enable) {
> +		ret = regulator_enable(channel->vbus);
> +		if (ret)
> +			return ret;

[Severity: High]
This is a pre-existing issue, but does this early return leak the implicit
enable_count reference if the regulator was already enabled?

If devm_regulator_get_exclusive() initializes enable_count to 1 (because the
hardware was already enabled), and this regulator_enable() call fails, we
return early and bypass registering the devm disable action. When the probe
fails and devres cleans up, regulator_put() will be called with
enable_count == 1, which triggers a WARN_ON(regulator->enable_count) and
leaks the underlying rdev->use_count.

> +	}
>  
> -	ret = regulator_enable(channel->vbus);
> -	if (ret)
> -		return ret;
> +	if (regulator_is_enabled(channel->vbus))
> +		return devm_add_action_or_reset(dev, rcar_gen3_phy_usb2_vbus_disable_action,
> +						channel->vbus);

[Severity: Medium]
Does regulator_is_enabled() return a negative error code on failure, and
will that be incorrectly evaluated as true here?

If a hardware or I2C error occurs, regulator_is_enabled() can return a
negative value. This condition would evaluate as true, queueing the
rcar_gen3_phy_usb2_vbus_disable_action even if the regulator is actually
disabled or its enable_count is 0. 

On device removal, calling regulator_disable() with an enable_count of 0
triggers a WARN in the regulator core.

[Severity: High]
This is a pre-existing issue, but does this logic lead to a resource leak if
the regulator was initially enabled in hardware and explicitly enabled by the
driver?

If the bootloader leaves the regulator enabled,
devm_regulator_get_exclusive() initializes enable_count to 1. If the driver
also explicitly requests enable = true, regulator_enable() increments
enable_count to 2. 

However, this logic only registers a single disable action. During unbind,
the action decrements enable_count to 1, and devm_regulator_release() calls
regulator_put() which triggers a WARN_ON and destroys the consumer struct
without fully decrementing the underlying rdev->use_count.

> -	return devm_add_action_or_reset(dev, rcar_gen3_phy_usb2_vbus_disable_action,
> -					channel->vbus);
> +	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but does this device removal sequence miss
canceling the pending workqueue task?

drivers/phy/renesas/phy-rcar-gen3-usb2.c:rcar_gen3_phy_usb2_remove() {
	struct rcar_gen3_chan *channel = platform_get_drvdata(pdev);

	if (channel->is_otg_channel)
		device_remove_file(&pdev->dev, &dev_attr_role);
}

The driver schedules channel->work from its IRQ handler. If the driver is
unbound while an IRQ is being processed, rcar_gen3_phy_usb2_remove()
executes but does not call cancel_work_sync(&channel->work).

As devres cleans up, it frees the channel structure. If the workqueue
executes after channel is freed, it will dereference freed memory leading
to a use-after-free.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707143646.245177-1-biju.das.jz@bp.renesas.com?part=7

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy