netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>, Joakim Zhang <qiangqing.zhang@nxp.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	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
Date: Mon, 24 Jan 2022 00:09:34 +0800	[thread overview]
Message-ID: <Ye19vpFWXR8wJQVH@xhacker> (raw)
In-Reply-To: <Ye19bHxcQ5Plx0v9@xhacker>

On Mon, Jan 24, 2022 at 12:08:22AM +0800, Jisheng Zhang wrote:
> On Sun, Jan 23, 2022 at 04:52:29PM +0100, Andrew Lunn wrote:
> > 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 <jszhang@kernel.org>
> > > ---
> > >  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
> 
> I think this is a common issue because the MAC needs phy's RXC for RX
> logic. But it's better to let other stmmac users verify. The issue
> can easily be reproduced on platforms with PHY_POLL external phy.
> Or other platforms use a dedicated clock rather than clock from phy
> for MAC's RX logic?
> 
> If the issue turns out specific to my system, then I will send out
> a new patch to adopt your suggestion.
>

+ Joakim

> Hi Joakim, IIRC, you have stmmac + external RTL8211F phy platform, but
> I'm not sure whether your platform have an irq for the phy. could you
> help me to check whether you can reproduce the issue on your platform?
> 
> > 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().
> 
> Thanks a lot for the suggestion.

  reply	other threads:[~2022-01-23 16:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-23 14:12 [PATCH] net: stmmac: don't stop RXC during LPI Jisheng Zhang
2022-01-23 15:52 ` Andrew Lunn
2022-01-23 16:08   ` Jisheng Zhang
2022-01-23 16:09     ` Jisheng Zhang [this message]
2022-01-23 18:29       ` Florian Fainelli
2022-01-24  6:25       ` Joakim Zhang
2022-01-23 17:39     ` Andrew Lunn
2022-01-26 12:55       ` Jisheng Zhang
2022-01-26 13:27         ` Russell King (Oracle)
2022-01-26  3:40 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ye19vpFWXR8wJQVH@xhacker \
    --to=jszhang@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=qiangqing.zhang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).