[PATCH] net: dwmac-rk: No need to check the return value of the phy_power_on()

李哲 posted 1 patch 6 months, 3 weeks ago
There is a newer version of this series
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
[PATCH] net: dwmac-rk: No need to check the return value of the phy_power_on()
Posted by 李哲 6 months, 3 weeks ago
since the return value of the phy_power_on() function is always 0,
checking its return value is redundant.

Signed-off-by: 李哲 <sensor1010@163.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 700858ff6f7c..6e8b10fda24d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1839,11 +1839,7 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
 		dev_err(dev, "NO interface defined!\n");
 	}
 
-	ret = phy_power_on(bsp_priv, true);
-	if (ret) {
-		gmac_clk_enable(bsp_priv, false);
-		return ret;
-	}
+	phy_power_on(bsp_priv, true);
 
 	pm_runtime_get_sync(dev);
 
-- 
2.17.1

Re: [PATCH] net: dwmac-rk: No need to check the return value of the phy_power_on()
Posted by Christophe JAILLET 6 months, 3 weeks ago
Le 26/05/2025 à 18:16, 李哲 a écrit :
> since the return value of the phy_power_on() function is always 0,
> checking its return value is redundant.

Can you elaborate why?

Looking at  (1], I think that it is obvious that non-0 values can be 
returned.


CJ

[1]: 
https://elixir.bootlin.com/linux/v6.15/source/drivers/phy/phy-core.c#L305

> 
> Signed-off-by: 李哲 <sensor1010@163.com>
> ---
>   drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-----
>   1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 700858ff6f7c..6e8b10fda24d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1839,11 +1839,7 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
>   		dev_err(dev, "NO interface defined!\n");
>   	}
>   
> -	ret = phy_power_on(bsp_priv, true);
> -	if (ret) {
> -		gmac_clk_enable(bsp_priv, false);
> -		return ret;
> -	}
> +	phy_power_on(bsp_priv, true);
>   
>   	pm_runtime_get_sync(dev);
>   

Re: [PATCH] net: dwmac-rk: No need to check the return value of the phy_power_on()
Posted by Andrew Lunn 6 months, 3 weeks ago
On Tue, May 27, 2025 at 07:43:57AM +0200, Christophe JAILLET wrote:
> Le 26/05/2025 à 18:16, 李哲 a écrit :
> > since the return value of the phy_power_on() function is always 0,
> > checking its return value is redundant.
> 
> Can you elaborate why?
> 
> Looking at  (1], I think that it is obvious that non-0 values can be
> returned.

Wrong phy_power_on(). There is a local scope one within the driver.

	Andrew
Re: [PATCH] net: dwmac-rk: No need to check the return value of the phy_power_on()
Posted by Andrew Lunn 6 months, 3 weeks ago
On Mon, May 26, 2025 at 09:16:21AM -0700, 李哲 wrote:
> since the return value of the phy_power_on() function is always 0,
> checking its return value is redundant.
> 
> Signed-off-by: 李哲 <sensor1010@163.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 700858ff6f7c..6e8b10fda24d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1839,11 +1839,7 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
>  		dev_err(dev, "NO interface defined!\n");
>  	}
>  
> -	ret = phy_power_on(bsp_priv, true);
> -	if (ret) {
> -		gmac_clk_enable(bsp_priv, false);
> -		return ret;
> -	}
> +	phy_power_on(bsp_priv, true);

I suggest you go one step further and turn phy_power_on() into a void
function.

net-next is closed for the next two week due to the merge window.

	Andrew