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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Jul 2017 11:21:06 +0200
From:   Richard Leitner <richard.leitner@...data.com>
To:     Andrew Lunn <andrew@...n.ch>, Andy Duan <fugang.duan@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
CC:     "mark.rutland@....com" <mark.rutland@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dev@...l1n.net" <dev@...l1n.net>,
        Richard Leitner <richard.leitner@...data.com>
Subject: Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable
 option


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