[PATCH v2 0/3] phy: renesas: rcar-gen2: three cleanups

[PATCH v2 0/3] phy: renesas: rcar-gen2: three cleanups

[Felix Gu]

Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Merge patch 1 and patch 2 into one series.
- Collect Krzysztof's reviewed-by for patch 1.
- Add patch 3 to use dev_err_probe() in probe function.
- Link to v1: https://patch.msgid.link/20260803-rcar-gen2-v1-1-9aa35c36d7d7@gmail.com

To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Geert Uytterhoeven <geert+renesas@glider.be>
To: Magnus Damm <magnus.damm@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
To: Kishon Vijay Abraham I <kishon@kernel.org>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: linux-phy@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Felix Gu (3):
      phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure
      phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
      phy: renesas: rcar-gen2: Use dev_err_probe() in probe

 drivers/phy/renesas/phy-rcar-gen2.c | 36 ++++++++++++++----------------------
 1 file changed, 14 insertions(+), 22 deletions(-)
---
base-commit: 415606a7be939835db9b0d6b711887586646346d
change-id: 20260803-rcar-gen2-140f014cd384

Best regards,
--  
Felix Gu <ustc.gu@gmail.com>


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

[PATCH v2 1/3] phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure

[Felix Gu]

for_each_child_of_node_scoped() releases the node reference on scope
exit, so the explicit of_node_put(np) in the devm_phy_create() error
path drops it twice.

Drop the redundant of_node_put() and let the scoped cleanup handle it.

Fixes: b64b32791fb5 ("phy: renesas: rcar-gen2: Simplify with scoped for each OF child loop")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
 drivers/phy/renesas/phy-rcar-gen2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
index 6c671254c625..5a272e25e051 100644
--- a/drivers/phy/renesas/phy-rcar-gen2.c
+++ b/drivers/phy/renesas/phy-rcar-gen2.c
@@ -405,7 +405,6 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 						   data->gen2_phy_ops);
 			if (IS_ERR(phy->phy)) {
 				dev_err(dev, "Failed to create PHY\n");
-				of_node_put(np);
 				return PTR_ERR(phy->phy);
 			}
 			phy_set_drvdata(phy->phy, phy);

-- 
2.43.0


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

Re: [PATCH v2 1/3] phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing reference count increment for device node leads to a dangling pointer.
- [High] TOCTOU race condition between child count and iteration leads to out-of-bounds array write.
--

--- Patch [1]: [PATCH v2 1/3] phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure ---
commit 047745265c7b61da44949752ecc277b2156237a3
Author: Felix Gu <ustc.gu@gmail.com>

phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure

This commit fixes a double of_node_put() issue in the error path of
devm_phy_create(). The scoped iterator for_each_child_of_node_scoped()
already handles dropping the node reference, so the explicit of_node_put()
was redundant.

> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 6c671254c6258..5a272e25e051c 100644
> --- a/drivers/phy/renesas/phy-rcar-gen2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen2.c
> @@ -405,7 +405,6 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  						   data->gen2_phy_ops);
>  			if (IS_ERR(phy->phy)) {
>  				dev_err(dev, "Failed to create PHY\n");

[Severity: High]
This is a pre-existing issue, but does this code leave a dangling pointer
when saving the node?

Looking at rcar_gen2_phy_probe(), we save np to channel->of_node:

	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
		...
		channel->of_node = np;

Because for_each_child_of_node_scoped() automatically drops the reference on
the node when advancing or exiting, channel->of_node becomes a dangling pointer.

Later in rcar_gen2_phy_xlate(), this potentially dangling pointer is
used for comparison:

	if (np == drv->channels[i].of_node)

Could this falsely match a newly allocated node due to pointer aliasing if a
DT overlay is applied and removed? Should we call of_node_get() before
saving it to channel->of_node?


[Severity: High]
This is also a pre-existing issue, but is there a potential out-of-bounds write
if the number of child nodes changes?

Earlier in rcar_gen2_phy_probe(), the driver allocates the channels array based
on the child count:

	drv->num_channels = of_get_child_count(dev->of_node);
	drv->channels = devm_kcalloc(dev, drv->num_channels, ...);

Then it iterates over the children and increments i:

	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
		...
		i++;
	}

