- 06 Jun, 2019 6 commits
-
-
Zhu Yanjun authored
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>
-
David S. Miller authored
Biao Huang says: ==================== complete dwmac-mediatek driver and fix flow control issue Changes in v2: patch#1: there is no extra action in mediatek_dwmac_remove, remove it v1: This series mainly complete dwmac-mediatek driver: 1. add power on/off operations for dwmac-mediatek. 2. disable rx watchdog to reduce rx path reponding time. 3. change the default value of tx-frames from 25 to 1, so ptp4l will test pass by default. and also fix the issue that flow control won't be disabled any more once being enabled. ==================== Signed-off-by: -
Biao Huang authored
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: 477286b5 ("stmmac: add GMAC4 core support") Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
Biao Huang authored
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 authored
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 authored
add Ethernet power on/off operations in init/exit flow. Signed-off-by:
-
- 05 Jun, 2019 34 commits
-
-
Enrico Weigelt authored
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:
-
Enrico Weigelt authored
IS_ERR() already calls unlikely(), so this extra unlikely() call around IS_ERR() is not needed. Signed-off-by:
-
Enrico Weigelt authored
IS_ERR() already calls unlikely(), so this extra unlikely() call around IS_ERR() is not needed. Signed-off-by:
-
Enrico Weigelt authored
IS_ERR() already calls unlikely(), so this extra likely() call around the !IS_ERR() is not needed. Signed-off-by:
-
Enrico Weigelt authored
IS_ERR() already calls unlikely(), so this extra likely() call around the !IS_ERR() is not needed. Signed-off-by:
-
Gustavo A. R. Silva authored
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:
-
Lihong Yang authored
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:
-
Lihong Yang authored
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:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2019-06-05 This series contains updates to mainly ixgbe, with a few updates to i40e, net, ice and hns2 driver. Jan adds support for tracking each queue pair for whether or not AF_XDP zero copy is enabled. Also updated the ixgbe driver to use the netdev-provided umems so that we do not need to contain these structures in our own adapter structure. William Tu provides two fixes for AF_XDP statistics which were causing incorrect counts. Jake reduces the PTP transmit timestamp timeout from 15 seconds to 1 second, which is still well after the maximum expected delay. Also fixes an issues with the PTP SDP pin setup which was not properly aligning on a full second, so updated the code to account for the cyclecounter multiplier and simplify the code to make the intent of the calculations more clear. Updated the function header comments to help with the code documentation. Added support for SDP/PPS output for x550 devices, which is slightly different than x540 devices that currently have this support. Anirudh adds a new define for Link Layer Discovery Protocol to the networking core, so that drivers do not have to create and use their own definitions. In addition, update all the drivers currently defining their own LLDP define to use the new networking core define. ==================== Signed-off-by: -
Kangjie Lu authored
If ixgbevf_write_msg_read_ack fails, return its error code upstream Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Tested-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Jacob Keller authored
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:
-
Anirudh Venkataramanan authored
Remove references to HCLGE_MAC_ETHERTYPE_LLDP and use ETH_P_LLDP instead. Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
-
Jeff Kirsher authored
Instead of using a local define for the LLDP ethertype, use the kernel define ETH_P_LLDP. Signed-off-by: -
Anirudh Venkataramanan authored
Remove references to IXGBE_ETH_P_LLD and use ETH_P_LLDP instead. Signed-off-by:
-
Anirudh Venkataramanan authored
Remove references to I40E_ETH_P_LLDP and use ETH_P_LLDP instead. Signed-off-by:
-
Anirudh Venkataramanan authored
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:
-
Jacob Keller authored
This function was missing a documentation comment. Add one now. Signed-off-by:
-
Jacob Keller authored
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 authored
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 authored
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:
-
William Tu authored
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:
-
William Tu authored
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:
-
Jan Sokolowski authored
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:
-
Jan Sokolowski authored
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:
-
Fabio Estevam authored
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 authored
Heiner Kallweit says: ==================== r8169: factor out firmware handling 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. v2: - fix small whitespace issue in patch 2 ==================== Signed-off-by: -
Heiner Kallweit authored
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:
-
Heiner Kallweit authored
In preparation of factoring out firmware handling rename r8169.c to r8169_main.c. Signed-off-by:
-
Randy Dunlap authored
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 authored
Rasmus Villemoes says: ==================== net: dsa: mv88e6xxx: support for mv88e6250 This adds support for the mv88e6250 chip. Initially based on the mv88e6240, this time around, I've been through each ->ops callback and checked that it makes sense, either replacing with a 6250 specific variant or dropping it if no equivalent functionality seems to exist for the 6250. Along the way, I found a few oddities in the existing code, mostly sent as separate patches/questions. The one relevant to the 6250 is the ieee_pri_map callback, where the existing mv88e6085_g1_ieee_pri_map() is actually wrong for many of the existing users. I've put the mv88e6250_g1_ieee_pri_map() patch first in case some of the existing chips get switched over to use that and it is deemed important enough for -stable. v4: - fix style issue in 1/10 - add Andrew's reviewed-by to 1,6,7,8,9,10. v3: - rebase on top of net-next/master - add reviewed-bys to patches unchanged from v2 (2,3,4,5) - add 6250-specific ->ieee_pri_map, ->port_set_speed, ->port_link_state (1,6,7) - in addition, use mv88e6065_phylink_validate for ->phylink_validate, and don't implement ->port_get_cmode, ->port_set_jumbo_size, ->port_disable_learn_limit, ->rmu_disable - drop ptp support - add patch adding the compatible string to the DT binding (9) - add small refactoring patch (10) v2: - rebase on top of net-next/master - add reviewed-by to two patches unchanged from v1 (2,3) - add separate watchdog_ops ==================== Signed-off-by: -
Rasmus Villemoes authored
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:
-
Rasmus Villemoes authored
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:
-
Rasmus Villemoes authored
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: -
Rasmus Villemoes authored
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:
-
