- 23 Apr, 2019 34 commits
-
-
David S. Miller authored
Kavya Sree Kotagiri says: ==================== net: phy: mscc: Improvements to VSC8514 PHY driver. The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX, 1000BASE-X, can communicate with the MAC via QSGMII. The MAC interface protocol for each port within QSGMII can be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is connecting to supports this functionality. VSC8514 also supports SGMII MAC-side autonegotiation on each individual port, downshifting, can set the blinking pattern of each of its 4 LEDs, SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection. This patch series adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T, QSGMII link with the MAC, downshifting, HP Auto-MDIX detection and blinking pattern for its 4 LEDs. The GPIO register bank is a set of registers that are common to all PHYs in the package. So any modification in any register of this bank affects all PHYs of the package. If the PHYs haven't been reset before booting the Linux kernel and were configured to use interrupts for e.g. link status updates, it is required to clear the interrupts mask register of all PHYs before being able to use interrupts with any PHY. The first PHY of the package that will be init will take care of clearing all PHYs interrupts mask registers. Thus, we need to keep track of the init sequence in the package, if it's already been done or if it's to be done. Most of the init sequence of a PHY of the package is common to all PHYs in the package, thus we use the SMI broadcast feature which enables us to propagate a write in one register of one PHY to all PHYs in the same package. This patch series adds support for VSC8514 in Microsemi driver(mscc.c) and removes support from Vitesse driver(vitesse.c). v8 - mscc: Added appropriate code using phy_modify() in vsc8514_config_init(). v7 - mscc: Handled return values in vsc8514_config_init(). v6 - mscc: Added proper return value in vsc85xx_csr_ctrl_phy_read(). - mscc: Replaced __mdiobus_write and__mdiobus_read with __phy_write and __phy_read resp. - mscc: Replaced register addresses in 8514_config_init() with proper constants. v5 - mscc: Added return error statements for few function calls. - mscc: Added comments in vsc85xx_csr_ctrl_phy_read() and vsc85xx_csr_ctrl_phy_write() v4 - mscc: Removed features settings - mscc: Removed aneg_done settings. v3 - mscc: Used BIT(x) for PHY_MCB_S6G_WRITE and PHY_MCB_S6G_READ instead of hex. - mscc: Replaced magic numbers with proper constants. - mscc: Handled delays and timeouts at appropriate points. - mscc: Added comments/explanation where requested. v2 - mscc: Sorted variable declarations in reverse christmas tree order. v1 - Added 0/2 file. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Kavya Sree Kotagiri authored
Add support for VSC8514 in Microsemi driver (mscc.c) with more features. Signed-off-by:
Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Signed-off-by:
-
Kavya Sree Kotagiri authored
The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX, 1000BASE-X, can communicate with the MAC via QSGMII. The MAC interface protocol for each port within QSGMII can be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is connecting to supports this functionality. VSC8514 also supports SGMII MAC-side autonegotiation on each individual port, downshifting, can set the blinking pattern of each of its 4 LEDs, SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection. This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T, QSGMII link with the MAC, downshifting, HP Auto-MDIX detection and blinking pattern for its 4 LEDs. The GPIO register bank is a set of registers that are common to all PHYs in the package. So any modification in any register of this bank affects all PHYs of the package. If the PHYs haven't been reset before booting the Linux kernel and were configured to use interrupts for e.g. link status updates, it is required to clear the interrupts mask register of all PHYs before being able to use interrupts with any PHY. The first PHY of the package that will be init will take care of clearing all PHYs interrupts mask registers. Thus, we need to keep track of the init sequence in the package, if it's already been done or if it's to be done. Most of the init sequence of a PHY of the package is common to all PHYs in the package, thus we use the SMI broadcast feature which enables us to propagate a write in one register of one PHY to all PHYs in the same package. Signed-off-by:
Quentin Schulz <quentin.schulz@bootlin.com> Co-developed-by:
-
Jian Shen authored
The default m88e151x LED configuration is 0x1177, used LED[0] for 1000M link, LED[1] for 100M link, and LED[2] for active. But for some boards, which use LED[0] for link, and LED[1] for active, prefer to be 0x1040. To be compatible with this case, this patch defines a new dev_flag, and set it before connect phy in HNS3 driver. When phy initializing, using the new LED configuration if this dev_flag is set. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Florian Fainelli authored
All we do is write the length/status and address bits to a DMA descriptor only to write its contents into on-chip registers right after, eliminate this unnecessary step. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Ido Schimmel authored
When a bridge port is being deleted, do not dereference it later in br_vlan_port_event() as it can result in a use-after-free [1] if the RCU callback was executed before invoking the function. [1] [ 129.638551] ================================================================== [ 129.646904] BUG: KASAN: use-after-free in br_vlan_port_event+0x53c/0x5fd [ 129.654406] Read of size 8 at addr ffff8881e4aa1ae8 by task ip/483 [ 129.663008] CPU: 0 PID: 483 Comm: ip Not tainted 5.1.0-rc5-custom-02265-ga946bd73daac #1383 [ 129.672359] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 [ 129.682484] Call Trace: [ 129.685242] dump_stack+0xa9/0x10e [ 129.689068] print_address_description.cold.2+0x9/0x25e [ 129.694930] kasan_report.cold.3+0x78/0x9d [ 129.704420] br_vlan_port_event+0x53c/0x5fd [ 129.728300] br_device_event+0x2c7/0x7a0 [ 129.741505] notifier_call_chain+0xb5/0x1c0 [ 129.746202] rollback_registered_many+0x895/0xe90 [ 129.793119] unregister_netdevice_many+0x48/0x210 [ 129.803384] rtnl_delete_link+0xe1/0x140 [ 129.815906] rtnl_dellink+0x2a3/0x820 [ 129.844166] rtnetlink_rcv_msg+0x397/0x910 [ 129.868517] netlink_rcv_skb+0x137/0x3a0 [ 129.882013] netlink_unicast+0x49b/0x660 [ 129.900019] netlink_sendmsg+0x755/0xc90 [ 129.915758] ___sys_sendmsg+0x761/0x8e0 [ 129.966315] __sys_sendmsg+0xf0/0x1c0 [ 129.988918] do_syscall_64+0xa4/0x470 [ 129.993032] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 129.998696] RIP: 0033:0x7ff578104b58 ... [ 130.073811] Allocated by task 479: [ 130.077633] __kasan_kmalloc.constprop.5+0xc1/0xd0 [ 130.083008] kmem_cache_alloc_trace+0x152/0x320 [ 130.088090] br_add_if+0x39c/0x1580 [ 130.092005] do_set_master+0x1aa/0x210 [ 130.096211] do_setlink+0x985/0x3100 [ 130.100224] __rtnl_newlink+0xc52/0x1380 [ 130.104625] rtnl_newlink+0x6b/0xa0 [ 130.108541] rtnetlink_rcv_msg+0x397/0x910 [ 130.113136] netlink_rcv_skb+0x137/0x3a0 [ 130.117538] netlink_unicast+0x49b/0x660 [ 130.121939] netlink_sendmsg+0x755/0xc90 [ 130.126340] ___sys_sendmsg+0x761/0x8e0 [ 130.130645] __sys_sendmsg+0xf0/0x1c0 [ 130.134753] do_syscall_64+0xa4/0x470 [ 130.138864] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 130.146195] Freed by task 0: [ 130.149421] __kasan_slab_free+0x125/0x170 [ 130.154016] kfree+0xf3/0x310 [ 130.157349] kobject_put+0x1a8/0x4c0 [ 130.161363] rcu_core+0x859/0x19b0 [ 130.165175] __do_softirq+0x250/0xa26 [ 130.170956] The buggy address belongs to the object at ffff8881e4aa1ae8 which belongs to the cache kmalloc-1k of size 1024 [ 130.184972] The buggy address is located 0 bytes inside of 1024-byte region [ffff8881e4aa1ae8, ffff8881e4aa1ee8) Fixes: 9c0ec2e7 ("bridge: support binding vlan dev link state to vlan member bridge ports") Signed-off-by:Ido Schimmel <idosch@mellanox.com> Cc: Mike Manning <mmanning@vyatta.att-mail.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Mike Manning <mmanning@vyatta.att-mail.com> Signed-off-by:
-
Crag.Wang authored
Without this patch the socket address family sporadically gets wrong value ends up the dev_set_mac_address() fails to set the desired MAC address. Fixes: 25766271 ("r8152: Refresh MAC address during USBDEVFS_RESET") Signed-off-by:
Crag.Wang <crag.wang@dell.com> Reviewed-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Shared buffer improvements This patchset includes two improvements with regards to shared buffer configuration in mlxsw. The first part of this patchset forbids the user from performing illegal shared buffer configuration that can result in unnecessary packet loss. In order to better communicate these configuration failures to the user, extack is propagated from devlink towards drivers. This is done in patches #1-#8. The second part of the patchset deals with the shared buffer configuration of the CPU port. When a packet is trapped by the device, it is sent across the PCI bus to the attached host CPU. From the device's perspective, it is as if the packet is transmitted through the CPU port. While testing traffic directed at the CPU it became apparent that for certain packet sizes and certain burst sizes, the current shared buffer configuration of the CPU port is inadequate and results in packet drops. The configuration is adjusted by patches #9-#14 that create two new pools - ingress & egress - which are dedicated for CPU traffic. ==================== Acked-by:
-
Ido Schimmel authored
Switch the CPU port to use the new dedicated egress pool instead the previously used egress pool which was shared with normal front panel ports. Add per-port quotas for the amount of traffic that can be buffered for the CPU port and also adjust the per-{port, TC} quotas. Signed-off-by:Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
The CPU port is used to transmit traffic that is trapped to the host CPU. It is therefore irrelevant to define ingress quota for it. Add a 'skip_ingress' argument to the function tasked with configuring per-port quotas, so that ingress quotas could be skipped in case the passed local port is the CPU port. Signed-off-by:
-
Ido Schimmel authored
The function is used to set the per-port shared buffer quotas. Currently, these quotas are only set for front panel ports, but a subsequent patch will configure these quotas for the CPU port as well. The configuration required for the CPU port is a bit different than that of the front panel ports, so split the business logic into a separate function which will be called with different parameters for the CPU port. No functional changes intended. Signed-off-by:
-
Ido Schimmel authored
Use the new ingress pool that was added in the previous patch for control packets (e.g., STP, LACP) that are trapped to the CPU. The previous management pool is no longer necessary and therefore its size is set to 0. The maximum quota for traffic towards the CPU is increased to 50% of the free space in the new ingress pool and therefore the reserved space is reduced by half, to 10KB - in both the shared and headroom buffer. This allows for more efficient utilization of the shared buffer as reserved space cannot be used for other purposes. Signed-off-by:
-
Ido Schimmel authored
Packets that are trapped to the CPU are transmitted through the CPU port to the attached host. The CPU port is therefore like any other port and needs to have shared buffer configuration. The maximum quotas configured for the CPU are provided using dynamic threshold and cannot be changed by the user. In order to make sure that these thresholds are always valid, the configuration of the threshold type of these pools is forbidden. Signed-off-by:
-
Ido Schimmel authored
The code currently assumes that ingress pools have lower indices than egress pools. This makes it impossible to add more ingress pools without breaking user configuration that relies on a certain pool index to correspond to an egress pool. Remove such assumptions from the code, so that more ingress pools could be added by subsequent patches. Signed-off-by:
-
Ido Schimmel authored
Commit e83c045e ("mlxsw: spectrum_buffers: Configure MC pool") configured the threshold of the multicast TCs as infinite so that the admission of multicast packets is only depended on per-switch priority threshold. Forbid the user from changing the thresholds of these multicast TCs and their binding to a different pool. Signed-off-by:
-
Ido Schimmel authored
Multicast packets have three egress quotas: * Per egress port * Per egress port and traffic class * Per switch priority The limits on the switch priority are not exposed to the user and specified as dynamic threshold on the first egress pool. Forbid changing the threshold type of the first egress pool so that these limits are always valid. Signed-off-by:
-
Ido Schimmel authored
Commit e83c045e ("mlxsw: spectrum_buffers: Configure MC pool") added a dedicated pool for multicast traffic. The pool is visible to the user so that it would be possible to monitor its occupancy, but its configuration should be forbidden in order to maintain its intended operation. Signed-off-by:
-
Ido Schimmel authored
Subsequent patches are going to need to veto changes in certain TCs' binding and threshold configurations. Add fields to the TC's struct that indicate if the TC can be bound to a different pool and whether its threshold can change and enforce that. Signed-off-by:
-
Ido Schimmel authored
Subsequent patches are going to need to veto changes in certain pools' size and / or threshold type (mode). Add two fields to the pool's struct that indicate if either of these attributes is allowed to change and enforce that. Signed-off-by:
-
Ido Schimmel authored
The pool indices are currently hard coded throughout the code, which makes the code hard to follow and extend. Overcome this by using defines for the pool indices. Signed-off-by:
-
Ido Schimmel authored
Add extack messages to better communicate invalid configuration to the user. Example: # devlink sb pool set pci/0000:01:00.0 pool 0 size 104857600 thtype dynamic Error: mlxsw_spectrum: Exceeded shared buffer size. devlink answers: Invalid argument Signed-off-by:
-
Ido Schimmel authored
Add extack to shared buffer set operations, so that meaningful error messages could be propagated to the user. Signed-off-by:
-
David S. Miller authored
Paul Gortmaker says: ==================== clean up needless use of module infrastructure People can embed modular includes and modular exit functions into code that never use any of it, and they won't get any errors or warnings. Using modular infrastructure in non-modules might seem harmless, but some of the downfalls this leads to are: (1) it is easy to accidentally write unused module_exit removal code (2) it can be misleading when reading the source, thinking a driver can be modular when the Makefile and/or Kconfig prohibit it (3) an unused include of the module.h header file will in turn include nearly everything else; adding a lot to CPP overhead. (4) it gets copied/replicated into other drivers and spreads quickly. As a data point for #3 above, an empty C file that just includes the module.h header generates over 750kB of CPP output. Repeating the same experiment with init.h and the result is less than 12kB; with export.h it is only about 1/2kB; with both it still is less than 12kB. One driver in this series gets the module.h ---> init.h+export.h conversion. Worse, are headers in include/linux that in turn include <linux/module.h> as they can impact a whole fleet of drivers, or a whole subsystem, so special care should be used in order to avoid that. Such headers should only include what they need to be stand-alone; they should not be trying to anticipate the various header needs of their possible end users. In this series, four include/linux headers have module.h removed from them because they don't strictly need it. Then three chunks of net related code have modular infrastructure that isn't used, removed. There are no runtime changes, so the biggest risk is a genuine consumer of module.h content relying on implicitly getting it from one of the include/linux instances removed here - thus resulting in a build fail. With that in mind, allmodconfig build testing was done on x86-64, arm64, x86-32, arm. powerpc, and mips on linux-next (and hence net-next). ==================== Signed-off-by: -
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: net/strparser/Kconfig:config STREAM_PARSER net/strparser/Kconfig: def_bool n ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. For clarity, we change the fcn name mod_init to dev_init at the same time. We replace module.h with init.h and export.h ; the latter since this file exports some syms. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig controlling this code is: bpfilter/Kconfig:menuconfig BPFILTER bpfilter/Kconfig: bool "BPF based packet filtering framework (BPFILTER)" Since it isn't a module, we shouldn't use module_init(). Instead we use device_initcall() - which is exactly what module_init() defaults to for non-modular code/builds. We don't remove <linux/module.h> from the includes since this file does a request_module() and hence is a valid user of that header file, even though it is not modular itself. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: net/Kconfig:config CGROUP_NET_PRIO net/Kconfig: bool "Network priority cgroup" ...meaning that it currently is not being built as a module by anyone, as module support was discontinued in 2014. We delete the MODULE_LICENSE tag since all that information is already contained at the top of the file in the comments. We don't delete module.h from the includes since it was no longer there to begin with. Cc: "David S. Miller" <davem@davemloft.net> Cc: Tejun Heo <tj@kernel.org> Cc: "Rosen, Rami" <rami.rosen@intel.com> Cc: Daniel Wagner <daniel.wagner@bmw-carit.de> Cc: netdev@vger.kernel.org Signed-off-by:
-
Paul Gortmaker authored
Ideally, header files under include/linux shouldn't be adding includes of other headers, in anticipation of their consumers, but just the headers needed for the header itself to pass parsing with CPP. The module.h is particularly bad in this sense, as it itself does include a whole bunch of other headers, due to the complexity of module support. Since tc_ife.h is not going into a module struct looking for specific fields, we can just let it know that module is a struct, just like about 60 other include/linux headers already do. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
Ideally, header files under include/linux shouldn't be adding includes of other headers, in anticipation of their consumers, but just the headers needed for the header itself to pass parsing with CPP. The module.h is particularly bad in this sense, as it itself does include a whole bunch of other headers, due to the complexity of module support. Since fib_notifier.h is not going into a module struct looking for specific fields, we can just let it know that module is a struct, just like about 60 other include/linux headers already do. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
Ideally, header files under include/linux shouldn't be adding includes of other headers, in anticipation of their consumers, but just the headers needed for the header itself to pass parsing with CPP. The module.h is particularly bad in this sense, as it itself does include a whole bunch of other headers, due to the complexity of module support. There doesn't appear to be anything in net/ife.h that is module related, and build coverage doesn't appear to show any other files/drivers relying implicitly on getting it from here. So it appears we are simply free to just remove it in this case. Cc: Yotam Gigi <yotam.gi@gmail.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
Ideally, header files under include/linux shouldn't be adding includes of other headers, in anticipation of their consumers, but just the headers needed for the header itself to pass parsing with CPP. The module.h is particularly bad in this sense, as it itself does include a whole bunch of other headers, due to the complexity of module support. There doesn't appear to be anything in psample.h that is module related, and build coverage doesn't appear to show any other files/drivers relying implicitly on getting it from here. So it appears we are simply free to just remove it in this case. Cc: Yotam Gigi <yotam.gi@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
David Ahern authored
The header contains rtnh_ macros so rename the file accordingly. Allows a later patch to use the nexthop.h name for the new nexthop code. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David Ahern authored
fib6_info_nh_lwt is no longer used; remove it. Signed-off-by:
-
Daniel T. Lee authored
This patch makes trivial whitespace fix to the function tcp_v4_check at include/net/tcp.h file. It has stylistic issue, which is "space required after that ','" and it can be confirmed with ./scripts/checkpatch.pl tool. ERROR: space required after that ',' (ctx:VxV) #29: FILE: include/net/tcp.h:1317: + return csum_tcpudp_magic(saddr,daddr,len,IPPROTO_TCP,base); ^ Signed-off-by:Daniel T. Lee <danieltimlee@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-04-22 The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) allow stack/queue helpers from more bpf program types, from Alban. 2) allow parallel verification of root bpf programs, from Alexei. 3) introduce bpf sysctl hook for trusted root cases, from Andrey. 4) recognize var/datasec in btf deduplication, from Andrii. 5) cpumap performance optimizations, from Jesper. 6) verifier prep for alu32 optimization, from Jiong. 7) libbpf xsk cleanup, from Magnus. 8) other various fixes and cleanups. ==================== Signed-off-by:
-
- 22 Apr, 2019 5 commits
-
-
Daniel Borkmann authored
Alexei Starovoitov says: ==================== Allow the bpf verifier to run in parallel for root. ==================== Acked-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Alexei Starovoitov authored
Drop bpf_verifier_lock for root to avoid being DoS-ed by unprivileged. The BPF verifier is now fully parallel. All unpriv users are still serialized by bpf_verifier_lock to avoid exhausting kernel memory by running N parallel verifications. Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Alexei Starovoitov authored
Move three global variables protected by bpf_verifier_lock into 'struct bpf_verifier_env' to allow parallel verification. Signed-off-by:
-
Alexei Starovoitov authored
Document the verifier limits. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
David Ahern authored
The RTF_ADDRCONF flag filters out routes added by RA's in determining which routes can be appended to an existing one to create a multipath route. Restore the flag check and add a comment to document the RA piece. Fixes: 4e54507a ("ipv6: Simplify rt6_qualify_for_ecmp") Signed-off-by:
-
- 21 Apr, 2019 1 commit
-
-
David Ahern authored
After commit c7a1ce39 ("ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create"), the gateway is no longer filled in for fib6_nh structs in a prefix route. Accordingly, the RTF_ADDRCONF flag check can be dropped from the 'rt6_qualify_for_ecmp'. Further, RTF_DYNAMIC is only set in rt6_info instances, so it can be removed from the check as well. This reduces rt6_qualify_for_ecmp and the mlxsw version to just checking if the nexthop has a gateway which is the real indication of whether entries can be coalesced into a multipath route. Signed-off-by:
-
