aboutsummaryrefslogtreecommitdiffstats
path: root/Kconfig (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-06-05net: rds: add per rds connection cache statisticsZhu Yanjun2-0/+4
The variable cache_allocs is to indicate how many frags (KiB) are in one rds connection frag cache. The command "rds-info -Iv" will output the rds connection cache statistics as below: " RDS IB Connections: LocalAddr RemoteAddr Tos SL LocalDev RemoteDev 1.1.1.14 1.1.1.14 58 255 fe80::2:c903:a:7a31 fe80::2:c903:a:7a31 send_wr=256, recv_wr=1024, send_sge=8, rdma_mr_max=4096, rdma_mr_size=257, cache_allocs=12 " This means that there are about 12KiB frag in this rds connection frag cache. Since rds.h in rds-tools is not related with the kernel rds.h, the change in kernel rds.h does not affect rds-tools. rds-info in rds-tools 2.0.5 and 2.0.6 is tested with this commit. It works well. Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: stmmac: dwmac4: fix flow control issueBiao Huang1-2/+6
Current dwmac4_flow_ctrl will not clear GMAC_RX_FLOW_CTRL_RFE/GMAC_RX_FLOW_CTRL_RFE bits, so MAC hw will keep flow control on although expecting flow control off by ethtool. Add codes to fix it. Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: stmmac: modify default value of tx-framesBiao Huang1-1/+1
the default value of tx-frames is 25, it's too late when passing tstamp to stack, then the ptp4l will fail: ptp4l -i eth0 -f gPTP.cfg -m ptp4l: selected /dev/ptp0 as PTP clock ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l: port 1: link up ptp4l: timed out while polling for tx timestamp ptp4l: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: port 1: send peer delay response failed ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l tests pass when changing the tx-frames from 25 to 1 with ethtool -C option. It should be fine to set tx-frames default value to 1, so ptp4l will pass by default. Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: stmmac: dwmac-mediatek: disable rx watchdogBiao Huang1-0/+1
disable rx watchdog for dwmac-mediatek, then the hw will issue a rx interrupt once receiving a packet, so the responding time for rx path will be reduced. Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: stmmac: dwmac-mediatek: enable Ethernet power domainBiao Huang1-0/+7
add Ethernet power on/off operations in init/exit flow. Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05drivers: net: vxlan: drop unneeded likely() call around IS_ERR()Enrico Weigelt1-1/+1
IS_ERR() already calls unlikely(), so this extra likely() call around the !IS_ERR() is not needed. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: ipv6: drop unneeded likely() call around IS_ERR()Enrico Weigelt2-2/+2
IS_ERR() already calls unlikely(), so this extra unlikely() call around IS_ERR() is not needed. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: ipv4: drop unneeded likely() call around IS_ERR()Enrico Weigelt4-4/+4
IS_ERR() already calls unlikely(), so this extra unlikely() call around IS_ERR() is not needed. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: openvswitch: drop unneeded likely() call around IS_ERR()Enrico Weigelt1-1/+1
IS_ERR() already calls unlikely(), so this extra likely() call around the !IS_ERR() is not needed. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: socket: drop unneeded likely() call around IS_ERR()Enrico Weigelt1-1/+1
IS_ERR() already calls unlikely(), so this extra likely() call around the !IS_ERR() is not needed. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05nfp: flower: use struct_size() helperGustavo A. R. Silva1-2/+1
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct nfp_tun_active_tuns { ... struct route_ip_info { __be32 ipv4; __be32 egress_port; __be32 extra[2]; } tun_info[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(struct nfp_tun_active_tuns) + sizeof(struct route_ip_info) * count with: struct_size(payload, tun_info, count) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05i40e: Check and set the PF driver state first in i40e_ndo_set_vf_macLihong Yang1-5/+5
The PF driver state flag __I40E_VIRTCHNL_OP_PENDING needs to be checked and set at the beginning of i40e_ndo_set_vf_mac. Otherwise, if there are error conditions before it, the flag will be cleared unexpectedly by this function to cause potential race conditions. Hence move the check to the top of this function. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05i40e: Do not check VF state in i40e_ndo_get_vf_configLihong Yang1-4/+2
The VF configuration returned in i40e_ndo_get_vf_config is already stored by the PF. There is no dependency on any specific state of the VF to return the configuration. Drop the check against I40E_VF_STATE_INIT since it is not needed. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: ixgbevf: fix a missing check of ixgbevf_write_msg_read_ackKangjie Lu1-3/+2
If ixgbevf_write_msg_read_ack fails, return its error code upstream Signed-off-by: Kangjie Lu <kjlu@umn.edu> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: implement support for SDP/PPS output on X550 hardwareJacob Keller2-5/+108
Similar to the X540 hardware, enable support for generating a 1pps output signal on SDP0. This support is slightly different to the X540 hardware, because of the register layout changes. First, the system time register is now represented in 'cycles' and 'billions of cycles'. Second, we need to also program the TSSDP register, as well as the ESDP register. Third, the clock output uses only FREQOUT, instead of a full 64bit value for the output clock period. Finally, we have to use the ST0 bit instead of the SYNCLK bit in the TSAUXC register. This support should work even for the hardware with a higher frequency clock, as it carefully takes into account the multiply and shift of the cycle counter used. We also set the pps configuration to 1, since we now support generating a pulse per second output. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05net: hns3: Use LLDP ethertype define ETH_P_LLDPAnirudh Venkataramanan2-2/+1
Remove references to HCLGE_MAC_ETHERTYPE_LLDP and use ETH_P_LLDP instead. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ice: Use LLDP ethertype define ETH_P_LLDPJeff Kirsher1-3/+1
Instead of using a local define for the LLDP ethertype, use the kernel define ETH_P_LLDP. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: Use LLDP ethertype define ETH_P_LLDPAnirudh Venkataramanan2-3/+1
Remove references to IXGBE_ETH_P_LLD and use ETH_P_LLDP instead. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05i40e: Use LLDP ethertype define ETH_P_LLDPAnirudh Venkataramanan2-4/+2
Remove references to I40E_ETH_P_LLDP and use ETH_P_LLDP instead. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05net: Add a define for LLDP ethertypeAnirudh Venkataramanan1-0/+1
Add a new define ETH_P_LLDP for Link Layer Discovery Protocol (LLDP) ethertype. Suggested-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: add a kernel documentation comment for ixgbe_ptp_get_ts_configJacob Keller1-0/+9
This function was missing a documentation comment. Add one now. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: use 'cc' instead of 'hw_cc' for local variableJacob Keller1-3/+3
The ixgbe_ptp.c file sometimes uses hw_cc as the local variable for the cycle counter in ixgbe_ptp_read_X550. However, we use just 'cc' as a local variable for this by convention else where in the file. Convert this lone usage of 'hw_cc' into just the shorter 'cc' name to match the other read functions in the file. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: fix PTP SDP pin setup on X540 hardwareJacob Keller1-29/+42
The function ixgbe_ptp_setup_sdp_X540 attempts to program a software defined pin, in order to generate a pulse-per-second output on SDP 0. It does work to generate the output, but does not align the output on the full second. Additionally, it does not take into account the cyclecounter multiplier. This leads to somewhat confusing code which is likely to be incorrect if blindly copied to another hardware type. Update this code to account for the cyclecounter multiplier, and to directly use timecounter_read. This change ensures that the SDP output will align properly on a full second, and makes the intent of the calculations a bit more clear. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: reduce PTP Tx timestamp timeout to 1 secondJacob Keller1-1/+1
Previously we waited for a whole 15 seconds before we cleared the Tx timestamp state. This is astronomically long compared to the worst case timings expected by our devices. In addition, this is longer than the wait in ptp4l when it detects a fault (caused by missing Tx timestamps). Thus, reduce the timer to only 1 second, which is well after the maximum expected delay. This should reduce user frustration when a timestamp does get dropped for some reason. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: fix AF_XDP tx packet countWilliam Tu1-0/+1
The total_packets count at ixgbe_clean_xdp_tx_irq is always zero when testing with xdpsock -t -N. Set the gso_segs to 1 to make the tx packet count correct. Signed-off-by: William Tu <u9012063@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: fix AF_XDP tx byte countWilliam Tu1-1/+0
The tx bytecount is done twice. When running './xdpsock -t -N -i eth3' and 'ip -s link show dev eth3' The avg packet size is 120 instead of 60. So remove the extra one. Signed-off-by: William Tu <u9012063@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: remove umem from adapterJan Sokolowski2-71/+19
As current implementation of netdev already contains and provides umems for us, we no longer have the need to contain these structures in ixgbe_adapter. Refactor the code to operate on netdev-provided umems. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05ixgbe: add tracking of AF_XDP zero-copy state for each queue pairJan Sokolowski3-1/+11
Here, we add a bitmap to the ixgbe_adapter that tracks if a certain queue pair has been "zero-copy enabled" via the ndo_bpf. The bitmap is used in ixgbe_xsk_umem, and enables zero-copy if and only if XDP is enabled, the corresponding qid in the bitmap is set, and the umem is non-NULL; Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-06-05net: fec_ptp: Use dev_err() instead of pr_err()Fabio Estevam1-1/+1
dev_err() is more appropriate for printing error messages inside drivers, so switch to dev_err(). Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05r8169: factor out firmware handlingHeiner Kallweit4-241/+274
Let's factor out firmware handling into a separate source code file. This simplifies reading the code and makes clearer what the interface between driver and firmware handling is. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05r8169: rename r8169.c to r8169_main.cHeiner Kallweit2-0/+1
In preparation of factoring out firmware handling rename r8169.c to r8169_main.c. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-05net: ethernet: mediatek: fix mtk_eth_soc build errors & warningsRandy Dunlap1-2/+2
Fix build errors in Mediatek mtk_eth_soc driver. It looks like these 3 source files were meant to be linked together since 2 of them are library-like functions, but they are currently being built as 3 loadable modules. Fixes these build errors: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/mediatek/mtk_eth_path.o WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/mediatek/mtk_sgmii.o ERROR: "mtk_sgmii_init" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! ERROR: "mtk_setup_hw_path" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! ERROR: "mtk_sgmii_setup_mode_force" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! ERROR: "mtk_sgmii_setup_mode_an" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! ERROR: "mtk_w32" [drivers/net/ethernet/mediatek/mtk_eth_path.ko] undefined! ERROR: "mtk_r32" [drivers/net/ethernet/mediatek/mtk_eth_path.ko] undefined! This changes the loadable module name from mtk_eth_soc to mtk_eth. I didn't see a way to leave it as mtk_eth_soc. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Sean Wang <sean.wang@mediatek.com> Cc: John Crispin <blogic@openwrt.org> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Nelson Chang <nelson.chang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: refactor mv88e6352_g1_resetRasmus Villemoes1-13/+1
The new mv88e6250_g1_reset() is identical to mv88e6352_g1_reset() except for the call of mv88e6352_g1_wait_ppu_polling(), so refactor the 6352 version in term of the 6250 one. No functional change. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04dt-bindings: net: dsa: marvell: add "marvell,mv88e6250" compatible stringRasmus Villemoes1-2/+5
The mv88e6250 has port_base_addr 0x8 or 0x18 (depending on configuration pins), so it constitutes a new family and hence needs its own compatible string. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: add support for mv88e6250Rasmus Villemoes5-0/+104
This adds support for the Marvell 88E6250. I've checked that each member in the ops-structure makes sense, and basic switchdev functionality works fine. It uses the new dual_chip option, and since its port registers start at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to introduce a new compatible string in order for the auto-identification in mv88e6xxx_detect() to work. The chip has four per port 16-bits statistics registers, two of which correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should this be easy...). Wiring up those four statistics seems to require introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones. The chip does have ptp support, and the existing mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work out-of-the-box, but for simplicity (and lack of testing) I'm eliding this. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: implement port_link_state for mv88e6250Rasmus Villemoes2-0/+77
The mv88e6250 has a rather different way of reporting the link, speed and duplex status. A simple difference is that the link bit is bit 12 rather than bit 11 of the port status register. It gets more complicated for speed and duplex, which do not have separate fields. Instead, there's a four-bit PortMode field, and decoding that depends on whether it's a phy or mii port. For the phy ports, only four of the 16 values have defined meaning; the rest are called "reserved", so returning {SPEED,DUPLEX}_UNKNOWN seems reasonable. For the mii ports, most possible values are documented (0x3 and 0x5 are reserved), but I'm unable to make sense of them all. Since the bits simply reflect the Px_MODE[3:0] configuration pins, just support the subset that I'm certain about. Support for other setups can be added later. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: implement port_set_speed for mv88e6250Rasmus Villemoes2-0/+13
The data sheet also mentions the possibility of selecting 200 Mbps for the MII ports (ports 5 and 6) by setting the ForceSpd field to 0x2 (aka MV88E6065_PORT_MAC_CTL_SPEED_200). However, there's a note that "actual speed is determined by bit 8 above", and flipping back a page, one finds that bits 13:8 are reserved... So without further information on what bit 8 means, let's stick to supporting just 10 and 100 Mbps on all ports. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: implement watchdog_ops for mv88e6250Rasmus Villemoes2-0/+40
The MV88E6352_G2_WDOG_CTL_* bits almost, but not quite, describe the watchdog control register on the mv88e6250. Among those actually referenced in the code, only QC_ENABLE differs (bit 6 rather than bit 5). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250Rasmus Villemoes2-0/+62
These are almost identical to the 6185 variants, but have fewer bits for the FID. Bit 10 of the VTU_OP register (offset 0x05) is the VidPolicy bit, which one should probably preserve in mv88e6xxx_g1_vtu_op(), instead of always writing a 0. However, on the 6352 family, that bit is located at bit 12 in the VTU FID register (offset 0x02), and is always unconditionally cleared by the mv88e6xxx_g1_vtu_fid_write() function. Since nothing in the existing driver seems to know or care about that bit, it seems reasonable to not add the boilerplate to preserve it for the 6250 (which would require adding a chip-specific vtu_op function, or adding chip-quirks to the existing one). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: prepare mv88e6xxx_g1_atu_op() for the mv88e6250Rasmus Villemoes1-1/+4
All the currently supported chips have .num_databases either 256 or 4096, so this patch does not change behaviour for any of those. The mv88e6250, however, has .num_databases == 64, and it does not put the upper two bits in ATU control 13:12, but rather in ATU Operation 9:8. So change the logic to prepare for supporting mv88e6250. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: introduce support for two chips using direct smi addressingRasmus Villemoes2-1/+30
The 88e6250 (as well as 6220, 6071, 6070, 6020) do not support multi-chip (indirect) addressing. However, one can still have two of them on the same mdio bus, since the device only uses 16 of the 32 possible addresses, either addresses 0x00-0x0F or 0x10-0x1F depending on the ADDR4 pin at reset [since ADDR4 is internally pulled high, the latter is the default]. In order to prepare for supporting the 88e6250 and friends, introduce mv88e6xxx_info::dual_chip to allow having a non-zero sw_addr while still using direct addressing. Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04net: dsa: mv88e6xxx: add mv88e6250_g1_ieee_pri_mapRasmus Villemoes2-0/+8
Quite a few of the existing supported chips that use mv88e6085_g1_ieee_pri_map as ->ieee_pri_map (including, incidentally, mv88e6085 itself) actually have a reset value of 0xfa50 in the G1_IEEE_PRI register. The data sheet for the mv88e6095, however, does describe a reset value of 0xfa41. So rather than changing the value in the existing callback, introduce a new variant with the 0xfa50 value. That will be used by the upcoming mv88e6250, and existing chips can be switched over one by one, preferably double-checking both the data sheet and actual hardware in each case - if anybody actually feels this is important enough to care. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04vmxnet3: turn off lro when rxcsum is disabledRonak Doshi3-2/+16
Currently, when rx csum is disabled, vmxnet3 driver does not turn off lro, which can cause performance issues if user does not turn off lro explicitly. This patch adds fix_features support which is used to turn off LRO whenever RXCSUM is disabled. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Rishi Mehta <rmehta@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04rocker: Fail attempts to use routes with nexthop objectsDavid Ahern1-0/+4
Fail attempts to use nexthop objects with routes until support can be properly added. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04mlx5: Fail attempts to use routes with nexthop objectsDavid Ahern1-0/+4
Fail attempts to use nexthop objects with routes until support can be properly added. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04mlxsw: Fail attempts to use routes with nexthop objectsDavid Ahern1-0/+14
Fail attempts to use nexthop objects with routes until support can be properly added. Signed-off-by: David Ahern <dsahern@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04ipv6: Plumb support for nexthop object in a fib6_infoDavid Ahern8-36/+260
Add struct nexthop and nh_list list_head to fib6_info. nh_list is the fib6_info side of the nexthop <-> fib_info relationship. Since a fib6_info referencing a nexthop object can not have 'sibling' entries (the old way of doing multipath routes), the nh_list is a union with fib6_siblings. Add f6i_list list_head to 'struct nexthop' to track fib6_info entries using a nexthop instance. Update __remove_nexthop_fib to walk f6_list and delete fib entries using the nexthop. Add a few nexthop helpers for use when a nexthop is added to fib6_info: - nexthop_fib6_nh - return first fib6_nh in a nexthop object - fib6_info_nh_dev moved to nexthop.h and updated to use nexthop_fib6_nh if the fib6_info references a nexthop object - nexthop_path_fib6_result - similar to ipv4, select a path within a multipath nexthop object. If the nexthop is a blackhole, set fib6_result type to RTN_BLACKHOLE, and set the REJECT flag Update the fib6_info references to check for nh and take a different path as needed: - rt6_qualify_for_ecmp - if a fib entry uses a nexthop object it can NOT be coalesced with other fib entries into a multipath route - rt6_duplicate_nexthop - use nexthop_cmp if either fib6_info references a nexthop - addrconf (host routes), RA's and info entries (anything configured via ndisc) does not use nexthop objects - fib6_info_destroy_rcu - put reference to nexthop object - fib6_purge_rt - drop fib6_info from f6i_list - fib6_select_path - update to use the new nexthop_path_fib6_result when fib entry uses a nexthop object - rt6_device_match - update to catch use of nexthop object as a blackhole and set fib6_type and flags. - ip6_route_info_create - don't add space for fib6_nh if fib entry is going to reference a nexthop object, take a reference to nexthop object, disallow use of source routing - rt6_nlmsg_size - add space for RTA_NH_ID - add rt6_fill_node_nexthop to add nexthop data on a dump As with ipv4, most of the changes push existing code into the else branch of whether the fib entry uses a nexthop object. Update the nexthop code to walk f6i_list on a nexthop deleted to remove fib entries referencing it. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04ipv4: Plumb support for nexthop object in a fib_infoDavid Ahern5-36/+229
Add 'struct nexthop' and nh_list list_head to fib_info. nh_list is the fib_info side of the nexthop <-> fib_info relationship. Add fi_list list_head to 'struct nexthop' to track fib_info entries using a nexthop instance. Add __remove_nexthop_fib and add it to __remove_nexthop to walk the new list_head and mark those fib entries as dead when the nexthop is deleted. Add a few nexthop helpers for use when a nexthop is added to fib_info: - nexthop_cmp to determine if 2 nexthops are the same - nexthop_path_fib_result to select a path for a multipath 'struct nexthop' - nexthop_fib_nhc to select a specific fib_nh_common within a multipath 'struct nexthop' Update existing fib_info_nhc to use nexthop_fib_nhc if a fib_info uses a 'struct nexthop', and mark fib_info_nh as only used for the non-nexthop case. Update the fib_info functions to check for fi->nh and take a different path as needed: - free_fib_info_rcu - put the nexthop object reference - fib_release_info - remove the fib_info from the nexthop's fi_list - nh_comp - use nexthop_cmp when either fib_info references a nexthop object - fib_info_hashfn - use the nexthop id for the hashing vs the oif of each fib_nh in a fib_info - fib_nlmsg_size - add space for the RTA_NH_ID attribute - fib_create_info - verify nexthop reference can be taken, verify nexthop spec is valid for fib entry, and add fib_info to fi_list for a nexthop - fib_select_multipath - use the new nexthop_path_fib_result to select a path when nexthop objects are used - fib_table_lookup - if the 'struct nexthop' is a blackhole nexthop, treat it the same as a fib entry using 'blackhole' The bulk of the changes are in fib_semantics.c and most of that is moving the existing change_nexthops into an else branch. Update the nexthop code to walk fi_list on a nexthop deleted to remove fib entries referencing it. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04ipv4: Prepare for fib6_nh from a nexthop objectDavid Ahern7-37/+69
Convert more IPv4 code to use fib_nh_common over fib_nh to enable routes to use a fib6_nh based nexthop. In the end, only code not using a nexthop object in a fib_info should directly access fib_nh in a fib_info without checking the famiy and going through fib_nh_common. Those functions will be marked when it is not directly evident. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04ipv4: Use accessors for fib_info nexthop dataDavid Ahern12-80/+132
Use helpers to access fib_nh and fib_nhs fields of a fib_info. Drop the fib_dev macro which is an alias for the first nexthop. Replacements: fi->fib_dev --> fib_info_nh(fi, 0)->fib_nh_dev fi->fib_nh --> fib_info_nh(fi, 0) fi->fib_nh[i] --> fib_info_nh(fi, i) fi->fib_nhs --> fib_info_num_path(fi) where fib_info_nh(fi, i) returns fi->fib_nh[nhsel] and fib_info_num_path returns fi->fib_nhs. Move the existing fib_info_nhc to nexthop.h and define the new ones there. A later patch adds a check if a fib_info uses a nexthop object, and defining the helpers in nexthop.h avoid circular header dependencies. After this all remaining open coded references to fi->fib_nhs and fi->fib_nh are in: - fib_create_info and helpers used to lookup an existing fib_info entry, and - the netdev event functions fib_sync_down_dev and fib_sync_up. The latter two will not be reused for nexthops, and the fib_create_info will be updated to handle a nexthop in a fib_info. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.