- 15 Dec, 2023 40 commits
-
-
Tobias Waldekranz authored
Report the applicable subset of an mv88e6xxx port's counters using ethtool's standardized "rmon" counter group. Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
Chips in this family only have one set of histogram counters, which can be used to count ingressing and/or egressing traffic. mv88e6xxx has, up until this point, kept the hardware default of counting both directions. In the mean time, standard counter group support has been added to ethtool. Via that interface, drivers may report ingress-only and egress-only histograms separately - but not combined. In order for mv88e6xxx to maximize amount of diagnostic information that can be exported via standard interfaces, we opt to limit the histogram counters to ingress traffic only. Which will allow us to export them via the standard "rmon" group in an upcoming commit. The reason for choosing ingress-only over egress-only, is to be compatible with RFC2819 (RMON MIB). Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Tobias Waldekranz authored
Report the applicable subset of an mv88e6xxx port's counters using ethtool's standardized "eth-mac" counter group. Reviewed-by:
-
Tobias Waldekranz authored
With the upcoming standard counter group support, we are no longer reading out the whole set of counters, but rather mapping a subset to the requested group. Therefore, create an enum with an ID for each stat, such that mv88e6xxx_hw_stats[] can be subscripted with a human-readable ID corresponding to the counter's name. Reviewed-by:
-
Tobias Waldekranz authored
mv88e6xxx_get_stats, which collects stats from various sources, expects all callees to return the number of stats read. If an error occurs, 0 should be returned. Prevent future mishaps of this kind by updating the return type to reflect this contract. Reviewed-by:
-
Tobias Waldekranz authored
This change contains no functional change. We simply push the hardware specific stats logic to a function reading a single counter, rather than the whole set. This is a preparatory change for the upcoming standard ethtool statistics support (i.e. "eth-mac", "eth-ctrl" etc.). Reviewed-by:
-
Tobias Waldekranz authored
This is more consistent with the driver's general structure. Reviewed-by:
-
David S. Miller authored
Eric Dumazet says: ==================== net: optmem_max changes optmem_max default value is too small for tx zerocopy workloads. First patch increases default from 20KB to 128 KB, which is the value we have used for seven years. Second patch makes optmem_max sysctl per netns. Last patch tweaks two tests accordingly. ==================== Signed-off-by: -
Eric Dumazet authored
/proc/sys/net/core/optmem_max is now per netns, change two tests that were saving/changing/restoring its value on the parent netns. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Eric Dumazet authored
optmem_max being used in tx zerocopy, we want to be able to control it on a netns basis. Following patch changes two tests. Tested: oqq130:~# cat /proc/sys/net/core/optmem_max 131072 oqq130:~# echo 1000000 >/proc/sys/net/core/optmem_max oqq130:~# cat /proc/sys/net/core/optmem_max 1000000 oqq130:~# unshare -n oqq130:~# cat /proc/sys/net/core/optmem_max 131072 oqq130:~# exit logout oqq130:~# cat /proc/sys/net/core/optmem_max 1000000 Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Eric Dumazet authored
For many years, /proc/sys/net/core/optmem_max default value on a 64bit kernel has been 20 KB. Regular usage of TCP tx zerocopy needs a bit more. Google has used 128KB as the default value for 7 years without any problem. Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: CFF flood mode: NVE underlay configuration Recently, support for CFF flood mode (for Compressed FID Flooding) was added to the mlxsw driver. The most recent patchset has a detailed coverage of what CFF is and what has changed and how: https://lore.kernel.org/netdev/cover.1701183891.git.petrm@nvidia.com/ In CFF flood mode, each FID allocates a handful (in our implementation two or three) consecutive PGT entries. One entry holds the flood vector for unknown-UC traffic, one for MC, one for BC. To determine how to look up flood vectors, the CFF flood mode uses a concept of flood profiles, which are IDs that reference mappings from traffic types to offsets. In the case of CFF flood mode, the offset in question is applied to the PGT address configured at a FID. The same mechanism is used by NVE underlay for flooding. Again the profile ID and the traffic type determine the offset to apply, this time to KVD address used to look up flooding entries. Since mlxsw configures NVE underlay flood the same regardless of traffic type, only one offset was ever needed: the zero, which is the default, and thus no explicit configuration was needed. Now that CFF uses profiles as well, it would be better to configure the profile used by NVE explicitly, to make the configuration visible in the source code. In this patchset, add the register support (in patch #1), add a new traffic type to refer to "any traffic at all" (in patch #2) and finally configure the NVE profile explicitly for FIDs (in patch #3). So far, the implicitly configured flood profile was the ID 0. With this patchset, it changes to 3, leaving the 0 free to allow us to spot missed configuration. ==================== Signed-off-by: -
Petr Machata authored
The NVE flood profile is used for determining of offset applied to KVD address for NVE flood. We currently do not set it, leaving it at the default value of 0. That is not an issue: all the traffic-type-to-offset mappings (as configured by SFFP) default to offset of 0. This is what we need anyway, as mlxsw only allocates a single KVD entry for NVE underlay. The field is only relevant on Spectrum-2 and above. So to be fully consistent, we should split the existing controlled ops to Spectrum-1 and Spectrum>1 variants, with only the latter setting the field. But that seems like a lot of overhead for a single field whose meaning is "everything is the default". So instead pretend that the NVE flood profile does not exist in the controlled flood mode, like we have so far, and only set it when flood mode is CFF. Setting this at all serves dual purpose. First, it is now clear which profile belongs to NVE, because in the CFF mode, we have multiple users. This should prevent bugs in flood profile management. Second, using specifically non-zero value means there will be no valid uses of the profile 0, which we can therefore use as a sentinel. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Petr Machata authored
Flood profiles have been used prior to CFF support for NVE underlay. Like is the case with FID flooding, an NVE profile describes at which offset a datum is located given traffic type. mlxsw currently only ever uses one KVD entry for NVE lookup, i.e. regardless of traffic type, the offset is always zero. To be able to describe this, add a traffic type enumerator describing "any traffic type". Signed-off-by:
-
Petr Machata authored
The field is used for setting a flood profile for lookup of KVD entry for NVE underlay. As the other uses of flood profile, this references a traffic type-to-offset mapping, except here it is not applied to PGT offsets, but KVD offsets. Signed-off-by:
-
David S. Miller authored
Christian Marangi says: ==================== net: phy: at803x: additional cleanup for qca808x This small series is a preparation for the big code split. While the qca808x code is waiting to be reviwed and merged, we can further cleanup and generalize shared functions between at803x and qca808x. With these last 2 patch everything is ready to move the driver to a dedicated directory and split the code by creating a library module for the few shared functions between the 2 driver. Eventually at803x can be further cleaned and generalized but everything will be already self contained and related only to at803x family of PHYs. ==================== Signed-off-by: -
Christian Marangi authored
Rework read specific status function to be more generic. The function apply different speed mask based on the PHY ID. Make it more generic by adding an additional arg to pass the specific speed (ss) mask and use the provided mask to parse the speed value. This is needed to permit an easier deatch of qca808x code from the at803x driver. Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Christian Marangi authored
Move specific qca808x config_aneg to dedicated function to permit easier split of qca808x portion from at803x driver. Signed-off-by:
-
David S. Miller authored
Arseniy Krasnov says: ==================== send credit update during setting SO_RCVLOWAT DESCRIPTION This patchset fixes old problem with hungup of both rx/tx sides and adds test for it. This happens due to non-default SO_RCVLOWAT value and deferred credit update in virtio/vsock. Link to previous old patchset: https://lore.kernel.org/netdev/39b2e9fd-601b-189d-39a9-914e5574524c@sberdevices.ru/ Here is what happens step by step: TEST INITIAL CONDITIONS 1) Vsock buffer size is 128KB. 2) Maximum packet size is also 64KB as defined in header (yes it is hardcoded, just to remind about that value). 3) SO_RCVLOWAT is default, e.g. 1 byte. STEPS SENDER RECEIVER 1) sends 128KB + 1 byte in a single buffer. 128KB will be sent, but for 1 byte sender will wait for free space at peer. Sender goes to sleep. 2) reads 64KB, credit update not sent 3) sets SO_RCVLOWAT to 64KB + 1 4) poll() -> wait forever, there is only 64KB available to read. So in step 4) receiver also goes to sleep, waiting for enough data or connection shutdown message from the sender. Idea to fix it is that rx kicks tx side to continue transmission (and may be close connection) when rx changes number of bytes to be woken up (e.g. SO_RCVLOWAT) and this value is bigger than number of available bytes to read. I've added small test for this, but not sure as it uses hardcoded value for maximum packet length, this value is defined in kernel header and used to control deferred credit update. And as this is not available to userspace, I can't control test parameters correctly (if one day this define will be changed - test may become useless). Head for this patchset is: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=9bab51bd662be4c3ebb18a28879981d69f3ef15a Link to v1: https://lore.kernel.org/netdev/20231108072004.1045669-1-avkrasnov@salutedevices.com/ Link to v2: https://lore.kernel.org/netdev/20231119204922.2251912-1-avkrasnov@salutedevices.com/ Link to v3: https://lore.kernel.org/netdev/20231122180510.2297075-1-avkrasnov@salutedevices.com/ Link to v4: https://lore.kernel.org/netdev/20231129212519.2938875-1-avkrasnov@salutedevices.com/ Link to v5: https://lore.kernel.org/netdev/20231130130840.253733-1-avkrasnov@salutedevices.com/ Link to v6: https://lore.kernel.org/netdev/20231205064806.2851305-1-avkrasnov@salutedevices.com/ Link to v7: https://lore.kernel.org/netdev/20231206211849.2707151-1-avkrasnov@salutedevices.com/ Link to v8: https://lore.kernel.org/netdev/20231211211658.2904268-1-avkrasnov@salutedevices.com/ Link to v9: https://lore.kernel.org/netdev/20231214091947.395892-1-avkrasnov@salutedevices.com/ Changelog: v1 -> v2: * Patchset rebased and tested on new HEAD of net-next (see hash above). * New patch is added as 0001 - it removes return from SO_RCVLOWAT set callback in 'af_vsock.c' when transport callback is set - with that we can set 'sk_rcvlowat' only once in 'af_vsock.c' and in future do not copy-paste it to every transport. It was discussed in v1. * See per-patch changelog after ---. v2 -> v3: * See changelog after --- in 0003 only (0001 and 0002 still same). v3 -> v4: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v4 -> v5: * Change patchset tag 'RFC' -> 'net-next'. * See per-patch changelog after ---. v5 -> v6: * New patch 0003 which sends credit update during reading bytes from socket. * See per-patch changelog after ---. v6 -> v7: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v7 -> v8: * See per-patch changelog after ---. v8 -> v9: * Patchset rebased and tested on new HEAD of net-next (see hash above). * Add 'Fixes' tag for the current 0002. * Reorder patches by moving two fixes first. v9 -> v10: * Squash 0002 and 0003 and update commit message in result. ==================== Signed-off-by: -
Arseniy Krasnov authored
Both tests are almost same, only differs in two 'if' conditions, so implemented in a single function. Tests check, that credit update message is sent: 1) During setting SO_RCVLOWAT value of the socket. 2) When number of 'rx_bytes' become smaller than SO_RCVLOWAT value. Signed-off-by:
Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Arseniy Krasnov authored
Send credit update message when SO_RCVLOWAT is updated and it is bigger than number of bytes in rx queue. It is needed, because 'poll()' will wait until number of bytes in rx queue will be not smaller than O_RCVLOWAT, so kick sender to send more data. Otherwise mutual hungup for tx/rx is possible: sender waits for free space and receiver is waiting data in 'poll()'. Rename 'set_rcvlowat' callback to 'notify_set_rcvlowat' and set 'sk->sk_rcvlowat' only in one place (i.e. 'vsock_set_rcvlowat'), so the transport doesn't need to do it. Fixes: b89d882d ("vsock/virtio: reduce credit update messages") Signed-off-by:
-
Arseniy Krasnov authored
Add one more condition for sending credit update during dequeue from stream socket: when number of bytes in the rx queue is smaller than SO_RCVLOWAT value of the socket. This is actual for non-default value of SO_RCVLOWAT (e.g. not 1) - idea is to "kick" peer to continue data transmission, because we need at least SO_RCVLOWAT bytes in our rx queue to wake up user for reading data (in corner case it is also possible to stuck both tx and rx sides, this is why 'Fixes' is used). Fixes: b89d882d ("vsock/virtio: reduce credit update messages") Signed-off-by:
-
Leone Fernando authored
In order to support IP_PKTINFO on those packets, we need to call ipv4_pktinfo_prepare. When sending mrouted/pimd daemons a cache report IGMP msg, it is unnecessary to set dst on the newly created skb. It used to be necessary on older versions until commit d826eb14 ("ipv4: PKTINFO doesnt need dst reference") which changed the way IP_PKTINFO struct is been retrieved. Changes from v1: 1. Undo changes in ipv4_pktinfo_prepare function. use it directly and copy the control block. Fixes: d826eb14 ("ipv4: PKTINFO doesnt need dst reference") Signed-off-by:
Leone Fernando <leone4fernando@gmail.com> Reviewed-by:
-
Konstantin Taranov authored
This patch allows to assign and poll more than one EQ on the same msix index. It is achieved by introducing a list of attached EQs in each IRQ context. It also removes the existing msix_index map that tried to ensure that there is only one EQ at each msix_index. This patch exports symbols for creating EQs from other MANA kernel modules. Signed-off-by:
Konstantin Taranov <kotaranov@microsoft.com> Signed-off-by:
-
Suman Ghosh authored
As per the existing implementation, there exists a race between finding a multicast/mirror group entry and deleting that entry. The group lock was taken and released independently by rvu_nix_mcast_find_grp_elem() function. Which is incorrect and group lock should be taken during the entire operation of group updation/deletion. This patch fixes the same. Fixes: 51b2804c ("octeontx2-af: Add new mbox to support multicast/mirror offload") Signed-off-by:
Suman Ghosh <sumang@marvell.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2023-12-13 Preparation for mlx5e socket direct feature. Socket direct will allow multiple PF devices attached to different NUMA nodes but sharing the same physical port. The following series is a small refactoring series in preparation to support socket direct in the following submission. Highlights: - Define required device registers and bits related to socket direct - Flow steering re-arrangements - Generalize TX objects (TISs) and store them in a common object, will be useful in the next series for per function object management. - Decouple raw CQ objects from their parent netdev priv - Prepare devcom for Socket Direct device group discovery. Please see the individual patches for more information. ==================== Signed-off-by: -
David S. Miller authored
FUJITA Tomonori says: ==================== Rust abstractions for network PHY drivers No functional change since v10; only comment and commit log updates. This patchset adds Rust abstractions for phylib. It doesn't fully cover the C APIs yet but I think that it's already useful. I implement two PHY drivers (Asix AX88772A PHYs and Realtek Generic FE-GE). Seems they work well with real hardware. The first patch introduces Rust bindings for phylib. The second patch adds a macro to declare a kernel module for PHYs drivers. The third adds the Rust ETHERNET PHY LIBRARY entry to MAINTAINERS file; adds the binding file and me as a maintainer (as Andrew Lunn suggested) with Trevor Gross as a reviewer. The last patch introduces the Rust version of Asix PHY driver, drivers/net/phy/ax88796b.c. The features are equivalent to the C version. You can choose C (by default) or Rust version on kernel configuration. v11: - adds Andrew, Alice, and Trevor's Reviewed-by - comment update v10: https://lore.kernel.org/netdev/20231210234924.1453917-1-fujita.tomonori@gmail.com/T/ - adds Trevor's SoB to the third patch - adds Benno's Reviewed-by to the second patch v9: https://lore.kernel.org/netdev/20231205.124531.842372711631366729.fujita.tomonori@gmail.com/T/ - adds a workaround to access to a bit field in phy_device - fixes a comment typo v8: https://lore.kernel.org/netdev/20231123050412.1012252-1-fujita.tomonori@gmail.com/ - updates the safety comments on Device and its related code - uses _phy_start_aneg instead of phy_start_aneg - drops the patch for enum synchronization - moves Sync From Registration to DriverVTable - fixes doctest errors - minor cleanups v7: https://lore.kernel.org/netdev/20231026001050.1720612-1-fujita.tomonori@gmail.com/T/ - renames get_link() to is_link_up() - improves the macro format - improves the commit log in the third patch - improves comments v6: https://lore.kernel.org/netdev/20231025.090243.1437967503809186729.fujita.tomonori@gmail.com/T/ - improves comments - makes the requirement of phy_drivers_register clear - fixes Makefile of the third patch v5: https://lore.kernel.org/all/20231019.094147.1808345526469629486.fujita.tomonori@gmail.com/T/ - drops the rustified-enum option, writes match by hand; no *risk* of UB - adds Miguel's patch for enum checking - moves CONFIG_RUST_PHYLIB_ABSTRACTIONS to drivers/net/phy/Kconfig - adds a new entry for this abstractions in MAINTAINERS - changes some of Device's methods to take &mut self - comment improvment v4: https://lore.kernel.org/netdev/20231012125349.2702474-1-fujita.tomonori@gmail.com/T/ - split the core patch - making Device::from_raw() private - comment improvement with code update - commit message improvement - avoiding using bindings::phy_driver in public functions - using an anonymous constant in module_phy_driver macro v3: https://lore.kernel.org/netdev/20231011.231607.1747074555988728415.fujita.tomonori@gmail.com/T/ - changes the base tree to net-next from rust-next - makes this feature optional; only enabled with CONFIG_RUST_PHYLIB_BINDINGS=y - cosmetic code and comment improvement - adds copyright v2: https://lore.kernel.org/netdev/20231006094911.3305152-2-fujita.tomonori@gmail.com/T/ - build failure fix - function renaming v1: https://lore.kernel.org/netdev/20231002085302.2274260-3-fujita.tomonori@gmail.com/T/ ==================== Signed-off-by:
-
FUJITA Tomonori authored
This is the Rust implementation of drivers/net/phy/ax88796b.c. The features are equivalent. You can choose C or Rust version kernel configuration. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by:
Trevor Gross <tmgross@umich.edu> Reviewed-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Alice Ryhl <aliceryhl@google.com> Signed-off-by:
-
FUJITA Tomonori authored
Adds me as a maintainer and Trevor as a reviewer. The files are placed at rust/kernel/ directory for now but the files are likely to be moved to net/ directory once a new Rust build system is implemented. Signed-off-by:
-
FUJITA Tomonori authored
This macro creates an array of kernel's `struct phy_driver` and registers it. This also corresponds to the kernel's `MODULE_DEVICE_TABLE` macro, which embeds the information for module loading into the module binary file. A PHY driver should use this macro. Signed-off-by:
-
FUJITA Tomonori authored
This patch adds abstractions to implement network PHY drivers; the driver registration and bindings for some of callback functions in struct phy_driver and many genphy_ functions. This feature is enabled with CONFIG_RUST_PHYLIB_ABSTRACTIONS=y. This patch enables unstable const_maybe_uninit_zeroed feature for kernel crate to enable unsafe code to handle a constant value with uninitialized data. With the feature, the abstractions can initialize a phy_driver structure with zero easily; instead of initializing all the members by hand. It's supposed to be stable in the not so distant future. Link: https://github.com/rust-lang/rust/pull/116218Signed-off-by:
-
Andrew Halaney authored
Currently a MDIO bus is created if the devicetree description is either: 1. Not fixed-link 2. fixed-link but contains a MDIO bus as well The "1" case above isn't always accurate. If there's a phy-handle, it could be referencing a phy on another MDIO controller's bus[1]. In this case, where the MDIO bus is not described at all, currently stmmac will make a MDIO bus and scan its address space to discover phys (of which there are none). This process takes time scanning a bus that is known to be empty, delaying time to complete probe. There are also a lot of upstream devicetrees[2] that expect a MDIO bus to be created, scanned for phys, and the first one found connected to the MAC. This case can be inferred from the platform description by not having a phy-handle && not being fixed-link. This hits case "1" in the current driver's logic, and must be handled in any logic change here since it is a valid legacy dt-binding. Let's improve the logic to create a MDIO bus if either: - Devicetree contains a MDIO bus - !fixed-link && !phy-handle (legacy handling) This way the case where no MDIO bus should be made is handled, as well as retaining backwards compatibility with the valid cases. Below devicetree snippets can be found that explain some of the cases above more concretely. Here's[0] a devicetree example where the MAC is both fixed-link and driving a switch on MDIO (case "2" above). This needs a MDIO bus to be created: &fec1 { phy-mode = "rmii"; fixed-link { speed = <100>; full-duplex; }; mdio1: mdio { switch0: switch0@0 { compatible = "marvell,mv88e6190"; pinctrl-0 = <&pinctrl_gpio_switch0>; }; }; }; Here's[1] an example where there is no MDIO bus or fixed-link for the ethernet1 MAC, so no MDIO bus should be created since ethernet0 is the MDIO master for ethernet1's phy: ðernet0 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy0>; mdio { compatible = "snps,dwmac-mdio"; sgmii_phy0: phy@8 { compatible = "ethernet-phy-id0141.0dd4"; reg = <0x8>; device_type = "ethernet-phy"; }; sgmii_phy1: phy@a { compatible = "ethernet-phy-id0141.0dd4"; reg = <0xa>; device_type = "ethernet-phy"; }; }; }; ðernet1 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy1>; }; Finally there's descriptions like this[2] which don't describe the MDIO bus but expect it to be created and the whole address space scanned for a phy since there's no phy-handle or fixed-link described: &gmac { phy-supply = <&vcc_lan>; phy-mode = "rmii"; snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>; snps,reset-active-low; snps,reset-delays-us = <0 10000 1000000>; }; [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164Reviewed-by:Serge Semin <fancer.lancer@gmail.com> Co-developed-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
Jason Xing authored
Since we never support this feature for I40E driver, we don't have to display the value when using 'ethtool -c eth0'. Before this patch applied, the rx-frames-irq is 256 which is consistent with tx-frames-irq. Apparently it could mislead users. Signed-off-by:
Jason Xing <kernelxing@tencent.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Reviewed-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20231213184406.1306602-1-anthony.l.nguyen@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== MDIO mux cleanup This small patch set resolves some technical debt in the MDIO mux driver which was discovered during the investigation for commit 1f9f2143 ("net: mdio-mux: fix C45 access returning -EIO after API change"). The patches have been sitting for 2 months in the NXP SDK kernel and haven't caused issues. ==================== Link: https://lore.kernel.org/r/20231213152712.320842-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
After the mii_bus API conversion to a split read() / read_c45(), there might be MDIO parent buses which only populate the read_c45() and write_c45() function pointers but not the C22 variants. We haven't seen these in the wild paired with MDIO multiplexers, but Andrew points out we should treat the corner case. Link: https://lore.kernel.org/netdev/4ccd7dc9-b611-48aa-865f-68d3a1327ce8@lunn.ch/Signed-off-by:
-
Vladimir Oltean authored
Showing the precise error symbols can help debugging probe issues, such as the recent -EIO error in of_mdiobus_register() caused by the lack of bus->read_c45() and bus->write_c45() methods. Signed-off-by:
-
Igor Russkikh authored
Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer. Signed-off-by:
Igor Russkikh <irusskikh@marvell.com> Link: https://lore.kernel.org/r/20231213095044.23146-1-irusskikh@marvell.comSigned-off-by:
-
Jakub Kicinski authored
Hangbin Liu says: ==================== Convert net selftests to run in unique namespace (Part 3) Here is the 3rd part of converting net selftests to run in unique namespace. This part converts all srv6 and fib tests. Note that patch 06 is a fix for testing fib_nexthop_multiprefix. Here is the part 1 link: https://lore.kernel.org/netdev/20231202020110.362433-1-liuhangbin@gmail.com And part 2 link: https://lore.kernel.org/netdev/20231206070801.1691247-1-liuhangbin@gmail.com ==================== Link: https://lore.kernel.org/r/20231213060856.4030084-1-liuhangbin@gmail.comSigned-off-by:
-
Hangbin Liu authored
Here is the test result after conversion. # ./fdb_flush.sh TEST: vx10: Expected 5 FDB entries, got 5 [ OK ] TEST: vx20: Expected 5 FDB entries, got 5 [ OK ] ... TEST: vx10: Expected 5 FDB entries, got 5 [ OK ] TEST: Test entries with dst 192.0.2.1 [ OK ] Acked-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
-
Hangbin Liu authored
Here is the test result after conversion. # ./fib_tests.sh Single path route test Start point TEST: IPv4 fibmatch [ OK ] ... Fib6 garbage collection test TEST: ipv6 route garbage collection [ OK ] IPv4 multipath list receive tests TEST: Multipath route hit ratio (1.00) [ OK ] IPv6 multipath list receive tests TEST: Multipath route hit ratio (1.00) [ OK ] Tests passed: 225 Tests failed: 0 Acked-by:
-
