On 22/07/15 16:52, Petri Gynther wrote:
> On Wed, Jul 22, 2015 at 3:11 PM, Florian Fainelli <f.faine...@gmail.com> 
> wrote:
>>
>> Instead of multiplying the number of checks for IS_ERR(priv->clk),
>> simply NULLify the 'struct clk' pointer which is something the Linux
>> common clock framework perfectly deals with and does early return for
>> each and every single clk_* API functions.
>>
>> Having every single function check for !IS_ERR(priv->clk) is both
>> redundant and error prone, as it turns out, we were doing it for the
>> main GENET clock: priv->clk, but not for the Wake-on-LAN or EEE clock,
>> so let's just be consistent here.
>>
>> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
>> ---
>>  drivers/net/ethernet/broadcom/genet/bcmgenet.c | 20 ++++++++++----------
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index 5bf7ce0ae221..133bb10fdd34 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> @@ -2625,8 +2625,7 @@ static int bcmgenet_open(struct net_device *dev)
>>         netif_dbg(priv, ifup, dev, "bcmgenet_open\n");
>>
>>         /* Turn on the clock */
>> -       if (!IS_ERR(priv->clk))
>> -               clk_prepare_enable(priv->clk);
>> +       clk_prepare_enable(priv->clk);
>>
>>         /* If this is an internal GPHY, power it back on now, before UniMAC 
>> is
>>          * brought out of reset as absolutely no UniMAC activity is allowed
>> @@ -2703,8 +2702,7 @@ err_irq0:
>>  err_fini_dma:
>>         bcmgenet_fini_dma(priv);
>>  err_clk_disable:
>> -       if (!IS_ERR(priv->clk))
>> -               clk_disable_unprepare(priv->clk);
>> +       clk_disable_unprepare(priv->clk);
>>         return ret;
>>  }
>>
>> @@ -2761,8 +2759,7 @@ static int bcmgenet_close(struct net_device *dev)
>>         if (priv->internal_phy)
>>                 ret = bcmgenet_power_down(priv, GENET_POWER_PASSIVE);
>>
>> -       if (!IS_ERR(priv->clk))
>> -               clk_disable_unprepare(priv->clk);
>> +       clk_disable_unprepare(priv->clk);
>>
>>         return ret;
>>  }
>> @@ -3215,11 +3212,12 @@ static int bcmgenet_probe(struct platform_device 
>> *pdev)
>>                 priv->version = pd->genet_version;
>>
>>         priv->clk = devm_clk_get(&priv->pdev->dev, "enet");
>> -       if (IS_ERR(priv->clk))
>> +       if (IS_ERR(priv->clk)) {
>>                 dev_warn(&priv->pdev->dev, "failed to get enet clock\n");
>> +               priv->clk = NULL;
>> +       }
> 
> Wouldn't the above be a fatal error? If you can't get the enet main
> clock, any point to go further in this code?

No, you could have a system with no clock provider at all because:

- you purposely disabled your clock driver
- you removed clock phandles from e.g: Device Tree

but your HW might still be turned on by default and this would be by design.

> 
>>
>> -       if (!IS_ERR(priv->clk))
>> -               clk_prepare_enable(priv->clk);
>> +       clk_prepare_enable(priv->clk);
>>
>>         bcmgenet_set_hw_params(priv);
>>
>> @@ -3230,8 +3228,10 @@ static int bcmgenet_probe(struct platform_device 
>> *pdev)
>>         INIT_WORK(&priv->bcmgenet_irq_work, bcmgenet_irq_task);
>>
>>         priv->clk_wol = devm_clk_get(&priv->pdev->dev, "enet-wol");
>> -       if (IS_ERR(priv->clk_wol))
>> +       if (IS_ERR(priv->clk_wol)) {
>>                 dev_warn(&priv->pdev->dev, "failed to get enet-wol clock\n");
>> +               priv->clk_wol = NULL;
>> +       }
>>
>>         priv->clk_eee = devm_clk_get(&priv->pdev->dev, "enet-eee");
>>         if (IS_ERR(priv->clk_eee)) {
>> --
>> 2.1.0
>>
> 
> Looking at the rest of the code in bcmgenet_probe(), I still see:
>         /* Turn off the main clock, WOL clock is handled separately */
>         if (!IS_ERR(priv->clk))
>                 clk_disable_unprepare(priv->clk);
> 
> err_clk_disable:
>         if (!IS_ERR(priv->clk))
>                 clk_disable_unprepare(priv->clk);
> 
> you probably want to convert those as well, right?

Yes, thanks for catching these.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to