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 BE5C630EF94; Thu, 18 Sep 2025 15:37:07 +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=1758209829; cv=none; b=A8Ryp5RKZYB4sJfTfJsZIe23WfROmKt/Qaodz0a8K2tkcdkyvPWBJeF4mqyeXBrYYCV3e6q6DbdgNu6d46AY/69ypUuNsTwRqDlrw54cs9DONE7O3iJxAr3FJgP3799D5GAFOOg+Es/AKjKnIvmAHDX7eShntqlLvAPuTpzgEKk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758209829; c=relaxed/simple; bh=AjBGs66bwYcRT0DYbNaapwReZ4uUeTrPz4K6vm2LwC8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KSNv7AZb3STm8W4vgNoEDF3gTJyv83062FBDlSFq+ZsVyV2+2UEixvAKZMPX7UKY6OUe8P1K2b/lkXYg27/xSEkYHtivKU5Neyq+FUsCRSeQnsKIGT3T23IAB93fPbG3kRVDZy9W7CFtRf2To3qNbZzF3u1jnHIziHRIb8UVbHg= 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=F7JJb73T; 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="F7JJb73T" 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=aM9defDUbxftG1qhQP/TtclfqCxbcheJJLtqcFMRzU4=; b=F7JJb73THAOqRK1K8GFdiT/8Ej gj9W1dfgE4nWfaTkdI63AdaKD9zzZMlzAxOzu/aVmbYNPPczfMsbitvrzmw7CZnzqz/C9q3imUOni DrjmmEfLd4yPeTmSp8UTMZiFZhZVOCF/DbW5nbpr95AdhrtzhSqzme+mDJkXUlfUxPsOgtLSizXEI aKmM1UInF0ZFJyDXT4Q/TiHrZbxO+8cSKNzxhzXu4mZcNN4QEbc2pAfsUEqW1Dfh8v32Pv/wPfA9I 6e+qoV4lDUliCYjwrwt3A8JGGBM4o8WYYgFiQYMG0kH0PY/hQ7LWOjWw3XYtpBs06bmGxtzkqmwLx q1UygtCQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43486) 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 1uzGgg-000000001BG-1j6Y; Thu, 18 Sep 2025 16:36:46 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1uzGgc-000000001Hk-0d9w; Thu, 18 Sep 2025 16:36:42 +0100 Date: Thu, 18 Sep 2025 16:36:41 +0100 From: "Russell King (Oracle)" To: Gatien CHEVALLIER Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maxime Coquelin , Alexandre Torgue , Christophe Roullier , Andrew Lunn , Heiner Kallweit , Simon Horman , Tristram Ha , Florian Fainelli , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 2/4] net: stmmac: stm32: add WoL from PHY support Message-ID: References: <20250917-wol-smsc-phy-v2-0-105f5eb89b7f@foss.st.com> <20250917-wol-smsc-phy-v2-2-105f5eb89b7f@foss.st.com> <72ad4e2d-42fa-41c2-960d-c0e7ea80c6ff@foss.st.com> <64b32996-9862-4716-8d14-16c80c4a2b10@foss.st.com> 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: <64b32996-9862-4716-8d14-16c80c4a2b10@foss.st.com> Sender: Russell King (Oracle) On Thu, Sep 18, 2025 at 05:07:00PM +0200, Gatien CHEVALLIER wrote: > On 9/18/25 15:59, Russell King (Oracle) wrote: > > > So no. In a situation like this, either we want to be in interrupt > > mode (in which case we have an interrupt), or the pin is wired to > > a power management controller and needs to be in PME mode, or it isn't > > wired. > > > > If you are in interrupt mode, plugging a cable would trigger a > system wakeup in low-power mode if the INTB/PMEB line is wired to a > power management controller and the WoL is enabled because we're no > longer in polling mode, wouldn't it? What Andrew suggested, which is what I implemented for Realtek, other interrupts get disabled when we enter suspend: static int rtl8211f_suspend(struct phy_device *phydev) { ... /* If a PME event is enabled, then configure the interrupt for * PME events only, disabling link interrupt. We avoid switching * to PMEB mode as we don't have a status bit for that. */ if (device_may_wakeup(&phydev->mdio.dev)) { ret = phy_write_paged(phydev, 0xa42, RTL821x_INER, RTL8211F_INER_PME); This disables all other interrupts when entering suspend _if_ WoL is enabled and only if WoL is enabled. If you're getting woken up when you unplug/replug the ethernet cable when WoL is disabled, that suggests you have something wrong in your interrupt controller - the wake-up state of the interrupt is managed by core driver-model code. I tested this on nVidia Jetson Xavier NX and if WoL wasn't enabled at the PHY, no wakeup occurred. > You can argue that as per the Realtek 8211F datasheet: > "The interrupts can be individually enabled or disabled by setting or > clearing bits in the interrupt enable register INER". That requires > PHY registers handling when going to low-power mode. ... which is what my patch does. > There are PHYs like the LAN8742 on which 3 pins can be configured > as nINT(equivalent to INTB), and 2 as nPME(equivalent to PMEB). The > smsc driver, as is, contains hardcoded nPME mode on the > LED2/nINT/nPME/nINTSEL pin. What if a manufacturer wired the power > management controller to the LED1/nINT/nPME/nINTSEL? > This is where the pinctrl would help even if I do agree it might be a > bit tedious at first. The pinctrl would be optional though. I'm not opposing the idea of pinctrl on PHYs. I'm opposing the idea of tying it into the WoL code in a way that makes it mandatory. Of course, if it makes sense for a PHY driver to do pinctrl stuff then go ahead - and if from that, the driver can work out that the PHY is wake-up capable, even better. What I was trying to say is that in such a case as the Realtek driver, I don't want to see pinctrl forced upon it unless there is a real reason and benefit, especially when there are simpler ways to do this. I also think that it would be helpful to add the wakeup-source property where PHYs are so capable even if the PHY driver doesn't need it for two reasons. 1. OS independence. 2. it's useful docs. 3. just because our driver as it stands at whatever moment in time doesn't make use of it doesn't mean that will always be the case. (e.g., we may want to have e.g. phylib looking at that property.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!