From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 05679C433EF for ; Sun, 23 Jan 2022 16:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Oehpcg8peYsjc3Q4mgpYayVpoczykRvFxuT0p5aK9PA=; b=0vrcn8ms/gGo9U AB+LZlPwCPuzp6mIldD/bydvv85o2CWavaSlSbACjyspgB12tmUb3txZ9GRyhdw3P1T+l5vupkkH5 49q1b/C/iYZAEqp3QQ+aS32NyxLs7tL+OC1Mip0jF/cyokonjW0UGAxIMSWF31BJSlJhPI8tQ/kiA rtxG2qFqREBbYi0n4i3MjRqRxGvE/JuVmcYmjZrXOnwNnPlFrVHC8QFykHHomezmzvIxhIwq3Tqka QQwI1/Bn0e1GBH2TSzCMXRuioK1hWIMpc3QG8SsYd2y4cWrPdaNxG7XRLjjgvAgQ16/bu947hEb1N YebFTAkRskpQYAR2eZIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nBfGe-001EaN-3v; Sun, 23 Jan 2022 15:59:01 +0000 Received: from vps0.lunn.ch ([185.16.172.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nBfAV-001Ce5-KQ for linux-arm-kernel@lists.infradead.org; Sun, 23 Jan 2022 15:52:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=EMC6Ft10JXwi16PGGMWQ1pe3LM0kkBsvwtaXhgSs0wM=; b=EO0tRbP4Cm6mmtzSNEUjPEe+fN gEll1aTSwCLFqWNaKAehFMt6LO3f3TV6EsNHAZGABi4xyxeHb8Tpf+vbNq26LfSK0KL9iDpWUzJZI +kQE8nHGPjqqqISIy1/DC/Yk4uQ+cxG41jqOjV8AQAKzMk3WcnoirV20gNJSx7do3ELU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nBfAL-002OLT-JC; Sun, 23 Jan 2022 16:52:29 +0100 Date: Sun, 23 Jan 2022 16:52:29 +0100 From: Andrew Lunn To: Jisheng Zhang Cc: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S . Miller" , Jakub Kicinski , Maxime Coquelin , netdev@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: stmmac: don't stop RXC during LPI Message-ID: References: <20220123141245.1060-1-jszhang@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220123141245.1060-1-jszhang@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220123_075239_749246_7CFB77B9 X-CRM114-Status: GOOD ( 25.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Jan 23, 2022 at 10:12:45PM +0800, Jisheng Zhang wrote: > I met can't receive rx pkt issue with below steps: > 0.plug in ethernet cable then boot normal and get ip from dhcp server > 1.quickly hotplug out then hotplug in the ethernet cable > 2.trigger the dhcp client to renew lease > > tcpdump shows that the request tx pkt is sent out successfully, > but the mac can't receive the rx pkt. > > The issue can easily be reproduced on platforms with PHY_POLL external > phy. If we don't allow the phy to stop the RXC during LPI, the issue > is gone. I think it's unsafe to stop the RXC during LPI because the mac > needs RXC clock to support RX logic. > > And the 2nd param clk_stop_enable of phy_init_eee() is a bool, so use > false instead of 0. > > Signed-off-by: Jisheng Zhang > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index 6708ca2aa4f7..92a9b0b226b1 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -1162,7 +1162,7 @@ static void stmmac_mac_link_up(struct phylink_config *config, > > stmmac_mac_set(priv, priv->ioaddr, true); > if (phy && priv->dma_cap.eee) { > - priv->eee_active = phy_init_eee(phy, 1) >= 0; > + priv->eee_active = phy_init_eee(phy, false) >= 0; This has not caused issues in the past. So i'm wondering if this is somehow specific to your system? Does everybody else use a PHY which does not implement this bit? Does your synthesis of the stmmac have a different clock tree? By changing this value for every instance of the stmmac, you are potentially causing a power regression for stmmac implementations which don't need the clock. So we need a clear understanding, stopping the clock is wrong in general and so the change is correct in general. Or this is specific to your system, and you probably need to add priv->dma_cap.keep_rx_clock_ticking, which you set in your glue driver,and use here to decide what to pass to phy_init_eee(). Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel