wireguard-linux/drivers/net/ethernet, branch jd/unified-crypt-queue

r8169: add workaround for RTL8168evl TSO hw issues

2020-04-19T03:20:11Z

Add workaround for hw issues with TSO on RTL8168evl. This workaround is based on information I got from Realtek, and *should* allow to safely enable TSO on this chip version. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: improve rtl8169_tso_csum_v2

2020-04-19T03:20:11Z

Simplify the code and avoid the overhead of calling vlan_get_protocol(). Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: use rtl8169_set_features in rtl8169_init_one

2020-04-19T03:20:11Z

At that place in rtl_init_one() we can safely use rtl8169_set_features() to configure the chip according to the default features. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: preserve VLAN setting on RTL8125 in rtl_init_rxcfg

2020-04-19T03:20:10Z

So far we set RX_VLAN_8125 unconditionally, even if NETIF_F_HW_VLAN_CTAG_RX may not be set. Don't touch these bits, and let only rtl8169_set_features() control them. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: remove NETIF_F_HIGHDMA from vlan_features

2020-04-19T03:20:10Z

NETIF_F_HIGHDMA is added to vlan_features by register_netdev(), therefore we can omit this here. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: move setting OCP base to generic init code

2020-04-19T03:20:10Z

Move setting the ocp_base to rtl_init_one(). Where supported the value is always the same, and if not supported it doesn't hurt. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

enetc: permit configuration of rx-vlan-filter with ethtool

2020-04-18T22:55:05Z

Each ENETC station interface (SI) has a VLAN filter list and a port flag (PSIPVMR) by which it can be put in "VLAN promiscuous" mode, which enables the reception of VLAN-tagged traffic even if it is not in the VLAN filtering list. Currently the handling of this setting works like this: the port starts off as VLAN promiscuous, then it switches to enabling VLAN filtering as soon as the first VLAN is installed in its filter via .ndo_vlan_rx_add_vid. In practice that does not work out very well, because more often than not, the first VLAN to be installed is out of the control of the user: the 8021q module, if loaded, adds its rule for 802.1p (VID 0) traffic upon bringing the interface up. What the user is currently seeing in ethtool is this: ethtool -k eno2 rx-vlan-filter: on [fixed] which doesn't match the intention of the code, but the practical reality of having the 8021q module install its VID which has the side-effect of turning on VLAN filtering in this driver. All in all, a slightly confusing experience. So instead of letting this driver switch the VLAN filtering state by itself, just wire it up with the rx-vlan-filter feature from ethtool, and let it be user-configurable just through that knob, except for one case, see below. In promiscuous mode, it is more intuitive that all traffic is received, including VLAN tagged traffic. It appears that it is necessary to set the flag in PSIPVMR for that to be the case, so VLAN promiscuous mode is also temporarily enabled. On exit from promiscuous mode, the setting made by ethtool is restored. Signed-off-by: Vladimir Oltean Reviewed-by: Claudiu Manoil Signed-off-by: David S. Miller

net: mscc: ocelot: deal with problematic MAC_ETYPE VCAP IS2 rules

2020-04-18T22:54:11Z

By default, the VCAP IS2 will produce a single match for each frame, on the most specific classification. Example: a ping packet (ICMP over IPv4 over Ethernet) sent from an IP address of 10.0.0.1 and a MAC address of 96:18:82:00:04:01 will match this rule: tc filter add dev swp0 ingress protocol ipv4 \ flower skip_sw src_ip 10.0.0.1 action drop but not this one: tc filter add dev swp0 ingress \ flower skip_sw src_mac 96:18:82:00:04:01 action drop Currently the driver does not really warn the user in any way about this, and the behavior is rather strange anyway. The current patch is a workaround to force matches on MAC_ETYPE keys (DMAC and SMAC) for all packets irrespective of higher layer protocol. The setting is made at the port level. Of course this breaks all other non-src_mac and non-dst_mac matches, so rule exclusivity checks have been added to the driver, in order to never have rules of both types on any ingress port. The bits that discard higher-level protocol information are set only once a MAC_ETYPE rule is added to a filter block, and only for the ports that are bound to that filter block. Then all further non-MAC_ETYPE rules added to that filter block should be denied by the ports bound to it. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

igc: Fix default MAC address filter override

2020-04-17T17:19:24Z

This patch fixes a bug when the user adds the first MAC address filter via ethtool NFC mechanism. When the first MAC address filter is added, it overwrites the default MAC address filter configured at RAL[0] and RAH[0]. As consequence, frames addressed to the interface MAC address are not sent to host anymore. This patch fixes the bug by calling igc_set_default_mac_filter() during adapter init so the position 0 of adapter->mac_table[] is assigned to the default MAC address. Signed-off-by: Andre Guedes Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher

igc: Remove dead code related to flower filter

2020-04-17T17:19:24Z

IGC driver has no support for tc-flower filters so this patch removes some leftover code, probably copied from IGB driver by mistake. Signed-off-by: Andre Guedes Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher