Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752588AbdGGOAo (ORCPT ); Fri, 7 Jul 2017 10:00:44 -0400 Received: from vps0.lunn.ch ([178.209.37.122]:47771 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbdGGOAP (ORCPT ); Fri, 7 Jul 2017 10:00:15 -0400 Date: Fri, 7 Jul 2017 16:00:10 +0200 From: Andrew Lunn To: Richard Leitner Cc: Andy Duan , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dev@g0hl1n.net" Subject: Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Message-ID: <20170707140010.GD24237@lunn.ch> References: <1499346330-12166-1-git-send-email-richard.leitner@skidata.com> <1499346330-12166-2-git-send-email-richard.leitner@skidata.com> <81105c77-d48f-271b-2de1-c877b9413184@skidata.com> <6de114cb-4521-4bb2-d0a3-4aea32936bd3@skidata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1237 Lines: 35 > 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; 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. 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. 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. Andrew