- 22 Mar, 2023 15 commits
-
-
Florian Westphal authored
This defaulted to 'y' because before this knob existed the 32bit compat layer was always compiled in if CONFIG_COMPAT was set. 32bit iptables on 64bit kernel isn't common anymore, so remove the default-y now. Signed-off-by:Florian Westphal <fw@strlen.de>
-
Jeremy Sowden authored
nft_masq has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code. Const-qualify the `priv` pointer since we don't need to write through it. Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
-
Jeremy Sowden authored
`nf_nat_redirect_ipv4` takes a `struct nf_nat_ipv4_multi_range_compat`, but converts it internally to a `struct nf_nat_range2`. Change the function to take the latter, factor out the code now shared with `nf_nat_redirect_ipv6`, move the conversion to the xt_REDIRECT module, and update the ipv4 range initialization in the nft_redir module. Replace a bare hex constant for 127.0.0.1 with a macro. Remove `WARN_ON`. `nf_nat_setup_info` calls `nf_ct_is_confirmed`: /* Can't setup nat info for confirmed ct. */ if (nf_ct_is_confirmed(ct)) return NF_ACCEPT; This means that `ct` cannot be null or the kernel will crash, and implies that `ctinfo` is `IP_CT_NEW` or `IP_CT_RELATED`. nft_redir has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code. Const-qualify the `priv` pointer since we don't need to write through it. Assign `priv->flags` to the range instead of OR-ing it in. Set the `NF_NAT_RANGE_PROTO_SPECIFIED` flag once during init, rather than on every eval. Signed-off-by:
-
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>
-
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:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230321065826.2044-1-wsa+renesas@sang-engineering.comSigned-off-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:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-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:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321015746.96994-1-kerneljasonxing@gmail.comSigned-off-by:
-
Arseniy Krasnov authored
Pointer to transport could be checked before allocation of skbuff, thus there is no need to free skbuff when this pointer is NULL. Signed-off-by:
Arseniy Krasnov <AVKrasnov@sberdevices.ru> Reviewed-by:
Bobby Eshleman <bobby.eshleman@bytedance.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/08d61bef-0c11-c7f9-9266-cb2109070314@sberdevices.ruSigned-off-by:
-
Jakub Kicinski authored
Jiri suggests it reads more naturally to skip the explicit array size when possible. When we export the symbol we want to make sure that the size is right but for statics its not needed. Link: https://lore.kernel.org/r/20230321044159.1031040-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: remove some rcu_bh cruft There is no point using rcu_bh variant hoping to free objects faster, especially hen using call_rcu() or kfree_rcu(). Disabling/enabling BH has a non-zero cost, and adds distracting hot spots in kernel profiles eg. in ip6_xmit(). ==================== Link: https://lore.kernel.org/r/20230321040115.787497-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
This helper is no longer used in the tree. Signed-off-by:
-
Eric Dumazet authored
rcu_bh is no longer a win, especially for objects freed with standard call_rcu(). Switch neighbour code to no longer disable BH when not necessary. Signed-off-by:
-
Eric Dumazet authored
struct ip6_flowlabel are rcu managed, and call_rcu() is used to delay fl_free_rcu() after RCU grace period. There is no point disabling BH for pure RCU lookups. Signed-off-by:
-
Tom Rix authored
clang with W=1 reports drivers/net/ethernet/atheros/atl1c/atl1c_main.c:214:20: error: unused function 'atl1c_irq_reset' [-Werror,-Wunused-function] static inline void atl1c_irq_reset(struct atl1c_adapter *adapter) ^ This function is not used, so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
-
- 21 Mar, 2023 16 commits
-
-
Nathan Chancellor authored
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/pasemi/pasemi_mac.c:1665:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = pasemi_mac_start_tx, ^~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of pasemi_mac_start_tx() to match the prototype's to resolve the warning. While PowerPC does not currently implement support for kCFI, it could in the future, which means this warning becomes a fatal CFI failure at run time. Link: https://github.com/ClangBuiltLinux/linux/issues/1750Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20230319-pasemi-incompatible-pointer-types-strict-v1-1-1b9459d8aef0@kernel.orgSigned-off-by:
-
Josef Miegl authored
The Geneve encapsulation, as defined in RFC 8926, has a Protocol Type field, which states the Ethertype of the payload appearing after the Geneve header. Commit 435fe1c0 ("net: geneve: support IPv4/IPv6 as inner protocol") introduced a new IFLA_GENEVE_INNER_PROTO_INHERIT flag that allowed the use of other Ethertypes than Ethernet. However, it did not get rid of a restriction that prohibits receiving payloads other than Ethernet, instead the commit white-listed additional Ethertypes, IPv4 and IPv6. This patch removes this restriction, making it possible to receive any Ethertype as a payload, if the IFLA_GENEVE_INNER_PROTO_INHERIT flag is set. The restriction was set in place back in commit 0b5e8b8e ("net: Add Geneve tunneling protocol driver"), which implemented a protocol layer driver for Geneve to be used with Open vSwitch. The relevant discussion about introducing the Ethertype white-list can be found here: https://lore.kernel.org/netdev/CAEP_g=_1q3ACX5NTHxLDnysL+dTMUVzdLpgw1apLKEdDSWPztw@mail.gmail.com/ <quote> >> + if (unlikely(geneveh->proto_type != htons(ETH_P_TEB))) > > Why? I thought the point of geneve carrying protocol field was to > allow protocols other than Ethernet... is this temporary maybe? Yes, it is temporary. Currently OVS only handles Ethernet packets but this restriction can be lifted once we have a consumer that is capable of handling other protocols. </quote> This white-list was then ported to a generic Geneve netdevice in commit 371bd106 ("geneve: Consolidate Geneve functionality in single module."). Preserving the Ethertype white-list at this point made sense, as the Geneve device could send out only Ethernet payloads anyways. However, now that the Geneve netdevice supports encapsulating other payloads with IFLA_GENEVE_INNER_PROTO_INHERIT and we have a consumer capable of other protocols, it seems appropriate to lift the restriction and allow any Geneve payload to be received. Signed-off-by:
Josef Miegl <josef@miegl.cz> Reviewed-by:
Eyal Birger <eyal.birger@gmail.com> Link: https://lore.kernel.org/r/20230319220954.21834-1-josef@miegl.czSigned-off-by:
-
Álvaro Fernández Rojas authored
BCM63xx RGMII ports require additional configuration in order to work. Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230319220805.124024-1-noltari@gmail.comSigned-off-by:
-
Russell King (Oracle) authored
pcs_get_state() implementations are not supposed to alter an_enabled. Remove this assignment. Fixes: b3591c2a ("net: dsa: qca8k: Switch to PHYLINK instead of PHYLIB") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1pdsE5-00Dl2l-8F@rmk-PC.armlinux.org.ukSigned-off-by:
-
Marek Behún authored
Commit 2c7e46ed ("net: dsa: mv88e6xxx: mask apparently non-existing phys during probing") added non-trivial bus->phy_mask in mv88e6xxx_mdio_register() in order to avoid excessive mdio bus transactions during probing. But the mask is incorrect for switches with non-zero phy_base_addr (such as 88E6341). Fix this. Fixes: 2c7e46ed ("net: dsa: mv88e6xxx: mask apparently non-existing phys during probing") Signed-off-by:
Marek Behún <kabel@kernel.org> Tested-by:
Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20230319140238.9470-1-kabel@kernel.orgSigned-off-by:
-
Tom Rix authored
clang with W=1 reports drivers/net/ethernet/chelsio/cxgb3/sge.c:169:32: error: unused function 'fl_to_qset' [-Werror,-Wunused-function] static inline struct sge_qset *fl_to_qset(const struct sge_fl *q, int qidx) ^ This function is not used, so remove it. Signed-off-by: -
Jakub Kicinski authored
Daniel Golle says: ==================== net: ethernet: mtk_eth_soc: various enhancements This series brings a variety of fixes and enhancements for mtk_eth_soc, adds support for the MT7981 SoC and facilitates sharing the SGMII PCS code between mtk_eth_soc and mt7530. The whole series has been tested on MT7622+MT7531 (BPi-R64), MT7623+MT7530 (BPi-R2), MT7981+GPY211 (GL.iNet GL-MT3000) and MT7986+MT7531 (BPi-R3). On the BananaPi R3 a variete of SFP modules have been tested, all of them (some SGMII with PHY, others 2500Base-X or 1000Base-X without PHY) are working well now, however, some of them need manually disabling of autonegotiation for the link to come up. ==================== Link: https://lore.kernel.org/r/cover.1679230025.git.daniel@makrotopia.orgSigned-off-by:
-
Daniel Golle authored
Implement regmap access wrappers, for now only to be used by the pcs-mtk-lynxi driver. Make use of this external PCS driver and drop the now reduntant implementation in mt7530.c. As a nice side effect the SGMII registers can now also more easily be inspected for debugging via /sys/kernel/debug/regmap. Tested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Tested-by:
Frank Wunderlich <frank-w@public-files.de> Reviewed-by:
-
Daniel Golle authored
Now that we got a PCS driver, use it and remove the now redundant PCS code and it's header macros from the Ethernet driver. Signed-off-by:
-
Daniel Golle authored
The SGMII core found in several MediaTek SoCs is identical to what can also be found in MediaTek's MT7531 Ethernet switch IC. As this has not always been clear, both drivers developed different implementations to deal with the PCS. Recently Alexander Couzens pointed out this fact which lead to the development of this shared driver. Add a dedicated driver, mostly by copying the code now found in the Ethernet driver. The now redundant code will be removed by a follow-up commit. Suggested-by:
Alexander Couzens <lynxis@fe80.eu> Suggested-by:
-
Daniel Golle authored
The PPE units found in MT7622 and newer support packet and byte accounting of hw-offloaded flows. Add support for reading those counters as found in MediaTek's SDK[1]. [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/bc6a6a375c800dc2b80e1a325a2c732d1737df92Tested-by:
-
Daniel Golle authored
Set MDIO bus clock frequency and allow setting a custom maximum frequency from device tree. Reviewed-by:
-
Daniel Golle authored
Add mediatek,pnswap boolean property needed on many boards using the MediaTek MT7981 SoC. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Daniel Golle authored
Convert mediatek,sgmiiisys bindings to DT schema format. Add maintainer Matthias Brugger, no maintainers were listed in the original documentation. As this node is also referenced by the Ethernet controller and used as SGMII PCS add this fact to the description. Move the file to Documentation/devicetree/bindings/net/pcs/ which seems more appropriate given that the great majority of registers are related to SGMII PCS functionality and only one register represents clock bits. Reviewed-by:
-
Daniel Golle authored
Introduce DT bindings for the MT7981 SoC to mediatek,net.yaml. Reviewed-by:
-
Daniel Golle authored
The MediaTek MT7981 SoC comes with two 1G/2.5G SGMII ports, just like MT7986. In addition MT7981 is equipped with a built-in 1000Base-T PHY which can be used with GMAC1. As many MT7981 boards make use of inverting SGMII signal polarity, add new device-tree attribute 'mediatek,pn_swap' to support them. Signed-off-by:
-
- 20 Mar, 2023 9 commits
-
-
Lukas Bulwahn authored
Commit 053fdaa8 ("nfc: mrvl: Move platform_data struct into driver") moves the nfcmrvl.h header file from include/linux/platform_data to the driver's directory, but misses to adjust MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Just remove the file entry in NFC SUBSYSTEM, as the new location of the code is already covered by another pattern in that section. Fixes: 053fdaa8 ("nfc: mrvl: Move platform_data struct into driver") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Now that rtl_hw_aspm_clkreq_enable() is a no-op for chip versions < 32, we can consolidate disabling ASPM before EPHY access in rtl_hw_start(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: reuse SMSC PHY driver functionality in the meson-gxl PHY driver The Amlogic Meson internal PHY's have the same register layout as certain SMSC PHY's (also for non-c22-standard registers). This seems to be more than just coincidence. Apparently they also need the same workaround for EDPD mode (energy detect power down). Therefore let's reuse SMSC PHY driver functionality in the meson-gxl PHY driver. ==================== Signed-off-by: -
Heiner Kallweit authored
The Amlogic Meson internal PHY's have the same register layout as certain SMSC PHY's (also for non-c22-standard registers). This seems to be more than just coincidence. Apparently they also need the same workaround for EDPD mode (energy detect power down). Therefore let's reuse SMSC PHY driver functionality in the meson-gxl PHY driver. Tested with a G12A internal PHY. I don't have GXL test hw, therefore I replace only the callbacks that are identical in the SMSC PHY driver. Signed-off-by:
-
Heiner Kallweit authored
The Amlogic Meson internal PHY's have the same register layout as certain SMSC PHY's (also for non-c22-standard registers). This seems to be more than just coincidence. Apparently they also need the same workaround for EDPD mode (energy detect power down). Therefore let's export SMSC PHY driver functionality for use by the meson-gxl PHY driver. Signed-off-by:
Chris Healy <healych@amazon.com> Signed-off-by:
-
David S. Miller authored
Colin Foster says: ==================== add support for ocelot external ports This is the start of part 3 of what is hopefully a 3-part series to add Ethernet switching support to Ocelot chips. Part 1 of the series (A New Chip) added general support for Ocelot chips that were controlled externally via SPI. https://lore.kernel.org/all/20220815005553.1450359-1-colin.foster@in-advantage.com/ Part 2 of the series (The Ethernet Strikes Back) added DSA Ethernet support for ports 0-3, which are the four copper ports that are internal to the chip. https://lore.kernel.org/all/20230127193559.1001051-1-colin.foster@in-advantage.com/ Part 3 will, at a minimum, add support for ports 4-7, which are configured to use QSGMII to an external phy (Return Of The QSGMII). With any luck, and some guidance, support for SGMII, SFPs, etc. will also be part of this series. V1 was submitted as an RFC - and that was rightly so. I suspected I wasn't doing something right, and that was certainly the case. V2 is much cleaner, so hopefully upgrading it to PATCH status is welcomed. Thanks to Russell and Vladimir for correcting my course from V1. In V1 I included a device tree snippet. I won't repeat that here, but I will include a boot log snippet, in case it is of use: ==================== Signed-off-by:
-
Colin Foster authored
The VSC7512 has four ports with internal phys that are already supported. There are additional ports that can be configured to work with external phys. Add support for these additional ethernet ports. Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
-
Colin Foster authored
Ports for Ocelot devices (VSC7511, VSC7512, VSC7513 and VSC7514) support external phys. When external phys are used, additional configuration on each port is required to enable QSGMII mode and set external phy modes. Add a configurable hook into these routines, so the external ports can be used. Signed-off-by:
-
Colin Foster authored
If a user of the Felix driver has a port running in SGMII / QSGMII mode, it will need to utilize phylink_mac_config(). Add this configurability. Signed-off-by:
-
