On Tue, Sep 21, 2021 at 11:02:52PM +0100, Russell King (Oracle) wrote:
On Tue, Sep 21, 2021 at 11:45:28PM +0200, Pavel Machek wrote:
Hi!
Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke when moving the incorrect handling of mac link state out of mac_config(). This reason this breaks is because the stmmac's WoL is handled by the MAC rather than the PHY, and phylink doesn't cater for that scenario.
This patch adds the necessary phylink code to handle suspend/resume events according to whether the MAC still needs a valid link or not. This is the barest minimum for this support.
This adds functions that end up being unused in 5.10. AFAICT we do not need this in 5.10.
It needs to be backported to any kernel that also has "net: stmmac: fix MAC not working when system resume back with WoL active" backported to. From what I can tell, the fixes line in that commit refers to a commit (46f69ded988d) in v5.7-rc1.
If "net: stmmac: fix MAC not working when system resume back with WoL active" is not being backported to 5.10, then there is no need to backport this patch.
Agreed.
As I'm not being copied on the stmmac commit, I've no idea which kernels this patch should be backported to.
AFAICT "net: stmmac: fix MAC not working when..." is not queued for 5.10.68-rc1 or 5.14.7-rc1.
Okay, this is madness. What is going on with stable's patch selection? The logic seems completely reversed.
"net: phylink: Update SFP selected interface on advertising changes" does not have a Fixes tag, and is not a fix in itself, yet has been picked up by the stable team. It lays the necessary work for its counter-part patch, which is...
"net: stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume" _has_ a Fixes tag, but has *not* been picked up by the stable team.
It seems there's something very wrong process-wise here. Why would a patch _without_ a Fixes line and isn't a fix in itself be picked out for stable backport when patches with a Fixes line are ignored?
Because they came in through two different sets of processes. And during the -rc1 merge window madness, we have lots to still catch up on because of all of the "fixes" that people wait to get into the tree then.
Not unless the stable plan is to apply "net: phylink: Update SFP selected interface on advertising changes" and then sometime later apply "net: stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume". No idea.
It all seems very weird and the process seems broken to me.
Help is always gladly accepted. Marking patches explicitly for stable with a cc: stable is always the easiest way into the tree. Otherwise we have to do hueristics in looking at changelog text and Fixes: tags to try to guess what is, and is not, valid for stable trees.
thanks,
greg k-h