From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 8FDBA1E51F for ; Thu, 10 Aug 2023 10:02:00 +0000 (UTC) Received: from pandora.armlinux.org.uk (unknown [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACD4F3C3B for ; Thu, 10 Aug 2023 03:01:59 -0700 (PDT) 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=gF7i5HM+zGdPrfl8tdSW5v/khHwK6WWq7/y9FHzMH6I=; b=dTXrjUWRhNybUaxoHW/6kjEczm w43bf3xX2CZK6zg8g9sXQF8/vxxYBVrCvKq9R+kNM6b/G/3I2BDTKiD/ObD+QwJMygqbEOKH2Jl6B DhoY239E39allcvF/wfpbIZxYZah3EFBqd5m9NHl/QKmoQIZSgGst/Eg64M4UJc3/cGbkxQhcgHAa lGwU5AzjgcxT+Dp9ZFoNnzBp6Rgc43G6EPa+d9BU834tnz3c2PfImf+eWZ+V7fyVvUxfJpiZwT+jY M2+I/rtWtfg02iGUhyampqjjb0o0YXsm9aYosvy0TM25anzlCGXl/On2/cyBHScZxVyqIbbL/wnSb 1UX968zQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:54166) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qU2UN-0003mm-05; Thu, 10 Aug 2023 11:01:55 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qU2UL-0001fg-Fm; Thu, 10 Aug 2023 11:01:53 +0100 Date: Thu, 10 Aug 2023 11:01:53 +0100 From: "Russell King (Oracle)" To: Marek Vasut Cc: Andrew Lunn , Wei Fang , Oleksij Rempel , "netdev@vger.kernel.org" , "David S. Miller" , Eric Dumazet , Heiner Kallweit , Jakub Kicinski , Oleksij Rempel , Paolo Abeni Subject: Re: [PATCH] net: phy: at803x: Improve hibernation support on start up Message-ID: References: <20230804175842.209537-1-marex@denx.de> <45b1ee70-8330-0b18-2de1-c94ddd35d817@denx.de> <20230809043626.GG5736@pengutronix.de> <76131561-18d7-945e-cb52-3c96ed208638@denx.de> <18601814-68f6-4597-9d88-a1b4b69ad34f@lunn.ch> <36ee0fa9-040a-8f7e-0447-eb3704ab8e11@denx.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: <36ee0fa9-040a-8f7e-0447-eb3704ab8e11@denx.de> Sender: Russell King (Oracle) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,RDNS_NONE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Thu, Aug 10, 2023 at 02:49:55AM +0200, Marek Vasut wrote: > On 8/10/23 00:06, Andrew Lunn wrote: > > On Wed, Aug 09, 2023 at 11:34:19PM +0200, Marek Vasut wrote: > > > On 8/9/23 15:40, Andrew Lunn wrote: > > > > > > Hm.. how about officially defining this PHY as the clock provider and disable > > > > > > PHY automatic hibernation as long as clock is acquired? > > > > > > > > > > > Sorry, I don't know much about the clock provider/consumer, but I think there > > > > > will be more changes if we use clock provider/consume mechanism. > > > > > > > > Less changes is not always best. What happens when a different PHY is > > > > used? > > > > > > Then the system wouldn't be affected by this AR803x specific behavior. > > > > Do you know it really is specific to the AR803x? Turning the clock off > > seams a reasonable thing to do when saving power, or when there is no > > link partner. > > This hibernation behavior seem specific to this PHY, I haven't seen it on > another PHY connected to the EQoS so far. Marvell PHYs can be programmed so that RXCLK stops when the PHY enters power down or energy-detect state, although it defaults to always keeping the RGMII interface powered (and thus providing a clock.) One Micrel PHY - "To save more power, the KSZ9031RNX stops the RX_CLK clock output to the MAC after 10 or more RX_CLK clock cycles have occurred in the receive LPI state." which seems to imply if EEE is enabled, then the receive clock will be stopped when entering low-power state. I've said this several times in this thread - I think we need a bit in the PHY device's dev_flags to allow the MAC to say "do not power down the receive clock" which is used by the PHY drivers to (a) program the hardware to prevent the receive clock being stopped in situations such as the AR803x hibernate mode, and (b) to program the hardware not to stop the receive clock when entering EEE low power. This does seem to be a generic thing and not specific to just one PHY - especially as the stopping of clocks when entering EEE low power is a IEEE 802.3 defined thing. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!