- 23 Mar, 2023 39 commits
-
-
David S. Miller authored
Petr Machata says: ==================== net: Allow changing IPv4 address protocol IPv4 and IPv6 addresses can be assigned a protocol value that indicates the provenance of the IP address. The attribute is modeled after ip route protocols, and essentially allows the administrator or userspace stack to tag addresses in some way that makes sense to the actor in question. When IP address protocol field was added in commit 47f0bd50 ("net: Add new protocol attribute to IP addresses"), the semantics included the ability to change the protocol for IPv6 addresses, but not for IPv4 addresses. It seems this was not deliberate, but rather by accident. One particular use case is tagging the addresses differently depending on whether the routing stack should advertise them or not. Without support for protocol replacement, this can not be done. In this patchset, extend IPv4 to allow changing the protocol defined at an address (in patch #1). Then in patches #2 and #3 add selftest coverage for ip address protocols. Currently the kernel simply ignores the new value. Thus allowing the replacement changes the observable behavior. However, since IPv6 already behaves like this anyway, and since the feature as such is relatively new, it seems like the change is safe to make. An example session with the feature in action: bash-5.2# ip address add dev d 192.0.2.1/28 proto 0xab bash-5.2# ip address show dev d 4: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/28 scope global proto 0xab d valid_lft forever preferred_lft forever bash-5.2# ip address replace dev d 192.0.2.1/28 proto 0x11 bash-5.2# ip address show dev d 4: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/28 scope global proto 0x11 d valid_lft forever preferred_lft forever ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Add coverage of "ip address {add,replace} ... proto" support. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Extract the list of all tests into a variable, ALL_TESTS. Then assume the environment variable TESTS holds the list of tests to actually run, falling back to ALL_TESTS if TESTS is empty. This is the same interface that forwarding selftests use to make the set of tests to run configurable. In addition to this, allow setting the value explicitly through a command line option "-t" along the lines of what fib_nexthops.sh does. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
When IP address protocol field was added in commit 47f0bd50 ("net: Add new protocol attribute to IP addresses"), the semantics included the ability to change the protocol for IPv6 addresses, but not for IPv4 addresses. It seems this was not deliberate, but rather by accident. A userspace that wants to change the protocol of an address might drop and recreate the address, but that disrupts routing and is just impractical. So in this patch, when an IPv4 address is replaced (through RTM_NEWADDR request with NLM_F_REPLACE flag), update the proto at the address to the one given in the request, or zero if none is given. This matches the behavior of IPv6. Previously, any new value given was simply ignored. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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 <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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 <edumazet@google.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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 <edumazet@google.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Link: https://lore.kernel.org/r/20230321150725.127229-1-nnac123@linux.ibm.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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 <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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 <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321184811.1827306-1-trix@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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 <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
Álvaro Fernández Rojas authored
BCM63268 requires special RGMII configuration to work. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Á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 <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Álvaro Fernández Rojas authored
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Álvaro Fernández Rojas authored
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230321131745.27688-1-wsa+renesas@sang-engineering.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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 <pavan.chebbi@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 22 Mar, 2023 1 commit
-
-
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: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230321081202.2370275-2-lixiaoyan@google.comSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-