If child nodes are added dynamically (e.g., via a DT overlay) between the call
to of_get_child_count() and the for_each_child_of_node_scoped() loop, could i
exceed drv->num_channels and cause an out-of-bounds write when accessing
drv->channels + i?

> -				of_node_put(np);
>  				return PTR_ERR(phy->phy);
>  			}
>  			phy_set_drvdata(phy->phy, phy);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-rcar-gen2-v2-0-829cb84112ca@gmail.com?part=1

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

[PATCH v2 2/3] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg

[Felix Gu]

When of_property_read_u32() succeeds but channel_num exceeds
data->num_channels, rcar_gen2_phy_probe() returns error which is 0,
so probe reports success even though no PHY provider is registered.

Return -EINVAL in that case.

Fixes: 1233f59f745b ("phy: Renesas R-Car Gen2 PHY driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
 drivers/phy/renesas/phy-rcar-gen2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
index 5a272e25e051..b18727ed41a1 100644
--- a/drivers/phy/renesas/phy-rcar-gen2.c
+++ b/drivers/phy/renesas/phy-rcar-gen2.c
@@ -390,7 +390,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 		error = of_property_read_u32(np, "reg", &channel_num);
 		if (error || channel_num >= data->num_channels) {
 			dev_err(dev, "Invalid \"reg\" property\n");
-			return error;
+			return error ?: -EINVAL;
 		}
 		channel->select_mask = select_mask[channel_num];
 

-- 
2.43.0


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

Re: [PATCH v2 2/3] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg

[sashiko-bot]

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

Pre-existing issues:
- [High] Pointer to device node 'np' is stored in 'channel->of_node' without holding a reference, leading to a dangling pointer.
- [High] Race condition in probe: PHY provider is registered before driver data is set.
- [High] The return value of clk_prepare_enable() is ignored, leading to a potential system lockup if the clock fails to enable.
- [Medium] Holding a spinlock with interrupts disabled for 340 microseconds violates kernel latency constraints.
--

--- Patch [2]: [PATCH v2 2/3] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg ---
commit b403c6500188baed7349ae963beab9f0eda61eb2
Author: Felix Gu <ustc.gu@gmail.com>

    phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
    
    When of_property_read_u32() succeeds but channel_num exceeds
    data->num_channels, rcar_gen2_phy_probe() returns error which is 0,
    so probe reports success even though no PHY provider is registered.
    
    Return -EINVAL in that case.
    
    Fixes: 1233f59f745b ("phy: Renesas R-Car Gen2 PHY driver")
    Signed-off-by: Felix Gu <ustc.gu@gmail.com>

> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 5a272e25e051c..b18727ed41a10 100644
> --- a/drivers/phy/renesas/phy-rcar-gen2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen2.c
> @@ -390,7 +390,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  		error = of_property_read_u32(np, "reg", &channel_num);
>  		if (error || channel_num >= data->num_channels) {
>  			dev_err(dev, "Invalid \"reg\" property\n");
> -			return error;
> +			return error ?: -EINVAL;
>  		}
>  		channel->select_mask = select_mask[channel_num];
>  

While reviewing this patch, I noticed a few pre-existing issues in this file
that might be worth addressing:

In rcar_gen2_phy_probe():

> 	for_each_child_of_node_scoped(dev->of_node, np) {
> 		struct rcar_gen2_channel *channel = drv->channels + i;
> 		u32 channel_num;
> 		int error, n;
> 
> 		channel->of_node = np;

[Severity: High]
This isn't a bug introduced by this patch, but the device node pointer 'np' is
assigned to the persistent channel structure without taking a reference.
Since 'for_each_child_of_node_scoped' automatically drops the reference on loop
exit, does this leave a dangling pointer in 'channel->of_node'? Later,
rcar_gen2_phy_xlate() compares 'np == drv->channels[i].of_node', which might
lead to an ABA problem if the node is freed and reallocated. Should we call
of_node_get() here?

Later in rcar_gen2_phy_probe():

> 	provider = devm_of_phy_provider_register(dev, rcar_gen2_phy_xlate);
> 	if (IS_ERR(provider)) {
> 		dev_err(dev, "Failed to register PHY provider\n");
> 		return PTR_ERR(provider);
> 	}
> 
> 	dev_set_drvdata(dev, drv);

[Severity: High]
This is also a pre-existing issue, but is there a race condition here during
probe? We register the PHY provider and expose it to consumers before we
initialize the driver data with dev_set_drvdata(). If a consumer driver tries
to acquire the PHY right after devm_of_phy_provider_register(),
rcar_gen2_phy_xlate() could execute, call dev_get_drvdata(), and receive NULL.

In rcar_gen2_phy_init():

> 	clk_prepare_enable(drv->clk);
> 
> 	spin_lock_irqsave(&drv->lock, flags);
> 	ugctrl2 = readl(drv->base + USBHS_UGCTRL2);

[Severity: High]
This is a pre-existing issue, but does this code need to check the return value
of clk_prepare_enable()? If the clock fails to enable, we proceed to
immediately access the hardware registers which could lock up the system or
cause a synchronous external abort.

In rz_g1c_phy_power_on():

> 	spin_lock_irqsave(&drv->lock, flags);
> 
> 	/* Power on USBHS PHY */
> 	value = readl(base + USBHS_UGCTRL);
> 	value &= ~USBHS_UGCTRL_PLLRESET;
> 	writel(value, base + USBHS_UGCTRL);
> 
> 	/* As per the data sheet wait 340 micro sec for power stable */
> 	udelay(340);

[Severity: Medium]
This is a pre-existing issue, but is it safe to hold a spinlock with
interrupts disabled for 340 microseconds here? This seems like it would
severely impact system latency, potentially causing missed interrupts.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-rcar-gen2-v2-0-829cb84112ca@gmail.com?part=2

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

[PATCH v2 3/3] phy: renesas: rcar-gen2: Use dev_err_probe() in probe

[Felix Gu]

Convert the error paths in rcar_gen2_phy_probe() to dev_err_probe().

Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
 drivers/phy/renesas/phy-rcar-gen2.c | 35 ++++++++++++++---------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
index b18727ed41a1..581f6768e2bb 100644
--- a/drivers/phy/renesas/phy-rcar-gen2.c
+++ b/drivers/phy/renesas/phy-rcar-gen2.c
@@ -342,17 +342,13 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 	const struct rcar_gen2_phy_data *data;
 	int i = 0;
 
-	if (!dev->of_node) {
-		dev_err(dev,
-			"This driver is required to be instantiated from device tree\n");
-		return -EINVAL;
-	}
+	if (!dev->of_node)
+		return dev_err_probe(dev, -EINVAL,
+				     "This driver is required to be instantiated from device tree\n");
 
 	clk = devm_clk_get(dev, "usbhs");
-	if (IS_ERR(clk)) {
-		dev_err(dev, "Can't get USBHS clock\n");
-		return PTR_ERR(clk);
-	}
+	if (IS_ERR(clk))
+		return dev_err_probe(dev, PTR_ERR(clk), "Can't get USBHS clock\n");
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base))
@@ -388,10 +384,9 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 		channel->selected_phy = -1;
 
 		error = of_property_read_u32(np, "reg", &channel_num);
