From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks Date: Mon, 22 Oct 2018 10:13:35 -0700 Message-ID: References: <20181022122839.GB24112@lunn.ch> <8114f345-0efb-9a64-b867-2cfe2fba09ab@synopsys.com> <20181022154851.GA1492@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Andrew Lunn , netdev@vger.kernel.org, "David S. Miller" , Joao Pinto To: Russell King - ARM Linux , Jose Abreu Return-path: Received: from mail-wm1-f67.google.com ([209.85.128.67]:34038 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727218AbeJWBdL (ORCPT ); Mon, 22 Oct 2018 21:33:11 -0400 Received: by mail-wm1-f67.google.com with SMTP id z25-v6so9692688wmf.1 for ; Mon, 22 Oct 2018 10:13:48 -0700 (PDT) In-Reply-To: <20181022154851.GA1492@n2100.armlinux.org.uk> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/22/18 8:48 AM, Russell King - ARM Linux wrote: > On Mon, Oct 22, 2018 at 01:47:48PM +0100, Jose Abreu wrote: >> Hello, >> >> On 22-10-2018 13:28, Andrew Lunn wrote: >>>> EXPORT_SYMBOL_GPL(gen10g_resume); >>>> @@ -327,7 +381,7 @@ struct phy_driver genphy_10g_driver = { >>>> .phy_id = 0xffffffff, >>>> .phy_id_mask = 0xffffffff, >>>> .name = "Generic 10G PHY", >>>> - .soft_reset = gen10g_no_soft_reset, >>>> + .soft_reset = gen10g_soft_reset, >>>> .config_init = gen10g_config_init, >>>> .features = 0, >>>> .aneg_done = genphy_c45_aneg_done, >>> Hi Jose >>> >>> You need to be careful here. There is a reason this is called >>> gen10g_no_soft_reset, rather than having an empty >>> gen10g_soft_reset. Some PHYs break when you do a reset. So adding a >>> gen10g_soft_reset is fine, but don't change this here, without first >>> understanding the history, and talking to Russell King. >> >> Hmm, the reset function only interacts with standard PCS >> registers, which should always be available ... >> >> >From my tests I need to do at least 1 reset during power-up so in >> ultimate case I can add a feature quirk or similar. >> >> Russell, can you please comment ? > > Setting the reset bit on 88x3310 causes the entire device to become > completely inaccessible until hardware reset. Therefore, this bit > must _never_ be set for these devices. That said, we have a separate > driver for these PHYs, but that will only be used for them if it's > present in the kernel. If we accidentally fall back to the generic > driver, then we'll screw the 88x3310 until a full hardware reset. > > We also have a bunch of net devices that make use of this crippled > "generic" 10G support - we don't know whether resetting the PHY > for those systems will cause a regression - maybe board firmware > already configured the PHY? I can't say either way on that, except > that we've had crippled 10G support in PHYLIB for a number of years > now _with_ users, and adding reset support drastically changes the > subsystem's behaviour for these users. > > I would recommend not touching the generic 10G driver, but instead > implement your own driver for your PHY to avoid causing regressions. > Agreed. -- Florian