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 539D214EC46; Mon, 21 Apr 2025 19:52:11 +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=1745265133; cv=none; b=bcIW2SpLEWRBHphJIdi5vBHFPfqcOz3Twkp27IW01CmX0PhWLL3nGnke8dqcHXCLKUQVI7Pscp1yzqedg/i0FpglBnNvA27SOyh7Tkxnk07KI9XU+lvYDQ/vJxuKrQQJZaeqARxCmgoHkM9GuC2TJgIFPWX09c74SMnsWbeHgFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745265133; c=relaxed/simple; bh=u6safFetNv4QEP0r9Iz/YmPmNAmPjrfsQtubWT4us/Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ODBvd+IFbjMoK94e/BwryM5HOaY2SOKISZtyMUM9Y+moOaBHDhvgK8DBONcWVU3qxQvcaTcUuRuBfUqNUcNwCnGMmU4Afexo5JrbiMBb+NdTnMvvIXn8DDhktJzrs6kjoLnwN5V4MLqcqh7G55mGCk9mjOk037/nT2z+7i2TyNM= 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=JKafrj3O; 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="JKafrj3O" 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=CoIXiOR5N4qvjIOVDMGoDjq4P3o+Q3XWknsTh3hugIQ=; b=JKafrj3OLsnuxsHw+VFNxH82yA TM2jheskPpBoFDY5/xp844xNRSPBxUT1UGoyCTP5TwbV50UiGTJoK6lWRZrqdjNdoqXDGgITcN5gz vevJR9DnBmIsQrgPVjts1CpRpFMUhXxVZckI8feZJxMwsbYilm0Ksuqec755JzCtDTN6asu9iFr2Q PdBYFesIWfaFrffZQqHMsx0HpE3KWeG17VDrJf0RgoktrUf9s+UbZbKo1llLg6z7M12lX+ePK85mi s4UG2UfzOixSH0XOn4K0rRPUZHUXVrlngVhCvsSzLcxzoCNYk0WdDmw5QponUsuyMPUM7lUqY0n8O quYz+Yug==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:55886) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u6xBH-0003Je-1s; Mon, 21 Apr 2025 20:51:52 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1u6xBC-0006js-0V; Mon, 21 Apr 2025 20:51:46 +0100 Date: Mon, 21 Apr 2025 20:51:46 +0100 From: "Russell King (Oracle)" To: Biju Das Cc: "Lad, Prabhakar" , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maxime Coquelin , Alexandre Torgue , Richard Cochran , Philipp Zabel , Geert Uytterhoeven , Magnus Damm , Giuseppe Cavallaro , Jose Abreu , "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-renesas-soc@vger.kernel.org" , Fabrizio Castro , Prabhakar Mahadev Lad Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH Message-ID: References: <20250407120317.127056-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20250407120317.127056-4-prabhakar.mahadev-lad.rj@bp.renesas.com> Precedence: bulk X-Mailing-List: devicetree@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 Mon, Apr 21, 2025 at 07:23:52PM +0000, Biju Das wrote: > Hi Russell, > > > -----Original Message----- > > From: Biju Das > > Sent: 21 April 2025 20:06 > > Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH > > > > Hi Russell, > > > > > -----Original Message----- > > > From: Russell King > > > Sent: 21 April 2025 20:00 > > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer > > > for Renesas GBETH > > > > > > On Mon, Apr 21, 2025 at 01:45:50PM +0000, Biju Das wrote: > > > > Hi All, > > > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY. > > > > > > Which "mainline" are you using? > > > > > > Reading your emails, I suspect v6.14 rather than something post-dating > > > v6.15-rc1, since your latest email suggests that the PHY driver's > > > ->resume method is not being called early in stmmac's resume. However, > > > commits 367f1854d442 and ef43e5132895 made this happen, which were > > > merged during the merge window, and are thus in v6.15-rc1. > > > > I am using Linux version 6.15.0-rc2-next-20250417 + renesas_defconfig with CONFIG_PROVE_LOCKING > > enabled. > > For me, it looks like issue related to timing, see[1] for details > > [1] https://lore.kernel.org/all/TY3PR01MB1134690619EC6CADD07CD2DE186B82@TY3PR01MB11346.jpnprd01.prod.outlook.com/ > > Please let me know, if you have any patch that I can try out to fix the random timing issue. That's the email that provoked me to reply this evening (I wouldn't have because I'm still on vacation.) So, this is how things are supposed to be working: - stmmac_phy_setup() sets phylink_config.mac_managed_pm and phylink_config.mac_requires_rxc to be true. The former disables phylib based power management. - You've hooked in stmmac_pltfr_pm_ops. - On resume, this will call stmmac_pltfr_resume(). - stmmac_pltfr_resume() will call your ->init function followed by stmmac_resume(). - stmmac_resume() will call phylink_prepare_resume(). - phylink_prepare_resume() will call phy_resume() to resume the PHY if pl->config->mac_requires_rxc && phydev && phydev->suspended is true. The first and second will be true. The third... depends. For phydev->suspended to be true, phy_suspend() needs to have been called. Neither mdio_bus_phy_suspend() nor mdio_bus_phy_resume() should be having any effect as phydev->mac_managed_pm should be set (as a result of phylink_config.mac_managed_pm having been set.) phy_suspend() also gets called from phy_detach() and _phy_state_machine_post_work() when the work is PHY_STATE_WORK_SUSPEND. This happens when we halt the PHY, which will happen if phy_stop() is called. phylink_suspend() will do this only when WoL is not active - calling it when WoL is active will prevent WoL from working as the PHY needs to stay awake to (1) detect WoL packets if it is programmed to do so, or (2) pass packets to the MAC in the case where the MAC is doing WoL. So, phy_resume() should be getting called for the !WoL case, which will result in the PHY driver's ->resume method being called - in your case kszphy_resume(). This will occur synchronously, and after gbeth's ->init function has been called, and as its all in the same thread of execution, it should be 100% reliable. For the WoL case, we assume that the PHY retains its settings since it needs to remain powered up, and because it hasn't been suspended or shutdown, it should be retaining all settings when the system wakes up. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!