netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jon Hunter <jonathanh@nvidia.com>,
	Joakim Zhang <qiangqing.zhang@nxp.com>,
	"peppe.cavallaro@st.com" <peppe.cavallaro@st.com>,
	"alexandre.torgue@foss.st.com" <alexandre.torgue@foss.st.com>,
	"joabreu@synopsys.com" <joabreu@synopsys.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
	"andrew@lunn.ch" <andrew@lunn.ch>
Cc: dl-linux-imx <linux-imx@nxp.com>,
	"treding@nvidia.com" <treding@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC net-next] net: stmmac: should not modify RX descriptor when STMMAC resume
Date: Thu, 22 Apr 2021 10:32:32 -0700	[thread overview]
Message-ID: <22bf351b-3f01-db62-8185-7a925f19998e@gmail.com> (raw)
In-Reply-To: <9abe58c4-a788-e07d-f281-847ee5b9fcf3@nvidia.com>



On 4/22/2021 10:00 AM, Jon Hunter wrote:
> 
> On 22/04/2021 17:12, Florian Fainelli wrote:
> 
> ...
> 
>> What does the resumption failure looks like? Does the stmmac driver
>> successfully resume from your suspend state, but there is no network
>> traffic? Do you have a log by any chance?
> 
> The board fails to resume and appears to hang. With regard to the
> original patch I did find that moving the code to re-init the RX buffers
> to before the PHY is enabled did work [0].

You indicated that you are using a Broadcom PHY, which specific PHY are
you using?

I suspect that the stmmac is somehow relying on the PHY to provide its
125MHz RXC clock back to you in order to have its RX logic work correctly.

One difference between using the Broadcom PHY and the Generic PHY
drivers could be whether your Broadcom PHY driver entry has a
.suspend/.resume callback implemented or not.

> 
>> Is power to the Ethernet MAC turned off in this suspend state, in which
>> case could we be missing an essential register programming stage?
> 
> It seems to be more of a sequencing issue rather than a power issue.
> 
> I have also ran 2000 suspend cycles on our Tegra platform without
> Joakim's patch to see how stable suspend is on this platform. I did not
> see any failures in 2000 cycles and so it is not evident to me that the
> problem that Joakim is trying to fix is seen on devices such as Tegra.
> Admittedly, if it is hard to reproduce, then it is possible we have not
> seen it yet.
> 
> Jon
> 
> [0]
> https://lore.kernel.org/netdev/e4864046-e52f-63b6-a490-74c3cd8045f4@nvidia.com/
> 

-- 
Florian

  reply	other threads:[~2021-04-22 17:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 11:59 [RFC net-next] net: stmmac: should not modify RX descriptor when STMMAC resume Joakim Zhang
2021-04-19 15:12 ` Jon Hunter
2021-04-20  1:49   ` Joakim Zhang
2021-04-20 13:33     ` Jon Hunter
2021-04-22  4:53       ` Joakim Zhang
2021-04-22 15:56         ` Jakub Kicinski
2021-04-23 13:48           ` Jon Hunter
2021-05-06  6:33             ` Joakim Zhang
2021-05-07 14:22               ` Jon Hunter
2021-05-08 11:20                 ` Joakim Zhang
2021-05-08 15:42                   ` Florian Fainelli
2021-05-10  2:10                     ` Joakim Zhang
2021-05-17  7:53                       ` Thierry Reding
2021-05-18  7:52                         ` Joakim Zhang
2021-04-22 16:12         ` Florian Fainelli
2021-04-22 17:00           ` Jon Hunter
2021-04-22 17:32             ` Florian Fainelli [this message]
2021-04-22 18:18               ` Jon Hunter
2021-04-22 18:20                 ` Florian Fainelli
2021-04-23 13:46                   ` Jon Hunter
2021-04-23 15:38                     ` Heiner Kallweit
2021-04-23  2:37               ` Joakim Zhang
2021-04-22 16:31 ` Florian Fainelli
2021-04-23  2:17   ` Joakim Zhang

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=22bf351b-3f01-db62-8185-7a925f19998e@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=joabreu@synopsys.com \
    --cc=jonathanh@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=qiangqing.zhang@nxp.com \
    --cc=treding@nvidia.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).