Re: [PATCH] net: fec: don't reset irq coalesce settings to defaults on "ip link up"

From: Greg Ungerer
Date: Mon Dec 05 2022 - 08:15:29 EST



On 5/12/22 18:44, Rasmus Villemoes wrote:
On 05/12/2022 08.15, Greg Ungerer wrote:
Hi Rasmus,

On 23 Nov 2022, Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote:
Currently, when a FEC device is brought up, the irq coalesce settings
are reset to their default values (1000us, 200 frames). That's
unexpected, and breaks for example use of an appropriate .link file to
make systemd-udev apply the desired
settings
(https://www.freedesktop.org/software/systemd/man/systemd.link.html),
or any other method that would do a one-time setup during early boot.

Refactor the code so that fec_restart() instead uses
fec_enet_itr_coal_set(), which simply applies the settings that are
stored in the private data, and initialize that private data with the
default values.

Signed-off-by: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>

This breaks The ColdFire parts that use the FEC hardware module at the
very least. It results in an access to a register (FEC_TXIC0) that does
not exist in the ColdFire FEC. Reverting this change fixes it.

So for me this is now broken in 6.1-rc8.

Sorry about that.

Since we no longer go through the same path that ethtool would, we need
to add a check of the FEC_QUIRK_HAS_COALESCE bit before calling
fec_enet_itr_coal_set() during initialization. So something like

diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 93a116788ccc..3df1b9be033f 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1186,7 +1186,8 @@ fec_restart(struct net_device *ndev)
writel(0, fep->hwp + FEC_IMASK);

/* Init the interrupt coalescing */
- fec_enet_itr_coal_set(ndev);
+ if (fep->quirks & FEC_QUIRK_HAS_COALESCE)
+ fec_enet_itr_coal_set(ndev);
}

That certainly fixes it.


Or perhaps it's even better to do the check inside
fec_enet_itr_coal_set() and just return silently?

That may well be better, yes.


Either way, I don't know if it's too late to apply this fix, or if
df727d4547 should just be reverted for 6.1 and then redone properly?
Greg, can you check if the above fixes it for you?

Yep, that is good. I have no strong opinion on which way to handle
right now, so up to you.

Regards
Greg