ethtool -K … lro off` doesn't stick once an ntuple LRO rule exists

[meehien]

mtk_fix_features() forces NETIF_F_LRO back on whenever the netdev has an
LRO destination address programmed, so a request to disable LRO is silently
reverted. ndo_fix_features() is where a driver resolves dependencies
between features, not a veto — the stack treats an unhonoured request as a
driver bug.

The caller that matters is dev_disable_lro(). The bridge and the routing
path call it to guarantee receive aggregation is off, because a device that
coalesces segments it is about to forward re-segments them wrongly. It
clears the bit, calls netdev_update_features(), and warns if the feature
survives — which is what happens here: enslave the port to a bridge with an
LRO rule programmed, netdev_WARN() fires, and hardware LRO stays on for a
forwarding path.

Programmed destination addresses are inert while LRO is off and are
re-applied by mtk_hwlro_netdev_enable() if it's turned back on, so nothing
is lost by honouring the request. Drop the override.

[frank-w]

Is lro still working when this flag is dropped?

[meehien]

yes, LRO still works, the patch only removes the veto in mtk_fix_features(), and the enable path (ethtool -K … lro on → mtk_set_features() → mtk_hwlro_netdev_enable()) is not affected.