From: John Ernberg <john.ernberg@actia.se>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>,
"Clark Wang" <xiaoning.wang@nxp.com>,
NXP Linux Team <linux-imx@nxp.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] net: fec: Always call fec_restart() in resume path
Date: Wed, 14 Feb 2024 15:49:40 +0000 [thread overview]
Message-ID: <e0641509-e18f-48d6-acba-6b649496782e@actia.se> (raw)
In-Reply-To: <20240214065221.26d71ed0@kernel.org>
On 2/14/24 15:52, Jakub Kicinski wrote:
> On Wed, 14 Feb 2024 08:27:02 +0000 John Ernberg wrote:
>> You are correct, we thought so too at [1], but bisection is really hard
>> because we need a whole bunch of patches on top to even boot the system
>> (imx8qxp specific stuff in the NXP vendor tree that's difficult to
>> rebase), we left it a bit open ended.
>>
>> Over the course of the weekend I lost all confidence in my bisection
>> after being confident for 4-5 days, because the more I thought about it
>> the less it made sense for that commit to be the culprit.
>>
>> I should probably have both followed up on that mail with that, and been
>> clearer here. I apologize for failing that.
>
> Is it perhaps possible that upstream 5.10 also didn't work?
> I'm not saying the change itself is incorrect, indeed there
> is fec_restart() on probe and open paths, as you say.
> Did you try reverting as many of the changes that happened
> in the meantime as possible (instead of bisection)?
>
That's a really good point. I'll make some time for this in the next weeks.
Please mark it with changes requested in the meantime, as I expect to
make changes to the patch when I have a result.
> The other question is whether we need to enable any of the
> clocks or runtime resume before calling fec_restart()?
On our board it works fine without it, I don't know enough about this
SoC or other NXP SoCs to know if it's necessary in other situations.
The clocks are re-enabled in the open call which appears to be enough to
get traffic going again when the link is brought up.
Perhaps NXP can fill us in?
Thanks! // John Ernberg
prev parent reply other threads:[~2024-02-14 15:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 10:50 [PATCH net-next] net: fec: Always call fec_restart() in resume path John Ernberg
2024-02-14 2:44 ` Jakub Kicinski
2024-02-14 8:27 ` John Ernberg
2024-02-14 14:52 ` Jakub Kicinski
2024-02-14 15:49 ` John Ernberg [this message]
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=e0641509-e18f-48d6-acba-6b649496782e@actia.se \
--to=john.ernberg@actia.se \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shenwei.wang@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@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).