[Linux-stm32] [PATCH] net: dwmac-rk: MAC clock should be truned off

lizhe sensor1010 at 163.com
Sat May 24 14:05:47 UTC 2025


Hi, Anerdw
The following is the logic for calling this function: 




rk_gmac_powerup() {

ret = phy_power_on(bsp_priv, true);      // here.

if (ret) {

gmac_clk_enable(bsp_priv, false);

return ret;

}

}

If this function consistently returns 0, is there still a need to validate its return value?
The rationale for checking the return value is to disable the clock on mac




_Thanks,
Lizhe











At 2025-05-24 00:20:13, "Andrew Lunn" <andrew at lunn.ch> wrote:
>On Fri, May 23, 2025 at 08:15:21AM -0700, 李哲 wrote:
>> if PHY power-on fails, clockassociated the MAC should
>> be disabled during the MAC initialization process
>
>The Subject: line has a typo.
>
>> Signed-off-by: 李哲 <sensor1010 at 163.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> index 700858ff6f7c..036e45be5828 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> @@ -1648,7 +1648,7 @@ static int gmac_clk_enable(struct rk_priv_data *bsp_priv, bool enable)
>>  static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
>>  {
>>  	struct regulator *ldo = bsp_priv->regulator;
>> -	int ret;
>> +	int ret = 0;
>>  	struct device *dev = &bsp_priv->pdev->dev;
>>  
>>  	if (enable) {
>> @@ -1661,7 +1661,7 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
>>  			dev_err(dev, "fail to disable phy-supply\n");
>>  	}
>>  
>> -	return 0;
>> +	return ret;
>
>This does not make much sense to me. How do you get here with ret not
>being 0?
>
>    Andrew
>
>---
>pw-bot: cr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://st-md-mailman.stormreply.com/pipermail/linux-stm32/attachments/20250524/1e9ec89d/attachment.html>


More information about the Linux-stm32 mailing list