From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4E471DE3B5; Thu, 29 Jan 2026 13:19:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769692781; cv=none; b=RBSEWh6uQJOUjgxMF4ucz0PvcqXLp73HnTg7DP9drCXimegdGXt2B3HBmlVPNRmOtyc+JWWw5Du9StueWpgq3Hm2VVKmXM5YqsjisgYqFArvAccsXZ4j1gNB+ZP5kNATQ91kHE8aiR5Jm730nalQSiucOF30xFkjvLbUN06giGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769692781; c=relaxed/simple; bh=E2uMmgiv8SXGd/De7T+FDhdr2ix6kp+Q1oN/jBcOCYE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kIy9jc2XeMTTvyhpqpJ5ydNdpdLV/cQ5HhKsS4keGGW5Pt2nG2SnlDMKfCd6atPcqr5s1kjsL/4dvLRwMnn9v83UkiXc3VI1HxHQtEOhkk8hxTBQT98HAW+nkqLIA8BqD0rpBLV1HptczbgHwT57nxyFscz2NDhDABzGHyuDLaI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=TrPIEcx+; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="TrPIEcx+" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=35RcmUOfMYcS5hqrNe+DIOwfSJkxRE1Iu6eQEiQMdMo=; b=TrPIEcx+Y1pqZdIOsV2XjEUn35 v6929udjMSbly9nPU9+mtcdo6HMKgrBinvgI/lYFrtHALtC46txAmvmozGz0Iwlwzct7LZEsYl6AW nbUQYSaQNe1PgaxlSCiUcsBOASDsSQ+uuyDcDUUy9G9irz1ONciaGmCojjcUM+ACEYN6OMFPbufdq Zaf3x7Zp+F/+va2mqOpNQnnCsFFFSEJBaZ0CGzdHQttrNWHHpsBZ1IQscCtXUqKawuzctpq3g+/UG T2r46S9b5Jvstz6WcEJOOQrsMbMMsMWI8/7+tW/BNNJ16RO2nAdaKIjfQRkYWsMc3askZu47IoTI0 /NYB+1NQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43902) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vlRvl-0000000006U-3bPv; Thu, 29 Jan 2026 13:19:29 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1vlRvk-0000000080g-0XMi; Thu, 29 Jan 2026 13:19:28 +0000 Date: Thu, 29 Jan 2026 13:19:27 +0000 From: "Russell King (Oracle)" To: Marco Felsch Cc: Michael Nazzareno Trimarchi , Andrew Lunn , Wei Fang , Shenwei Wang , Clark Wang , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , "open list:FREESCALE IMX / MXC FEC DRIVER" , "open list:FREESCALE IMX / MXC FEC DRIVER" , open list Subject: Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init_hw Message-ID: References: <20260128094644.302313-1-michael@amarulasolutions.com> <13d1018c-d9aa-4838-8bb3-35c509cd3e35@lunn.ch> <20260128202634.gqevi76o6wnf5xno@pengutronix.de> <20260129104123.zir4rtgeiu5qv3i7@pengutronix.de> <20260129111726.jjkcq46dpghuorco@pengutronix.de> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) On Thu, Jan 29, 2026 at 01:12:41PM +0000, Russell King (Oracle) wrote: > Another possible solution beyond those I've already stated, given that > this only afflicts the FEC driver, ould be for the FEC MDIO driver to > walk the child nodes, checking to see whether they require any clocks, > and ensuring that those are properly initialised before registering the > MDIO bus. > > Since the MDIO bus layer can release the PHY reset just before probing > the driver, this seems to me to be the only way to guarantee that, > where boot firmware does not deal with this, the PHY manufacturers > specification for the initial release of reset can be met while keeping > this FEC specific behaviour out of the core MDIO/phylib layers. I'll also add... as kernel developers, we're not very good at insisting on generic names for things like clocks (see the mess that is stmmac, where the dwmac's various clock signals are named differently in the many platform glues.) So, I guess that FEC MDIO may need to have a list of clock names to look for when inspecting the PHY nodes if the clock is even specified there. If it isn't, then some other way of discovering that the PHY needs a clock (looking at the pinctrl configuration to see whether the pin is configured to output a clock to the PHY?) would need to be added. However, care needs to be taken in the case where the PHY has already been setup by boot firmware, that the clock signal is not disturbed, as interrupting it could provoke PHY problems - especially if the platform doesn't have the PHY reset specified in DT. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!