- 23 Mar, 2023 35 commits
-
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: fully support IPA v5.0 At long last, add the IPA and GSI register definitions, and the configuration data required to support IPA v5.0. This enables IPA support for the Qualcomm SDX65 SoC. The first version of this series had build errors due to a non-existent source file being required. This version addresses that by changing how required files are specified in the Makefile. Note that the second patch has some warnings about lines starting with spaces; those spaces align text with the open parenthesis on the previous line. ==================== Link: https://lore.kernel.org/r/20230321182644.2143990-1-elder@linaro.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Add the configuration data required for IPA v5.0, which is used in the SDX65 SoC. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Add the definitions of GSI register offsets and fields for IPA v5.0. These are used for the SDX65 SoC. Increase the maximum channel and event ring counts supported by the driver, so those implemented by the SDX65 are supported. Signed-off-by:
-
Alex Elder authored
Add the definitions of IPA register offsets and fields for IPA v5.0. These are used for the SDX65 SoC. In the Makefile, split IPA_VERSIONS to use IPA_REG_VERSIONS and IPA_DATA_VERSIONS instead, to allow IPA register definitions for a new version to be added separate from the IPA data. Rename GSI_IPA_VERSIONS to be GSI_REG_VERSIONS for consistency. Signed-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== Quirk for OEM SFP-2.5G-T copper module Frank Wunderlich reports that this copper module requires a quirk in order to function - in that the module needs to use 2500base-X. Moreover, negotiation must be disabled. An example of this device would be: https://www.optcore.net/product/sfp-2g-t-gen ==================== Link: https://lore.kernel.org/r/ZBniMlTDZJQ242DP@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Add a quirk for a copper SFP that identifies itself as "OEM" "SFP-2.5G-T". This module's PHY is inaccessible, and can only run at 2500base-X with the host without negotiation. Add a quirk to enable the 2500base-X interface mode with 2500base-T support, and disable autonegotiation. Reported-by:
Frank Wunderlich <frank-w@public-files.de> Tested-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Russell King (Oracle) authored
Allow SFP quirks to override the Autoneg, Pause and Asym_Pause bits in the support mask. Some modules have an inaccessible PHY on which is only accessible via 2500base-X without Autonegotiation. We therefore want to be able to clear the Autoneg bit. Rearrange sfp_parse_support() to allow a SFP modes quirk to override this bit. Tested-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: remove some skb_mac_header assumptions Historically, we tried o maintain skb_mac_header available in most of networking paths. When reaching ndo_start_xmit() handlers, skb_mac_header() should always be skb->data. With recent additions of skb_mac_header_was_set() and DEBUG_NET_WARN_ON_ONCE() in skb_mac_header(), we can attempt to remove our reliance on skb_mac_header in TX paths. When this effort completes we will remove skb_reset_mac_header() from __dev_queue_xmit() and replace it by skb_unset_mac_header() on DEBUG_NET builds. ==================== Link: https://lore.kernel.org/r/20230321164519.1286357-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
tcf_mirred_act() and tcf_mpls_act() can use skb_network_offset() instead of relying on skb_mac_header(). Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
-
Eric Dumazet authored
We want to remove our use of skb_mac_header() in tx paths, eg remove skb_reset_mac_header() from __dev_queue_xmit(). Idea is that ndo_start_xmit() can get the mac header simply looking at skb->data. Signed-off-by:
-
Eric Dumazet authored
We want to remove our use of skb_mac_header() in tx paths, eg remove skb_reset_mac_header() from __dev_queue_xmit(). Idea is that ndo_start_xmit() can get the mac header simply looking at skb->data. Signed-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== Remove phylink_state's an_enabled member Now that all the fixes and correctness patches have been merged, it is time to switch the two users that make use of .an_enabled to check the Autoneg bit in the advertising mask, and finally remove the .an_enabled member. The first two patches remove the last uses of .an_enabled, which are in DPAA2 and XPCS. The final patch removes the member. ==================== Link: https://lore.kernel.org/r/ZBnT6yW9UY1sAsiy@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
The Autoneg bit in the advertising bitmap and state->an_enabled are always identical. state->an_enabled is now no longer used by any drivers, so lets kill this duplication. Signed-off-by:
-
Russell King (Oracle) authored
The Autoneg bit in the advertising bitmap and state->an_enabled are always identical. Thus, we will be removing state->an_enabled. Use the Autoneg bit in the advertising bitmap to indicate whether autonegotiation should be used, rather than using the an_enabled member which will be going away. Signed-off-by:
-
Russell King (Oracle) authored
The Autoneg bit in the advertising bitmap and state->an_enabled are always identical. Thus, we will be removing state->an_enabled. Use the Autoneg bit in the advertising bitmap to indicate whether autonegotiation should be used, rather than using the an_enabled member which will be going away. This means we use the same condition as phylink_mii_c22_pcs_config(). Signed-off-by:
-
Nick Child authored
When requesting a TX queue at a given index, warn on out-of-bounds referencing if the index is greater than the allocated number of queues. Specifically, since this function is used heavily in the networking stack use DEBUG_NET_WARN_ON_ONCE to avoid executing a new branch on every packet. Signed-off-by:
Nick Child <nnac123@linux.ibm.com> Link: https://lore.kernel.org/r/20230321150725.127229-2-nnac123@linux.ibm.comSigned-off-by:
-
Nick Child authored
When setting the XPS value of a TX queue, warn the user once if the index of the queue is greater than the number of allocated TX queues. Previously, this scenario went uncaught. In the best case, it resulted in unnecessary allocations. In the worst case, it resulted in out-of-bounds memory references through calls to `netdev_get_tx_queue( dev, index)`. Therefore, it is important to inform the user but not worth returning an error and risk downing the netdevice. Signed-off-by:
Piotr Raczynski <piotr.raczynski@intel.com> Link: https://lore.kernel.org/r/20230321150725.127229-1-nnac123@linux.ibm.comSigned-off-by:
-
Jakub Kicinski authored
Siddharth Vadapalli says: ==================== Add CPSWxG SGMII support for J7200 and J721E This series adds support to configure the CPSW Ethernet Switch in SGMII mode, using the am65-cpsw-nuss driver. SGMII mode is supported by the CPSWxG instances on TI's J7200 and J721E SoCs. Thus, SGMII mode is added in the list of extra_modes for the appropriate compatibles corresponding to the aforementioned SoCs. Additionally, the method of setting the supported interface via struct "phylink_config" is simplified by converting the IF/ELSE statements to SWITCH statements. ==================== Link: https://lore.kernel.org/r/20230321111958.2800005-1-s-vadapalli@ti.comSigned-off-by:
-
Siddharth Vadapalli authored
TI's J721E SoC supports SGMII mode with the CPSW9G instance of the CPSW Ethernet Switch. Thus, enable it by adding SGMII mode to the extra_modes member of the "j721e_cpswxg_pdata" SoC data. Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by:
-
Siddharth Vadapalli authored
TI's J7200 SoC supports SGMII mode with the CPSW5G instance of the CPSW Ethernet Switch. Thus, enable it by adding SGMII mode to the extra_modes member of the "j7200_cpswxg_pdata" SoC data. Signed-off-by:
-
Siddharth Vadapalli authored
Add support for configuring the CPSW Ethernet Switch in SGMII mode. Depending on the SoC, allow selecting SGMII mode as a supported interface, based on the compatible used. Signed-off-by:
-
Siddharth Vadapalli authored
Convert the existing IF/ELSE statement based approach of setting the supported_interfaces member of struct "phylink_config", to SWITCH statements. This will help scale to newer PHY-MODES as well as newer compatibles. Signed-off-by:
-
Tom Rix authored
clang with W=1 reports drivers/net/ethernet/cavium/liquidio/request_manager.c:43:19: error: unused function 'IQ_INSTR_MODE_64B' [-Werror,-Wunused-function] static inline int IQ_INSTR_MODE_64B(struct octeon_device *oct, int iq_no) ^ This function and its macro wrapper are not used, so remove them. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxJakub Kicinski authored
Leon Romanovsky says: ==================== Extend packet offload to fully support libreswan The following patches are an outcome of Raed's work to add packet offload support to libreswan [1]. The series includes: * Priority support to IPsec policies * Statistics per-SA (visible through "ip -s xfrm state ..." command) * Support to IKE policy holes * Fine tuning to acquire logic. [1] https://github.com/libreswan/libreswan/pull/986 Link: https://lore.kernel.org/all/cover.1678714336.git.leon@kernel.org * tag 'ipsec-libreswan-mlx5' of https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5e: Update IPsec per SA packets/bytes count net/mlx5e: Use one rule to count all IPsec Tx offloaded traffic net/mlx5e: Support IPsec acquire default SA net/mlx5e: Allow policies with reqid 0, to support IKE policy holes xfrm: copy_to_user_state fetch offloaded SA packets/bytes statistics xfrm: add new device offload acquire flag net/mlx5e: Use chains for IPsec policy priority offload net/mlx5: fs_core: Allow ignore_flow_level on TX dest net/mlx5: fs_chains: Refactor to detach chains from tc usage ==================== Link: https://lore.kernel.org/r/20230320094722.1009304-1-leon@kernel.orgSigned-off-by:
-
Rob Herring authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for bindings/net/can Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # for bindings/net/toshiba,visconti-dwmac.yaml Reviewed-by: Heiko Stuebner <heiko@sntech.de> #rockchip Link: https://lore.kernel.org/r/20230320233758.2918972-1-robh@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Álvaro Fernández Rojas says: ==================== net: dsa: b53: configure 6318 and 63268 RGMII ports BCM6318 and BCM63268 need special configuration for their RGMII ports, so we need to be able to identify them as a special BCM63xx switch. In the meantime, let's add some missing BCM63xx SoCs to B53 MMAP device table. This should be applied after "net: dsa: b53: add support for BCM63xx RGMIIs": https://patchwork.kernel.org/project/netdevbpf/patch/20230319220805.124024-1-noltari@gmail.com/ Álvaro Fernández Rojas (4): dt-bindings: net: dsa: b53: add more 63xx SoCs net: dsa: b53: mmap: add more 63xx SoCs net: dsa: b53: mmap: allow passing a chip ID net: dsa: b53: add BCM63268 RGMII configuration .../devicetree/bindings/net/dsa/brcm,b53.yaml | 3 ++ drivers/net/dsa/b53/b53_common.c | 19 +++++++++++- drivers/net/dsa/b53/b53_mmap.c | 29 +++++++++++++++---- drivers/net/dsa/b53/b53_priv.h | 9 +++++- drivers/net/dsa/b53/b53_regs.h | 1 + 5 files changed, 53 insertions(+), 8 deletions(-) ==================== Link: https://lore.kernel.org/r/20230321173359.251778-1-noltari@gmail.comSigned-off-by:
-
Álvaro Fernández Rojas authored
BCM63268 requires special RGMII configuration to work. Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by:
-
Álvaro Fernández Rojas authored
BCM6318 and BCM63268 SoCs require a special handling for their RGMIIs, so we should be able to identify them as a special BCM63xx switch. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by:
-
Wolfram Sang authored
phy_disconnect() calls phy_detach() which already clears 'phydev' if it is attached to a struct net_device. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Jakub Kicinski authored
Pavan Chebbi says: ==================== bnxt PTP optimizations Patches to 1. Enforce software based freq adjustments only on shared PHC NIC 2. A prerequisite change to expand capability storage field to accommodate more Firmware reported capabilities ==================== Link: https://lore.kernel.org/r/20230321144449.15289-1-pavan.chebbi@broadcom.comSigned-off-by:
-
Pavan Chebbi authored
Currently driver performs software based frequency adjustments when RTC capability is not discovered or when in shared PHC mode. But there may be some old firmware versions that still support hardware freq adjustments without RTC capability being exposed. In this situation driver will use non-realtime mode even on single host NICs. Hence enforce software frequency adjustments only when running in shared PHC mode. Make suitable changes for cyclecounter for the same. Signed-off-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Acked-by:
Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by:
-
Pavan Chebbi authored
Driver uses the flag BNXT_FLAG_MULTI_HOST to determine whether to use non-realtime mode PHC when running on a multi host NIC. However when ptp initializes on a NIC with shared PHC, we still don't have this flag set yet because HWRM_FUNC_QCFG is issued much later. Move the ptp initialization code after we have issued func_qcfg. The next patch will use the BNXT_FLAG_MULTI_HOST flag during PTP initialization. Signed-off-by:
-
Pavan Chebbi authored
The current fw_cap field (u32) has run out of bits to save any new capability. Change the field to u64. Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Reviewed-by:
-
- 22 Mar, 2023 5 commits
-
-
Xiaoyan Li authored
Add option to compute and send SHA256 over data sent (-i). This is to ensure the correctness of data received. Data is randomly populated from /dev/urandom. Tested: ./tcp_mmap -s -z -i ./tcp_mmap -z -H $ADDR -i SHA256 is correct ./tcp_mmap -s -i ./tcp_mmap -H $ADDR -i SHA256 is correct Signed-off-by:
Coco Li <lixiaoyan@google.com> Reviewed-by:
Paolo Abeni <pabeni@redhat.com>
-
Xiaoyan Li authored
When compound pages are enabled, although the mm layer still returns an array of page pointers, a subset (or all) of them may have the same page head since a max 180kb skb can span 2 hugepages if it is on the boundary, be a mix of pages and 1 hugepage, or fit completely in a hugepage. Instead of referencing page head on all page pointers, use page length arithmetic to only call page head when referencing a known different page head to avoid touching a cold cacheline. Tested: See next patch with changes to tcp_mmap Correntess: On a pair of separate hosts as send with MSG_ZEROCOPY will force a copy on tx if using loopback alone, check that the SHA on the message sent is equivalent to checksum on the message received, since the current program already checks for the length. echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages ./tcp_mmap -s -z ./tcp_mmap -H $DADDR -z SHA256 is correct received 2 MB (100 % mmap'ed) in 0.005914 s, 2.83686 Gbit cpu usage user:0.001984 sys:0.000963, 1473.5 usec per MB, 10 c-switches Performance: Run neper between adjacent hosts with the same config tcp_stream -Z --skip-rx-copy -6 -T 20 -F 1000 --stime-use-proc --test-length=30 Before patch: stime_end=37.670000 After patch: stime_end=30.310000 Signed-off-by:
-
Wolfram Sang authored
It had a purpose back in the days, but today we have a handy helper. Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
-
Grygorii Strashko authored
When the CPTS clock is synced/adjusted by running linuxptp (ptp4l/phc2sys), it will cause the TSN EST schedule to drift away over time. This is because the schedule is driven by the EstF periodic counter whose pulse length is defined in ref_clk cycles and it does not automatically sync to CPTS clock. _______ _| ^ expected cycle start time boundary _______________ _|_|___|_| ^ EstF drifted away -> direction To fix it, the same PPM adjustment has to be applied to EstF as done to the PHC CPTS clock, in order to correct the TSN EST cycle length and keep them in sync. Drifted cycle: AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373877017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374877017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375877023 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376377018 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376877018 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230377377018 Stable cycle: AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863196375473 Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Roger Quadros <rogerq@kernel.org> Acked-by:
Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20230321062600.2539544-1-s-vadapalli@ti.comSigned-off-by:
-
Jason Xing authored
Sometimes we need to know which one of backlog queue can be exactly long enough to cause some latency when debugging this part is needed. Thus, we can then separate the display of both. Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
-
