Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbdGGJxG (ORCPT ); Fri, 7 Jul 2017 05:53:06 -0400 Received: from mail2.skidata.com ([91.230.2.91]:33323 "EHLO mail2.skidata.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750848AbdGGJxE (ORCPT ); Fri, 7 Jul 2017 05:53:04 -0400 X-IronPort-AV: E=Sophos;i="5.40,322,1496095200"; d="scan'208";a="761628" Subject: Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option To: Andy Duan , "robh+dt@kernel.org" , "mark.rutland@arm.com" 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> CC: "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dev@g0hl1n.net" , Andrew Lunn From: Richard Leitner Message-ID: <6de114cb-4521-4bb2-d0a3-4aea32936bd3@skidata.com> Date: Fri, 7 Jul 2017 11:52:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.24.42] X-ClientProxiedBy: sdex1srv.skidata.net (172.16.10.92) To sdex1srv.skidata.net (172.16.10.92) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1662 Lines: 47 On 07/07/2017 09:03 AM, Andy Duan wrote: > From: Richard Leitner Sent: Friday, July 07, 2017 1:51 PM >>> Since it is common issue so long as using the PHY, can you move it into smsc >> phy driver like in .smsc_phy_reset() function ? >>> And get the reset pin from phy dts node. >> >> Some more points that come into my mind: >> - The smsc_phy_reset function is registered as "soft_reset". Would it be OK to >> use nRST in it? > > It is not reasonable. > >> - Would it be OK to call the phy_init_hw function from within the >> smsc_phy_reset? > > No, phy_init_hw() already call .drv->soft_reset(). > >> - IMHO I'd have to move the reset gpio binding inside the phy node then. Isn't >> that a pretty big change doing that for all PHYs/FECs? Would it be "worth" it? >> > To make the change to be common, there have big change for phy driver. > Maybe somebody can give one good suggestion/solution for it. Sorry, I don't think I understood everything correctly: 1. The "phy-reset-gpios" binding should go inside the phy node. This will cause to *change ALL FEC and PHY drivers*. Correct? 2. Add an additonal "hard reset" function to the PHY driver which handles the "phy-reset-gpios". Correct? 3. Who should then trigger the "hard reset" of the PHY? phy_init_hw? The FEC? The point is that the LAN8710 is currently not always working correctly, therefore this small change was proposed. Should we really change all PHY/FECs only because of this? Furthermore one problem still remains: The enet_refclk is controlled by the FEC. How does the PHY recognize when it was disabled/enabled? > > Andy > kind regards, Richard.L