Messages in this thread | | | From | John Ernberg <> | Subject | Re: [PATCH net-next] net: fec: Always call fec_restart() in resume path | Date | Wed, 14 Feb 2024 15:49:40 +0000 |
| |
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 | |