Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option

[Richard Leitner <richard.leitner@skidata.com>]

On 07/07/2017 04:00 PM, Andrew Lunn wrote:
>> Ok. I'm fine with moving the phy-reset-gpios binding into the PHY.
>> But one question still remains: Who should then trigger the "hard
>> reset" of the PHY?
> 
> Hi Richard
> 
> I think i see a few whys to do this, but first i need to check
> something. Is the clock which is causing a problem this one:
> 
>         /* clk_ref is optional, depends on board */
>         fep->clk_ref = devm_clk_get(&pdev->dev, "enet_clk_ref");
>         if (IS_ERR(fep->clk_ref))
>                 fep->clk_ref = NULL;

Yes. It's this one.

> 
> Possible solutions:
> 
> 1) clocks are referenced counted. If it is turned on twice, it needs
>    to be turned off twice before it is actually turned off. So, make
>    the PHY driver also clk_prepare_enable() this clock. When the FEC
>    tries to turn it off, it will stay ticking. Problem avoided, at the
>    expense of some power.

Somehow this approach triggers a "workaround-feeling" for me...
Furthermore as you say it "wastes" (at least some) power. For exactly
this reason the disabling of the clock was implemented in commit
e8fcfcd5684a ("net: fec: optimize the clock management to save power").

> 
> 2) More complex, but make the PHY driver also a clock driver. Have the
>    PHY driver export a clock which the FEC use, as "enet_clk_ref". The
>    implementation of this clock, would both turn the real clock on,
>    and the perform the reset.

This seems as a good solution to me. Furthermore IMHO it would be good
to move all PHY related dt bindings (reset-gpio, clk, etc.) from the MAC
into the PHY node.

Or are there any reasons/arguments against this approach?

> 
> Both require no changes to the FEC, or any other MAC driver using this
> PHY, so long as the MAC driver uses the common clock infrastructure to
> control the clock to the PHY.
As (IMHO) the new approach likely won't be backported to stable releases
I want to stress again the point that commit e8fcfcd5684a
("net: fec: optimize the clock management to save power") introduced
this problem and therefore "broke the PHY" for our board.

So would it be possible to add a "quick" bugfix patch (maybe this patch
or another one removing the clk disable) so this fix can be backported
to stable? Otherwise our board is only working with another
"out-of-tree" patch (which I want to avoid)...

kind regards,
Richard.L