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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
