- 23 Jan, 2019 40 commits
-
-
Ido Schimmel authored
Spectrum-1 and Spectrum-2 are largely backward compatible with regards to VXLAN. One difference - as explained in previous patch - is that an underlay RIF needs to be specified instead of an underlay VR during NVE initialization. This is accomplished by calling the relevant function that returns the index of such a RIF based on the table ID (RT_TABLE_MAIN) where underlay look up occurs. The second difference is that VXLAN learning (snooping) is controlled via a different register (TNPC). Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The configuration of a VXLAN tunnel in Spectrum-1 and Spectrum-2 is largely the same. To avoid code duplication, breakout the common parts to a common function that can be invoked from the ASIC-specific code. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In Spectrum-2, instead of providing the ID of the virtual router (VR) where NVE underlay lookups will occur as in Spectrum-1, the ID of a router interface (RIF) in this VR is required. Expose functions to create and destroy such a RIF. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/net/ethernet/mellanox/mlx4/eq.c: In function ‘mlx4_eq_int’: drivers/net/ethernet/mellanox/mlx4/mlx4.h:219:5: warning: this statement may fall through [-Wimplicit-fallthrough=] if (mlx4_debug_level) \ ^ drivers/net/ethernet/mellanox/mlx4/eq.c:558:4: note: in expansion of macro ‘mlx4_dbg’ mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n", ^~~~~~~~ drivers/net/ethernet/mellanox/mlx4/eq.c:561:3: note: here case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/net/ethernet/qlogic/qed/qed_cxt.c:2126:4: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:6336:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2231:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:722:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:783:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/3com/3c509.c:1265:8: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/3com/3c509.c:1271:8: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: net/tipc/link.c:1125:6: warning: this statement may fall through [-Wimplicit-fallthrough=] net/tipc/socket.c:736:6: warning: this statement may fall through [-Wimplicit-fallthrough=] net/tipc/socket.c:2418:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sudarsana Reddy Kalluru authored
Recently, there were bunch of fixes to bnx2x driver, the code is now aligned to out-of-box driver version 1.713.36. This patch updates bnx2x driver version to 1.713.36. Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nathan Chancellor authored
When building this code on a 32-bit platform such as ARM, there is a link time error (lld error shown, happpens with ld.bfd too): ld.lld: error: undefined symbol: __aeabi_uldivmod >>> referenced by devlink.c >>> net/core/devlink.o:(devlink_health_buffers_create) in archive built-in.a This happens when using a regular division symbol with a u64 dividend. Use DIV_ROUND_UP_ULL, which wraps do_div, to avoid this situation. Fixes: cb5ccfbe ("devlink: Add health buffer support") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Some of the PHY and MDIO drivers refer to the COPYING file in the main directory of this archive. This is the main license for Linux, thus GPLv2 plus syscall extension. Fixup the MODULE_LICENSE() where needed and add an SDPX header for GPLv2. Cc: David Daney <david.daney@cavium.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
A few PHY drivers have the GPLv2 license text. They then either have a MODULE_LICENSE() of GPLv2+, or an SPDX tag of GPLv2+. Since the license text is much easier to understand than either the SPDX tag or the MODULE_LICENSE, use it as the definitive source of the licence, and fixup with others when there are contradictions. Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Jonas Jensen <jonas.jensen@gmail.com> Cc: Laurent Pinchart <laurentp@cse-semaphore.com> Cc: Paulius Zaleckas <paulius.zaleckas@teltonika.lt> Cc: Scott Wood <scottwood@freescale.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Andrew F. Davis <afd@ti.com> Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Andrew Lunn says: ==================== SPDX tags for PHY and MDIO drivers This patchset adds SPDX tags to files where the license information is clear and consistent. It also removes redundent license text when an SPDX header is present. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
The SPDX header makes any license text redundent. Remove it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Where the license text and the MODULE_LICENSE() value agree, convert to using an SPDX header, removing the license text. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vishal Kulkarni authored
1) Speed should be supported by Physical Port Capabilities. 2) report Forward Error Correction mode which are available. 3) Added few comments. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Vishal Kulkarni <vishal@chelsio.com> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== selftests: forwarding: Add tests for VXLAN routing VXLAN routing allows hosts in different overlay networks (i.e., different VNIs) to communicate with one another. Two popular routing models are asymmetric and symmetric routing. In asymmetric routing the ingress VTEP routes the packet into the correct VXLAN tunnel, whereas the egress VTEP only bridges the packet to the correct host. Therefore, packets in different directions use different VNIs - the target VNI. In symmetric routing both the ingress and egress VTEPs perform routing in the overlay network into / from the VXLAN tunnel. Packets in different directions use the same VNI - the L3 VNI. Different tenants (VRFs) use different L3 VNIs. Patch #1 adds a test for asymmetric routing. Patches #2-#3 reuse the topology and add test cases for ARP decapsulation and suppression. Patch #4 adds a test for symmetric routing. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
ARP suppression allows the Linux bridge to answer ARP requests on behalf of remote hosts. It reduces the amount of packets a VTEP needs to flood. This test verifies that ARP suppression on / off works when a neighbour exists and when it does not exist. It does so by sending an ARP request from a host connected to one VTEP and checking whether it was received by a second VTEP. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In a similar fashion to the asymmetric test, add a test for symmetric routing. In symmetric routing both the ingress and egress VTEPs perform routing in the overlay network into / from the VXLAN tunnel. Packets in different directions use the same VNI - the L3 VNI. Different tenants (VRFs) use different L3 VNIs. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Verify that ARP packets are correctly decapsulated by the ingress VTEP by removing the neighbours configured on both VLAN interfaces and running a ping test. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In asymmetric routing the ingress VTEP routes the packet into the correct VXLAN tunnel, whereas the egress VTEP only bridges the packet to the correct host. Therefore, packets in different directions use different VNIs - the target VNI. The test uses a simple topology with two VTEPs and two VNIs and verifies that ping passes between hosts (local / remote) in the same VLAN (VNI) and in different VLANs belonging to the same tenant (VRF). While the test does not check VM mobility, it does configure an anycast gateway using a macvlan device on both VTEPs. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Yangbo Lu says: ==================== External trigger stamp fifo support for ptp_qoriq This patch-set is to add external trigger stamp fifo support by a new binding "fsl,extts-fifo", and to add fiper pulse loopback support which is very useful for validating trigger without external hardware. Also fixed issues in interrupt enabling/handling. "fsl,extts-fifo" is required to be added into 1588 timer dts node whose hardware supports it. The work will be done for some QorIQ platforms dts in the near future. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Added drivers/ptp/ptp_qoriq_debugfs.c into QorIQ PTP clock driver list. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
This patch is to add debugfs support for ptp_qoriq. Current debugfs supports to control fiper1/fiper2 loopback mode. If the loopback mode is enabled, the fiper1/fiper2 pulse is looped back into trigger1/ trigger2 input. This is very useful for validating hardware and driver without external hardware. Below is an example to enable fiper1 loopback. echo 1 > /sys/kernel/debug/2d10e00.ptp_clock/fiper1-loopback Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
This patch is to add external trigger stamp fifo support for 1588 timer. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Documented "fsl,extts-fifo" property. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
The external trigger stamp FIFO was introduced as a new feature for QorIQ 1588 timer IP block. This patch is to support it by adding a new dts property "fsl,extts-fifo". Any QorIQ 1588 timer supporting this feature is required to add this property in its dts node. In addition, the FIFO should be cleaned up before enabling external trigger interrupts. Otherwise, there will be interrupts immediately just after enabling external trigger interrupts. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
The tmr_tevent register would update event bits no matter tmr_temask bits were set or not. So we should get interrupts by tmr_tevent & tmr_temask, and clean up interrupts in tmr_tevent before enabling them. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
nlmsg_put may fail, this fix add a check of its return value. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vinod Koul says: ==================== net: Add support for Qualcomm ethqos Some Qualcomm SoCs sport a ethqos controller which use DW ip, so add the glue driver which uses stmmac driver along with DT bindings for this device. This controller supports rgmii mode and doesn't work with existing phy drivers as they do not remove the phy delay delay in this mode, so fix the two phy drivers tested with this. Changes in v3: - Add description in DT and rename the file and compatible as suggested by Rob - Update changelog for QCA8K driver - Update AT803x phy disable delay for all RGMxx modes Changes in v2: - Fix the example in dt-binding - Remove DT property for disable the delay and disable delay for RGMII mode in AT803x and QCA8K PHY drivers ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinod Koul authored
In RGMII mode we should not have any delay in port MAC, so disable the delay. Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinod Koul authored
For RGMII mode, phy delay should be disabled. Add this case along with disable delay routines. Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinod Koul authored
Add myself and Niklas as maintainers for this driver Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinod Koul authored
Add glue driver to support Qualcomm ETHQOS using stmmac driver. This is based on downstream driver written by Siddarth Gupta, Sunil Kumar Paidimarri, Rahul Ankushrao Kawadgave, Nisha Menon, Jagadeesh Babu Challagundla, Chaitanya Pratapa, Lakshit Tyagi, Suraj Jaiswal, Sneh Shah and Ventrapragada Ravi Kanth Co-developed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinod Koul authored
Add support for Qualcomm ethqos found in some SoCs like QCS404. Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Artem Panfilov authored
This patch adds support for the SIOCGHWTSTAMP ioctl which enables user processes to read the current hwtstamp_config settings non-destructively. Signed-off-by: Artem Panfilov <panfilov.artyom@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Linus Lüssing says: ==================== bridge: implement Multicast Router Discovery (RFC4286) This patchset adds initial Multicast Router Discovery support to the Linux bridge (RFC4286). With MRD it is possible to detect multicast routers and mark bridge ports and forward multicast packets to such routers accordingly. So far, multicast routers are detected via IGMP/MLD queries and PIM messages in the Linux bridge. As there is only one active, selected querier at a time RFC4541 ("Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches") section 2.1.1.a) recommends snooping Multicast Router Advertisements as provided by MRD (RFC4286). The first two patches are refactoring some existing code which is reused for parsing the Multicast Router Advertisements later in the fourth patch. The third patch lets the bridge join the all-snoopers multicast address to be able to reliably receive the Multicast Router Advertisements. What is not implemented yet from RFC4286 yet: * Sending Multicast Router Solicitations: -> RFC4286: "[...] may be sent when [...] an interface is (re-)initialized [or] MRD is enabled" * Snooping Multicast Router Terminations: -> currently this only relies on our own timeouts * Adjusting timeouts with the values provided in the announcements Changes in v2: * rebased to current net-next/master (no conflicts/changes) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linus Lüssing authored
When multiple multicast routers are present in a broadcast domain then only one of them will be detectable via IGMP/MLD query snooping. The multicast router with the lowest IP address will become the selected and active querier while all other multicast routers will then refrain from sending queries. To detect such rather silent multicast routers, too, RFC4286 ("Multicast Router Discovery") provides a standardized protocol to detect multicast routers for multicast snooping switches. This patch implements the necessary MRD Advertisement message parsing and after successful processing adds such routers to the internal multicast router list. Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linus Lüssing authored
Next to snooping IGMP/MLD queries RFC4541, section 2.1.1.a) recommends to snoop multicast router advertisements to detect multicast routers. Multicast router advertisements are sent to an "all-snoopers" multicast address. To be able to receive them reliably, we need to join this group. Otherwise other snooping switches might refrain from forwarding these advertisements to us. Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by: David S. Miller <davem@davemloft.net>
-