Received: by 10.223.164.202 with SMTP id h10csp3773278wrb; Mon, 20 Nov 2017 04:56:07 -0800 (PST) X-Google-Smtp-Source: AGs4zMYSc+KySqoGZeRqK7RyLxCutNxMoOWFhGoZZwHg6OTcLk/Xgjv/ilWRjeV5QBcfEBWNJNVx X-Received: by 10.84.163.75 with SMTP id n11mr13801998plg.287.1511182567155; Mon, 20 Nov 2017 04:56:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511182567; cv=none; d=google.com; s=arc-20160816; b=HT1Qf2N2eAKgUI4K3YSpZqZaFUOquBY5PMCsDXUHC0XSs1l5oNliyniMIlhg2GNtV3 lx7hZLqKE3Aqm4dFurvjSMMwe8RMB7TTqY2CTxM2zVTHxoOvVDtPCBJQEDHAM+zMBvfi a9G5s7O3hRE/O+uOqmrPdwVSlwPXY5vkPC28GRDh6Y/JiztT+CNRcPwqwcGP9fZum/ab SXxOBWRD0CzSbGWiiiK/L2w4W0gROSfTBKWh62A12hThcCmg8YOfoUmjnxeka+sxBTtP rX/CD5fw4tCn00wHh0+AVLlOcXlGoE+41MVmj+8EN3AOIaHGs3ZO0rFSuGCID23rF9it y1tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=TpA1zNPp+TvH7QD1REvA2Xp9ZjfbKyTY8JieehOPqn0=; b=DZSTllm6qJMybl0lMXuYhWvnwCtESDaUFlLjmZ6epbWSzPIlwT7cYshJWsE+UZiSUr A9fs5ny4v9G654mM3WOJmwgV3WOmbWajQbxDU96kceJFvFw9QvWsRZG8ukl3SCEFhRj7 Zj36Yu40NBBdaY3vx5WFAT6jsDzqWnfpzTlWoRyJl4/RqR6/OMA2aZDYAPD4eNE5hFiZ R/mSh2/1G1EqQMGGcTfJjnoC+Ja+0wBagfMBZSPxMwSaU9IPdHcp6BOcQgjbQBAqVaGg oVyZH96qt352ZHXjiKRfJZtcqSEjhYiwojRthXLeWSdaNAk5xNPbHXQNv9VP1Y12nzfp 3PbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m8si6441066plt.65.2017.11.20.04.55.56; Mon, 20 Nov 2017 04:56:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751194AbdKTMzT (ORCPT + 67 others); Mon, 20 Nov 2017 07:55:19 -0500 Received: from mail2.skidata.com ([91.230.2.91]:48805 "EHLO mail2.skidata.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751073AbdKTMzR (ORCPT ); Mon, 20 Nov 2017 07:55:17 -0500 X-IronPort-AV: E=Sophos;i="5.44,426,1505772000"; d="scan'208";a="1111422" Subject: Re: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20 To: Andy Duan , "f.fainelli@gmail.com" , "andrew@lunn.ch" CC: Richard Leitner , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Sergei Shtylyov , Geert Uytterhoeven References: <20171120083417.32558-1-dev@g0hl1n.net> <20171120083417.32558-4-dev@g0hl1n.net> <6cab10d6-8311-f34a-5eb7-ccca3c48a527@skidata.com> From: Richard Leitner Message-ID: <30a94c72-2345-0649-6682-4826d31c3285@skidata.com> Date: Mon, 20 Nov 2017 13:55:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.60.30] X-ClientProxiedBy: sdex1srv.skidata.net (172.16.10.92) To sdex1srv.skidata.net (172.16.10.92) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/20/2017 11:35 AM, Andy Duan wrote: > From: Richard Leitner Sent: Monday, November 20, 2017 5:57 PM >> To: Andy Duan ; f.fainelli@gmail.com; >> andrew@lunn.ch >> Cc: Richard Leitner ; netdev@vger.kernel.org; linux- >> kernel@vger.kernel.org >> Subject: Re: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC >> LAN8710/20 >> >> >> On 11/20/2017 10:47 AM, Andy Duan wrote: >>> From: Richard Leitner Sent: Monday, November 20, 2017 >>> 4:34 PM >>>> To: f.fainelli@gmail.com; Andy Duan ; >>>> andrew@lunn.ch >>>> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; >>>> richard.leitner@skidata.com >>>> Subject: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for >>>> SMSC >>>> LAN8710/20 >>>> >>>> From: Richard Leitner >>>> >>>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow >>>> turning the refclk on and off again during operation (according to their >> datasheet). >>>> Nonetheless exactly this behaviour was introduced for power saving >>>> reasons by commit e8fcfcd5684a ("net: fec: optimize the clock >>>> management to save power"). >>>> Therefore after enabling the refclk we detect if an affected PHY is >>>> attached. If so reset and initialize it again. >> ... >> >>>> +static int fec_enet_clk_ref_enable_reset_phy_quirk(struct net_device >>>> +*ndev) { >>>> + struct phy_device *phy_dev = ndev->phydev; >>>> + u32 real_phy_id; >>>> + int ret; >>>> + >>>> + /* some PHYs need a reset after the refclk was enabled, so we >>>> + * reset them here >>>> + */ >>>> + if (!phy_dev) >>>> + return 0; >>>> + if (!phy_dev->drv) >>>> + return 0; >>>> + real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask; >>>> + switch (real_phy_id) { >>>> + case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */ >>> Don't hard code here... >>> I believe there have many other phys also do such operation, hardcode is >> unacceptable... >>> And these code can be put into phy_device.c as common interface. >> Ok. Thank you for the feedback. >> So it would be fine to hardcode the affected phy_id's in a common function in >> phy_device.c? >> >> >> Another possible solution that came to my mind is to add a flag called >> something like "PHY_RST_AFTER_CLK_EN" to the flags variable in struct >> phy_driver. This flag could then be set in the smsc PHY driver for affected >> PHYs. >> >> Then instead of comparing the phy_id in the MAC driver this flag could be >> checked: >> >> if (phydev->drv->flags & PHY_RST_AFTER_CLK_EN) { >> ret = fec_reset_phy(ndev); >> ... >> } >> >> Would checking the flag be OK in fec_main.c? > Yes, it is better than previous solution. > But add new common API in phy_device.c is much better like: > 1. add a flag called "PHY_RST_AFTER_CLK_EN" to the flags variable in struct phy_driver, all phy driver that need reset can set the flag. OK. > 2. add new common api interface phy_reset_after_clk_enable() in phy_device.c driver OK. But see below... > 3. add reset gpio descriptor for common phy device driver. ... if I understood it correctly the patch called "Teach phylib hard-resetting devices" by Geert and Sergei is exactly doing this: https://patchwork.ozlabs.org/cover/828503/ https://lkml.org/lkml/2017/10/20/166 So I'll implement the phy_reset_after_clk_enable function atop of this patch-set and add a note that my patch-series depends on it. Would that be OK? > 4. then any mac driver can directly call the common interface .phy_reset_after_clk_enable(). Sounds reasonable :-) > > That is only my suggestion, maybe there have better idea. > Thanks. > Thanks for your quick feedback. regards Richard.L From 1584580973820115046@xxx Mon Nov 20 10:36:16 +0000 2017 X-GM-THRID: 1584573446575200827 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread