- 16 Feb, 2021 27 commits
-
-
Horatiu Vultur authored
Implement functions 'port_mrp_add', 'port_mrp_del', 'port_mrp_add_ring_role' and 'port_mrp_del_ring_role' to call the mrp functions from ocelot. Also all MRP frames that arrive to CPU on queue number OCELOT_MRP_CPUQ will be forward by the SW. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Add support for offloading MRP in HW. Currently implement the switchdev calls 'SWITCHDEV_OBJ_ID_MRP', 'SWITCHDEV_OBJ_ID_RING_ROLE_MRP', to allow to create MRP instances and to set the role of these instances. Add DSA_NOTIFIER_MRP_ADD/DEL and DSA_NOTIFIER_MRP_ADD/DEL_RING_ROLE which calls to .port_mrp_add/del and .port_mrp_add/del_ring_role in the DSA driver for the switch. Signed-off-by:
-
Horatiu Vultur authored
Add basic support for MRP. The HW will just trap all MRP frames on the ring ports to CPU and allow the SW to process them. In this way it is possible to for this node to behave both as MRM and MRC. Current limitations are: - it doesn't support Interconnect roles. - it supports only a single ring. - the HW should be able to do forwarding of MRP Test frames so the SW will not need to do this. So it would be able to have the role MRC without SW support. Signed-off-by:
-
Horatiu Vultur authored
Check the return values of the br_mrp_switchdev function. In case of: - BR_MRP_NONE, return the error to userspace, - BR_MRP_SW, continue with SW implementation, - BR_MRP_HW, continue without SW implementation, Signed-off-by:
-
Horatiu Vultur authored
This patch extends the br_mrp_switchdev functions to be able to have a better understanding what cause the issue and if the SW needs to be used as a backup. There are the following cases: - when the code is compiled without CONFIG_NET_SWITCHDEV. In this case return success so the SW can continue with the protocol. Depending on the function, it returns 0 or BR_MRP_SW. - when code is compiled with CONFIG_NET_SWITCHDEV and the driver doesn't implement any MRP callbacks. In this case the HW can't run MRP so it just returns -EOPNOTSUPP. So the SW will stop further to configure the node. - when code is compiled with CONFIG_NET_SWITCHDEV and the driver fully supports any MRP functionality. In this case the SW doesn't need to do anything. The functions will return 0 or BR_MRP_HW. - when code is compiled with CONFIG_NET_SWITCHDEV and the HW can't run completely the protocol but it can help the SW to run it. For example, the HW can't support completely MRM role(can't detect when it stops receiving MRP Test frames) but it can redirect these frames to CPU. In this case it is possible to have a SW fallback. The SW will try initially to call the driver with sw_backup set to false, meaning that the HW should implement completely the role. If the driver returns -EOPNOTSUPP, the SW will try again with sw_backup set to false, meaning that the SW will detect when it stops receiving the frames but it needs HW support to redirect the frames to CPU. In case the driver returns 0 then the SW will continue to configure the node accordingly. Signed-off-by:
-
Horatiu Vultur authored
Add the enum br_mrp_hw_support that is used by the br_mrp_switchdev functions to allow the SW to detect the cases where HW can't implement the functionality or when SW is used as a backup. Signed-off-by:
-
Horatiu Vultur authored
Add the member sw_backup to the structures switchdev_obj_ring_role_mrp and switchdev_obj_in_role_mrp. In this way the SW can call the driver in 2 ways, once when sw_backup is set to false, meaning that the driver should implement this completely in HW. And if that is not supported the SW will call again but with sw_backup set to true, meaning that the HW should help or allow the SW to run the protocol. For example when role is MRM, if the HW can't detect when it stops receiving MRP Test frames but it can trap these frames to CPU, then it needs to return -EOPNOTSUPP when sw_backup is false and return 0 when sw_backup is true. Signed-off-by:
-
Horatiu Vultur authored
Remove #IS_ENABLED(CONFIG_BRIDGE_MRP) from switchdev.h. This will simplify the code implements MRP callbacks and will be similar with the vlan filtering. Signed-off-by:
-
Robert Hancock authored
When 88E1111 is operating in SGMII mode, auto-negotiation should be enabled on the SGMII side so that the link will come up properly with PCSes which normally have auto-negotiation enabled. This is normally the case when the PHY defaults to SGMII mode at power-up, however if we switched it from some other mode like 1000Base-X, as may happen in some SFP module situations, it may not be, particularly for modules which have 1000Base-X auto-negotiation defaulting to disabled. Call genphy_check_and_restart_aneg on the fiber page to ensure that auto- negotiation is properly enabled on the SGMII interface. Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Signed-off-by:
-
David S. Miller authored
Marek Behún says: ====================- Add 5gbase-r PHY interface mode there is still some testing needed for Amethyst patches, so I have split the part adding support for 5gbase-r interface mode and am sending it alone. The first two patches are already reviewed. Changes since last patches (Amethyst v16): - added phylink 5gbase-r handler - added SFP support for 5gbase-r mode ==================== Signed-off-by: -
Marek Behún authored
The sfp_parse_support() function is setting 5000baseT_Full in some cases. Now that we have PHY_INTERFACE_MODE_5GBASER interface mode available, change sfp_select_interface() to return PHY_INTERFACE_MODE_5GBASER if 5000baseT_Full is set in the link mode mask. Signed-off-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Marek Behún authored
Add 5GBASER interface type and speed to phylink. Signed-off-by:
-
Pavana Sharma authored
Add 5GBASE-R phy interface mode Signed-off-by:
Pavana Sharma <pavana.sharma@digi.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Pavana Sharma authored
Add 5gbase-r PHY interface mode. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Florian Fainelli authored
The tg3 driver tried to communicate towards the PHY driver whether it wanted RGMII in-band signaling enabled or disabled however there is nothing that looks at those flags in drivers/net/phy/broadcom.c so this does do not anything. Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
David S. Miller authored
Bjarni Jonasson says: ==================== Fixes applied to VCS8514 3 different fixes applied to VSC8514: LCPLL reset, serdes calibration and coma mode disabled. Especially the serdes calibration is large and is now placed in a new file 'mscc_serdes.c' which can act as a placeholder for future serdes configuration. v1 -> v2: Preserved reversed christmas tree Removed forward definitions Fixed build issues Changed net to net-next v2 -> v3: Added cover letter. Removed ena_clk_bypass from function call Created mscc_serdes.c and .h for serdes configuration Modified coma register config. ==================== Signed-off-by: -
Bjarni Jonasson authored
The 'coma mode' (configurable through sw or hw) provides an optional feature that may be used to control when the PHYs become active. The typical usage is to synchronize the link-up time across all PHY instances. This patch releases coma mode if not done by hardware, otherwise the phys will not link-up. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by:
-
Bjarni Jonasson authored
The current IB serdes calibration algorithm (performed by the onboard 8051) has proven to be unstable for the VSC8514 QSGMII phy. A new algorithm has been developed based on 'Frequency-offset Jittered-Injection' or 'FoJi' method which solves all known issues. This patch disables the 8051 algorithm and replaces it with the new FoJi algorithm. The calibration is now performed in a new file (mscc_serdes.c), which can act as an placeholder for future serdes configurations. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Bjarni Jonasson authored
At Power-On Reset, transients may cause the LCPLL to lock onto a clock that is momentarily unstable. This is normally seen in QSGMII setups where the higher speed 6G SerDes is being used. This patch adds an initial LCPLL Reset to the PHY (first instance) to avoid this issue. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Fix buggy brport flags offload for SJA1105 DSA I am resending this series because the title and the patches were mixed up and these patches were lost. This series' cover letter was used as the merge commit for the unrelated "Fixing build breakage after "Merge branch 'Propagate-extack-for-switchdev-LANs-from-DSA'"" series, as can be seen below: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=ca04422afd6998611a81d0ea1b61d5a5f4923f84 while the actual patches from the "Fix buggy brport flags offload for SJA1105 DSA" series were marked as superseded and not applied: https://patchwork.kernel.org/project/netdevbpf/cover/20210214155704.1784220-1-olteanv@gmail.com/ which they should have. I know with so many bugs I introduced it's hard to keep track, I'm sorry. Original series description: While testing software bridging on sja1105, I discovered that I managed to introduce two bugs in a single patch submitted recently to net-next. ==================== Signed-off-by:
-
Vladimir Oltean authored
Quite embarrasingly, I managed to fool myself into thinking that the flooding domain of sja1105 source ports is restricted by the forwarding domain, which it isn't. Frames which match an FDB entry are forwarded towards that entry's DESTPORTS restricted by REACH_PORT[SRC_PORT], while frames that don't match any FDB entry are forwarded towards FL_DOMAIN[SRC_PORT] or BC_DOMAIN[SRC_PORT]. This means we can't get away with doing the simple thing, and we must manage the flooding domain ourselves such that it is restricted by the forwarding domain. This new function must be called from the .port_bridge_join and .port_bridge_leave methods too, not just from .port_bridge_flags as we did before. Fixes: 4d942354 ("net: dsa: sja1105: offload bridge port flags to device") Signed-off-by:
-
Vladimir Oltean authored
Due to a mistake, the driver always sets the address learning flag to the previously stored value, and not to the currently configured one. The bug is visible only in standalone ports mode, because when the port is bridged, the issue is masked by .port_stp_state_set which overwrites the address learning state to the proper value. Fixes: 4d942354 ("net: dsa: sja1105: offload bridge port flags to device") Signed-off-by:
-
Geetha sowjanya authored
This patch fixes references to uninitialized variables and debugfs entry name for CN10K platform and HW_TSO flag check. Fixes: 3ad3f8f9 ("octeontx2-af: cn10k: MAC internal loopback support"). Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> v1-v2 - Clear HW_TSO flag for 96xx B0 version. This patch fixes the bug introduced by the commit 3ad3f8f9 ("octeontx2-af: cn10k: MAC internal loopback support"). These changes are not yet merged into net branch, hence submitting to net-next. Signed-off-by:
-
Vladimir Oltean authored
If the driver fails to probe, it would be nice to not leak memory. Signed-off-by:
-
Vladimir Oltean authored
ocelot_init_port is called only if dsa_is_unused_port == false, however ocelot_deinit_port is called unconditionally. This causes a warning in the skb_queue_purge inside ocelot_deinit_port saying that the spin lock protecting ocelot_port->tx_skbs was not initialized. Fixes: e5fb512d ("net: mscc: ocelot: deinitialize only initialized ports") Signed-off-by:
-
Chen Lin authored
Remove the 'ionic_reset_cb' typedef as it is not used. Signed-off-by:
Chen Lin <chen.lin5@zte.com.cn> Acked-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2021-02-16 The following pull-request contains BPF updates for your *net-next* tree. There's a small merge conflict between 7eeba170 ("tcp: Add receive timestamp support for receive zerocopy.") from net-next tree and 9cacf81f ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE") from bpf-next tree. Resolve as follows: [...] lock_sock(sk); err = tcp_zerocopy_receive(sk, &zc, &tss); err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname, &zc, &len, err); release_sock(sk); [...] We've added 116 non-merge commits during the last 27 day(s) which contain a total of 156 files changed, 5662 insertions(+), 1489 deletions(-). The main changes are: 1) Adds support of pointers to types with known size among global function args to overcome the limit on max # of allowed args, from Dmitrii Banshchikov. 2) Add bpf_iter for task_vma which can be used to generate information similar to /proc/pid/maps, from Song Liu. 3) Enable bpf_{g,s}etsockopt() from all sock_addr related program hooks. Allow rewriting bind user ports from BPF side below the ip_unprivileged_port_start range, both from Stanislav Fomichev. 4) Prevent recursion on fentry/fexit & sleepable programs and allow map-in-map as well as per-cpu maps for the latter, from Alexei Starovoitov. 5) Add selftest script to run BPF CI locally. Also enable BPF ringbuffer for sleepable programs, both from KP Singh. 6) Extend verifier to enable variable offset read/write access to the BPF program stack, from Andrei Matei. 7) Improve tc & XDP MTU handling and add a new bpf_check_mtu() helper to query device MTU from programs, from Jesper Dangaard Brouer. 8) Allow bpf_get_socket_cookie() helper also be called from [sleepable] BPF tracing programs, from Florent Revest. 9) Extend x86 JIT to pad JMPs with NOPs for helping image to converge when otherwise too many passes are required, from Gary Lin. 10) Verifier fixes on atomics with BPF_FETCH as well as function-by-function verification both related to zero-extension handling, from Ilya Leoshkevich. 11) Better kernel build integration of resolve_btfids tool, from Jiri Olsa. 12) Batch of AF_XDP selftest cleanups and small performance improvement for libbpf's xsk map redirect for newer kernels, from Björn Töpel. 13) Follow-up BPF doc and verifier improvements around atomics with BPF_FETCH, from Brendan Jackman. 14) Permit zero-sized data sections e.g. if ELF .rodata section contains read-only data from local variables, from Yonghong Song. 15) veth driver skb bulk-allocation for ndo_xdp_xmit, from Lorenzo Bianconi. ==================== Signed-off-by:
-
- 15 Feb, 2021 13 commits
-
-
Jefferson Carpenter authored
Signed-off-by:
Jefferson Carpenter <jeffersoncarpenter2@gmail.com> Signed-off-by:
-
Colin Ian King authored
The variable mfs_max is not initialized and is being compared to find the maximum value. Fix this by initializing it to 0. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 90bc8e00 ("i40e: Add hardware configuration for software based DCB") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Heiner Kallweit authored
Some internal PHY's have their events like link change reported by the MAC interrupt. We have PHY_IGNORE_INTERRUPT to deal with this scenario. I'm not too happy with this name. We don't ignore interrupts, typically there is no interrupt exposed at a PHY level. So let's rename it to PHY_MAC_INTERRUPT. This is in line with phy_mac_interrupt(), which is called from the MAC interrupt handler to handle PHY events. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Michael Walle authored
AR8035 recently gained MDIX support. The same functions will work for the AR8031/33 PHY. We just need to add the at803x_config_aneg() callback. This was tested on a Kontron sl28 board. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: broadcom: Cleanups and APD This patch series cleans up the brcmphy.h header and its numerous unused phydev->dev_flags, fixes the RXC/TXC clock disabling bit and allows the BCM54210E PHY to utilize APD. Changes in v2: - dropped the patch that attempted to fix a possible discrepancy between the datasheet and the actual hardware - added a patch to remove a forward declaration - do additional flags cleanup ==================== Signed-off-by: -
Florian Fainelli authored
BCM54210E/BCM50212E has been verified to work correctly with the auto-power down configuration done by bcm54xx_adjust_rxrefclk(), add it to the list of PHYs working. While we are at it, provide an appropriate name for the bit we are changing which disables the RXC and TXC during auto-power down when there is no energy on the cable. Signed-off-by:
-
Florian Fainelli authored
We have a number of unused flags defined today and since we are scarce on space and may need to introduce new flags in the future remove and shift every existing flag down into a contiguous assignment. PHY_BCM_FLAGS_MODE_1000BX was only used internally for the BCM54616S PHY, so we allocate a driver private structure instead to store that flag instead of canibalizing one from phydev->dev_flags for that purpose. Signed-off-by:
-
Florian Fainelli authored
Avoid a forward declaration by moving the callers of bcm54xx_config_clock_delay() below its body. Signed-off-by:
-
Lijun Pan authored
The CRQ and subCRQ descriptors are DMA mapped, so dma_wmb(), though weaker, is good enough to protect the data structures. Signed-off-by:
Lijun Pan <ljp@linux.ibm.com> Acked-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
Lijun Pan authored
The only thing reset_long_term_buff() should do is set buffer to zero. After doing that, it is not necessary to send_request_map again to VIOS since it actually does not change the mapping. So, keep memset function and remove all others. Signed-off-by:
-
Geliang Tang authored
Add mptcpi_local_addr_used and mptcpi_local_addr_max in struct mptcp_info. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
It seems that the right argument to be passed is &tcp_ip6_spec->ip6dst, not &tcp_ip6_spec->ip6src, when calling function ipv6_addr_any(). Addresses-Coverity-ID: 1501734 ("Copy-paste error") Fixes: efca91e8 ("i40e: Add flow director support for IPv6") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Rafał Miłecki authored
Hardware comes up with default max frame size set to 1518. When using it with switch it results in actual Ethernet MTU 1492: 1518 - 14 (Ethernet header) - 4 (Broadcom's tag) - 4 (802.1q) - 4 (FCS) Above means hardware in its default state can't handle standard Ethernet traffic (MTU 1500). Define maximum possible Ethernet overhead and always set MAC max frame length accordingly. This change fixes handling Ethernet frames of length 1506 - 1514. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