-		if (error || channel_num >= data->num_channels) {
-			dev_err(dev, "Invalid \"reg\" property\n");
-			return error ?: -EINVAL;
-		}
+		if (error || channel_num >= data->num_channels)
+			return dev_err_probe(dev, error ?: -EINVAL,
+					     "Invalid \"reg\" property\n");
 		channel->select_mask = select_mask[channel_num];
 
 		for (n = 0; n < PHYS_PER_CHANNEL; n++) {
@@ -403,10 +398,9 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 
 			phy->phy = devm_phy_create(dev, NULL,
 						   data->gen2_phy_ops);
-			if (IS_ERR(phy->phy)) {
-				dev_err(dev, "Failed to create PHY\n");
-				return PTR_ERR(phy->phy);
-			}
+			if (IS_ERR(phy->phy))
+				return dev_err_probe(dev, PTR_ERR(phy->phy),
+						     "Failed to create PHY\n");
 			phy_set_drvdata(phy->phy, phy);
 		}
 
@@ -414,10 +408,9 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
 	}
 
 	provider = devm_of_phy_provider_register(dev, rcar_gen2_phy_xlate);
-	if (IS_ERR(provider)) {
-		dev_err(dev, "Failed to register PHY provider\n");
-		return PTR_ERR(provider);
-	}
+	if (IS_ERR(provider))
+		return dev_err_probe(dev, PTR_ERR(provider),
+				     "Failed to register PHY provider\n");
 
 	dev_set_drvdata(dev, drv);
 

-- 
2.43.0


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

Re: [PATCH v2 3/3] phy: renesas: rcar-gen2: Use dev_err_probe() in probe

[sashiko-bot]

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

Pre-existing issues:
- [High] The PHY provider is registered before the driver data is set, creating a race window where PHY lookup can fail.
- [High] The driver saves a scoped device node pointer into a persistent structure without incrementing its reference count, leading to a dangling pointer.
- [High] A Time-Of-Check to Time-Of-Use (TOCTOU) race condition with device tree modifications can lead to an array out-of-bounds access.
--

--- Patch [3]: [PATCH v2 3/3] phy: renesas: rcar-gen2: Use dev_err_probe() in probe ---
commit 709d9b8218087abc6526b29b382856eb53ccb3ba
Author: Felix Gu <ustc.gu@gmail.com>

    phy: renesas: rcar-gen2: Use dev_err_probe() in probe
    
    Convert the error paths in rcar_gen2_phy_probe() to dev_err_probe().

> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index b18727ed41a10..581f6768e2bb2 100644
> --- a/drivers/phy/renesas/phy-rcar-gen2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen2.c
[ ... ]
> @@ -388,10 +384,9 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  		channel->selected_phy = -1;

[Severity: High]
This isn't a bug introduced by this patch, but could the assignment to
channel->of_node just above this line result in a dangling pointer?

Looking at rcar_gen2_phy_probe(), the loop uses
for_each_child_of_node_scoped(dev->of_node, np) which automatically
decrements the reference count of np at the end of each iteration.

Since channel->of_node = np stores this pointer into the persistent
channel structure without calling of_node_get(np), wouldn't this leave
channel->of_node pointing to freed memory once the scope ends?

[Severity: High]
This isn't a bug introduced by this patch, but is there a risk of an
out-of-bounds array access in this loop?

Earlier in rcar_gen2_phy_probe(), drv->channels is allocated based on
of_get_child_count():

    drv->num_channels = of_get_child_count(dev->of_node);
    drv->channels = devm_kcalloc(dev, drv->num_channels, ...);

If a dynamic device tree overlay adds a child node concurrently before or
during the for_each_child_of_node_scoped() loop, the loop will iterate
more times than drv->num_channels. Would the assignment
channel = drv->channels + i then write past the end of the allocation?

>  		error = of_property_read_u32(np, "reg", &channel_num);
> -		if (error || channel_num >= data->num_channels) {
> -			dev_err(dev, "Invalid \"reg\" property\n");
> -			return error ?: -EINVAL;
> -		}
> +		if (error || channel_num >= data->num_channels)
> +			return dev_err_probe(dev, error ?: -EINVAL,
> +					     "Invalid \"reg\" property\n");
>  		channel->select_mask = select_mask[channel_num];
[ ... ]
> @@ -414,10 +408,9 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  	}
>  
>  	provider = devm_of_phy_provider_register(dev, rcar_gen2_phy_xlate);
> -	if (IS_ERR(provider)) {
> -		dev_err(dev, "Failed to register PHY provider\n");
> -		return PTR_ERR(provider);
> -	}
> +	if (IS_ERR(provider))
> +		return dev_err_probe(dev, PTR_ERR(provider),
> +				     "Failed to register PHY provider\n");
>  
>  	dev_set_drvdata(dev, drv);

[Severity: High]
This isn't a bug introduced by this patch, but does the registration order
create a race condition?

The PHY provider is registered via devm_of_phy_provider_register() before
dev_set_drvdata(dev, drv) is called.

If a concurrent deferred probe or module load calls rcar_gen2_phy_xlate()
during this window, it will try to access driver data that hasn't been set
yet. Should dev_set_drvdata() be called before exposing the PHY provider
to the system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-rcar-gen2-v2-0-829cb84112ca@gmail.com?part=3

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