- 31 Jan, 2024 17 commits
-
-
Rohan G Thomas authored
Report taprio offload status. This includes per txq and global counters of window_drops and tx_overruns. Window_drops count include count of frames dropped because of queueMaxSDU setting and HLBF error. Transmission overrun counter inform the user application whether any packets are currently being transmitted on a particular queue during a gate-close event.DWMAC IPs takes care Transmission overrun won't happen hence this is always 0. Signed-off-by:
Rohan G Thomas <rohan.g.thomas@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Rohan G Thomas authored
Keep per Tx-queue error count on Head-Of-Line Blocking due to frame size(HLBF) error. The MAC raises HLBF error on one or more queues when none of the time Intervals of open-gates in the GCL is greater than or equal to the duration needed for frame transmission and by default drops those packets that causes HLBF error. EST_FRM_SZ_ERR register provides the One Hot encoded Queue numbers that have the Frame Size related error. Signed-off-by:
-
Rohan G Thomas authored
Add support for configuring queueMaxSDU. As DWMAC IPs doesn't support queueMaxSDU table handle this in the SW. The maximum 802.3 frame size that is allowed to be transmitted by any queue is queueMaxSDU + 16 bytes (i.e. 6 bytes SA + 6 bytes DA + 4 bytes FCS). Inspired from intel i225 driver. Signed-off-by:
-
Willem de Bruijn authored
This test validates per-band packet limits in FQ. Packets are dropped rather than enqueued if the limit for their band is reached. This test is timing sensitive. It queues packets in FQ with a future delivery time to fill the qdisc. The test failed in a virtual environment (vng). Increase the delays to make it more tolerant to environments with timing variance. Signed-off-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
David S. Miller authored
Benjamin Poirier says: ==================== selftests: Add TEST_INCLUDES directive and adjust tests to use it After commit 25ae948b ("selftests/net: add lib.sh") but before commit 2114e833 ("selftests: forwarding: Avoid failures to source net/lib.sh"), some net selftests encountered errors when they were being exported and run. This was because the new net/lib.sh was not exported along with the tests. The errors were crudely avoided by duplicating some content between net/lib.sh and net/forwarding/lib.sh in 2114e833. In order to restore the sourcing of net/lib.sh from net/forwarding/lib.sh and remove the duplicated content, this series introduces a new selftests Makefile variable to list extra files to export from other directories and makes use of it to avoid reintroducing the errors mentioned above. v2: * "selftests: Introduce Makefile variable to list shared bash scripts" Fix rst syntax in Documentation/dev-tools/kselftest.rst (Jakub Kicinski) v1: * "selftests: Introduce Makefile variable to list shared bash scripts" Changed TEST_INCLUDES to take relative paths, like other TEST_* variables. Paths are adjusted accordingly in the subsequent patches. (Vladimir Oltean) * selftests: bonding: Change script interpreter selftests: forwarding: Remove executable bits from lib.sh Removed from this series, submitted separately. Since commit 2114e833 ("selftests: forwarding: Avoid failures to source net/lib.sh") resolved the test errors, this version of the series is focused on removing the duplication that was added in that commit. Directly rebasing the series would reintroduce the problems that 2114e833 avoided before fixing them again. In order to prevent such breakage partway through the series, patches are reordered and content changed slightly but there is no diff at the end compared with the simple rebasing approach. I have dropped most review tags on account of this reordering. RFC: https://lore.kernel.org/netdev/20231222135836.992841-1-bpoirier@nvidia.com/ Link: https://lore.kernel.org/netdev/ZXu7dGj7F9Ng8iIX@Laptop-X1/ ==================== Signed-off-by:
-
Petr Machata authored
commit 25ae948b ("selftests/net: add lib.sh") added net/lib.sh to contain code shared by tests under net/ and net/forwarding/. However, this caused issues with selftests from directories other than net/forwarding/, in particular those under drivers/net/. Those issues were avoided in a simple way by duplicating some content in commit 2114e833 ("selftests: forwarding: Avoid failures to source net/lib.sh"). In order to remove the duplicated content, restore the inclusion of net/lib.sh from net/forwarding/lib.sh but with the following changes: * net/lib.sh is imported through the net_forwarding_dir path The original expression "source ../lib.sh" would look for lib.sh in the directory above the script file's one, which did not work for tests under drivers/net/. * net/lib.sh is added to TEST_INCLUDES Since net/forwarding/lib.sh now sources net/lib.sh, both of those files must be exported along with tests which source net/forwarding/lib.sh. Suggested-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Benjamin Poirier <bpoirier@nvidia.com> Signed-off-by:
-
Benjamin Poirier authored
The following code which is part of lib.sh: relative_path="${BASH_SOURCE%/*}" if [[ "$relative_path" == "${BASH_SOURCE}" ]]; then relative_path="." fi reimplements functionality that is part of `dirname`: $ dirname "" . To avoid this duplication, replace "relative_path" by "net_forwarding_dir", a new variable defined using dirname. Furthermore, to avoid the potential confusion about what "relative_path" is about (cwd, test script directory or test library directory), define "net_forwarding_dir" as the absolute path to net/forwarding/. Tested-by: -
Benjamin Poirier authored
The dsa tests which are symlinks of tests from net/forwarding/ (like tc_actions.sh) become regular files after export (because `rsync --copy-unsafe-links` is used) and expect to source lib.sh (net/forwarding/lib.sh) from the same directory. In the last patch of this series, net/forwarding/lib.sh will source lib.sh from its parent directory (ie. net/lib.sh). This would not work for dsa tests because net/lib.sh is not present under drivers/net/. Since the tests in net/forwarding/ are not meant to be copied and run from another directory, as a preparation for that last patch, replace the test symlinks by a wrapper script which runs the original tests under net/forwarding/. Following from that, the links to shared library scripts in dsa/ are no longer used so remove them and add all the original files needed from parent directories to TEST_INCLUDES. Suggested-by:
-
Benjamin Poirier authored
In order to avoid duplicated files when both the team and bonding tests are exported together, add lag_lib.sh to TEST_INCLUDES. Do likewise for net/forwarding/lib.sh regarding team and forwarding tests. Reviewed-by:
-
Benjamin Poirier authored
In order to avoid duplicated files when both the bonding and forwarding tests are exported together, add net/forwarding/lib.sh to TEST_INCLUDES and include it via its relative path. Reviewed-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
Benjamin Poirier authored
Some tests written in bash source other files in a parent directory. For example, drivers/net/bonding/dev_addr_lists.sh sources net/forwarding/lib.sh. If a subset of tests is exported and run outside the source tree (for example by using `make -C tools/testing/selftests gen_tar TARGETS="drivers/net/bonding"`), these other files must be made available as well. Commit ae108c48 ("selftests: net: Fix cross-tree inclusion of scripts") addressed this problem by symlinking and copying the sourced files but this only works for direct dependencies. Commit 25ae948b ("selftests/net: add lib.sh") changed net/forwarding/lib.sh to source net/lib.sh. As a result, that latter file must be included as well when the former is exported. This was not handled and was reverted in commit 2114e833 ("selftests: forwarding: Avoid failures to source net/lib.sh"). In order to allow reinstating the inclusion of net/lib.sh from net/forwarding/lib.sh, add a mechanism to list dependent files in a new Makefile variable and export them. This allows sourcing those files using the same expression whether tests are run in-tree or exported. Dependencies are not resolved recursively so transitive dependencies must be listed in TEST_INCLUDES. For example, if net/forwarding/lib.sh sources net/lib.sh; the Makefile related to a test that sources net/forwarding/lib.sh from a parent directory must list: TEST_INCLUDES := \ ../../../net/forwarding/lib.sh \ ../../../net/lib.sh v2: Fix rst syntax in Documentation/dev-tools/kselftest.rst (Jakub Kicinski) v1 (from RFC): * changed TEST_INCLUDES to take relative paths, like other TEST_* variables (Vladimir Oltean) * preserved common "$(MAKE) OUTPUT=... -C ... target" ordering in Makefile (Petr Machata) Signed-off-by:
-
David S. Miller authored
Cristian Ciocaltea says: ==================== StarFive DWMAC support for JH7100 This is just a subset of the initial patch series [1] adding networking support for StarFive JH7100 SoC. [1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea@collabora.com/ Changes in v4: - Rebased series onto next-20240125 - Added R-b tag from Rob in PATCH 1 - v3: https://lore.kernel.org/lkml/20231222101001.2541758-1-cristian.ciocaltea@collabora.com/ Changes in v3: - Optimized jh7110 resets & reset-names properties (Rob) - Added R-b tag from Jacob in PATCH 1 - v2: https://lore.kernel.org/lkml/20231220002824.2462655-1-cristian.ciocaltea@collabora.com/ Changes in v2: - Add the missing binding patch (Conor) - v1: https://lore.kernel.org/lkml/20231219231040.2459358-1-cristian.ciocaltea@collabora.com/ ==================== Signed-off-by:
-
Cristian Ciocaltea authored
Add a missing quirk to enable support for the StarFive JH7100 SoC. Additionally, for greater flexibility in operation, allow using the rgmii-rxid and rgmii-txid phy modes. Co-developed-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Cristian Ciocaltea authored
The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly similar to the newer JH7110, but it requires only two interrupts and a single reset line, which is 'ahb' instead of the commonly used 'stmmaceth'. Since the common binding 'snps,dwmac' allows selecting 'ahb' only in conjunction with 'stmmaceth', extend the logic to also permit exclusive usage of the 'ahb' reset name. This ensures the following use cases are supported: JH7110: reset-names = "stmmaceth", "ahb"; JH7100: reset-names = "ahb"; other: reset-names = "stmmaceth"; Also note the need to use a different dwmac fallback, as v5.20 applies to JH7110 only, while JH7100 relies on v3.7x. Additionally, drop the reset description items from top-level binding as they are already provided by the included snps,dwmac schema. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Heiner Kallweit authored
Class-based I2C probing requires detect() and address_list to be set in the I2C client driver, see checks in i2c_detect(). It's misleading to declare I2C_CLASS_HWMON support if this precondition isn't met. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/77b5ab8e-20f2-4310-bd89-57db99e2f53b@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Christophe JAILLET authored
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_range() is inclusive. So a -1 has been added when needed. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/8e889d18a6c881b09db4650d4b30a62d76f4fe77.1705734073.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Kunwu Chan authored
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Link: https://lore.kernel.org/r/20240124075801.471330-1-chentao@kylinos.cnSigned-off-by:
-
- 30 Jan, 2024 23 commits
-
-
Paolo Abeni authored
Petr Machata says: ==================== mlxsw: Refactor reference counting code Amit Cohen writes: This set converts all reference counters defined as 'unsigned int' to refcount_t type. The reference counting of LAGs can be simplified, so first refactor the related code and then change the type of the reference counter. Patch set overview: Patches #1-#4 are preparations for LAG refactor Patch #5 refactors LAG code and change the type of reference counter Patch #6 converts the remaining reference counters in mlxsw driver ==================== Link: https://lore.kernel.org/r/cover.1706293430.git.petrm@nvidia.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Amit Cohen authored
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use refcount_t type which allows us to catch overflow and underflow issues. Change the type of the counters and use the appropriate API. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
-
Amit Cohen authored
mlxsw_sp stores an array of LAGs. When a port joins a LAG, in case that this LAG is already in use, we only have to increase the reference counter. Otherwise, we have to search for an unused LAG ID and configure it in hardware. When a port leaves a LAG, we have to destroy it only for the last user. This code can be simplified, for such requirements we usually add get() and put() functions which create and destroy the object. Add mlxsw_sp_lag_{get,put}() and use them. These functions take care of the reference counter and hardware configuration if needed. Change the reference counter to refcount_t type which catches overflow and underflow issues. Signed-off-by: -
Amit Cohen authored
Currently, the function mlxsw_sp_lag_index_get() is called twice - first as part of NETDEV_PRECHANGEUPPER event and later as part of NETDEV_CHANGEUPPER. This function will be changed in the next patch. To simplify the code, call it only once as part of NETDEV_CHANGEUPPER event and set an error message using 'extack' in case of failure. Signed-off-by:
-
Amit Cohen authored
The maximum number of LAGs is queried from core several times. It is used to allocate LAG array, and then to iterate over it. In addition, it is used for PGT initialization. To simplify the code, instead of querying it several times, store the value as part of 'mlxsw_sp' and use it. Signed-off-by:
-
Amit Cohen authored
A next patch will add mlxsw_sp_lag_{get,put}() functions to handle LAG reference counting and create/destroy it only for first user/last user. Remove mlxsw_sp_lag_get() function and access LAG array directly. Signed-off-by: -
Amit Cohen authored
The structure mlxsw_sp_upper is used only as LAG. Rename it to mlxsw_sp_lag and move it to spectrum.c file, as it is used only there. Move the function mlxsw_sp_lag_get() with the structure. Signed-off-by:
-
Petr Machata authored
The config file contains a partial kernel configuration to be used by `virtme-configkernel --custom'. The presumption is that the config file contains all Kconfig options needed by the selftests from the directory. In net/forwarding/config, many are missing, which manifests as spurious failures when running the selftests, with messages about unknown device types, qdisc kinds or classifier actions. Add the missing configurations. Tested the resulting configuration using virtme-ng as follows: # vng -b -f tools/testing/selftests/net/forwarding/config # vng --user root (within the VM:) # make -C tools/testing/selftests TARGETS=net/forwarding run_tests Signed-off-by:
-
Horatiu Vultur authored
When setting or getting PHC time, the higher bits of the second time (>32 bits) they were ignored. Meaning that setting some time in the future like year 2150, it was failing to set this. The issue can be reproduced like this: # phc_ctl /dev/ptp1 set 10000000000 phc_ctl[12.290]: set clock time to 10000000000.000000000 or Sat Nov 20 17:46:40 2286 # phc_ctl /dev/ptp1 get phc_ctl[15.309]: clock time is 1410065411.018055420 or Sun Sep 7 04:50:11 2014 Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by:
Divya Koppera <divya.koppera@microchip.com> Reviewed-by:
-
Stephen Hemminger authored
Use the inline function reciprocal_scale rather than open coding the scale optimization. Also, remove unnecessary initializations. Resulting compiled code is unchanged (according to godbolt). Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Reviewed-by:
Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20240126002550.169608-1-stephen@networkplumber.orgSigned-off-by:
-
Paolo Abeni authored
Tony Nguyen says: ==================== ice: fix timestamping in reset process Karol Kolacinski says: PTP reset process has multiple places where timestamping can end up in an incorrect state. This series introduces a proper state machine for PTP and refactors a large part of the code to ensure that timestamping does not break. The following are changes since commit 91374ba5: net: dsa: mt7530: support OF-based registration of switch MDIO bus and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE ==================== Link: https://lore.kernel.org/r/20240125215757.2601799-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jacob Keller authored
The ice driver currently attempts to destroy and re-initialize the Tx timestamp tracker during the reset flow. The release of the Tx tracker only happened during CORE reset or GLOBAL reset. The ice_ptp_rebuild() function always calls the ice_ptp_init_tx function which will allocate a new tracker data structure, resulting in memory leaks during PF reset. Certainly the driver should not be allocating a new tracker without removing the old tracker data, as this results in a memory leak. Additionally, there's no reason to remove the tracker memory during a reset. Remove this logic from the reset and rebuild flow. Instead of releasing the Tx tracker, flush outstanding timestamps just before we reset the PHY timestamp block in ice_ptp_cfg_phy_interrupt(). Signed-off-by:
Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Jacob Keller authored
The ice_ptp_reset() function uses a goto to skip past clock owner operations if performing a PF reset or if the device is not the clock owner. This is a bit confusing. Factor this out into ice_ptp_rebuild_owner() instead. The ice_ptp_reset() function is called by ice_rebuild() to restore PTP functionality after a device reset. Follow the convention set by the ice_main.c file and rename this function to ice_ptp_rebuild(), in the same way that we have ice_prepare_for_reset() and ice_ptp_prepare_for_reset(). Signed-off-by:
-
Jacob Keller authored
The ice_ptp_tx_cfg_intr() function sends a control queue message to configure the PHY timestamp interrupt block. This is a very similar name to a function which is used to configure the MAC Other Interrupt Cause Enable register. Rename this function to ice_ptp_cfg_phy_interrupt in order to make it more obvious to the reader what action it performs, and distinguish it from other similarly named functions. Signed-off-by:
-
Jacob Keller authored
E810 hardware does not have a Tx timestamp ready bitmap. Don't check has_ready_bitmap in E810-specific functions. Add has_ready_bitmap check in ice_ptp_process_tx_tstamp() to stop relying on the fact that ice_get_phy_tx_tstamp_ready() returns all 1s. Signed-off-by:
-
Jacob Keller authored
The tx->verify_cached flag is used to inform the Tx timestamp tracking code whether it needs to verify the cached Tx timestamp value against a previous captured value. This is necessary on E810 hardware which does not have a Tx timestamp ready bitmap. In addition, we currently rely on the fact that the ice_get_phy_tx_tstamp_ready() function returns all 1s for E810 hardware. Instead of introducing a brand new flag, rename and verify_cached to has_ready_bitmap, inverting the relevant checks. Signed-off-by:
-
Jacob Keller authored
The ice_ptp_prepare_for_reset() and ice_ptp_reset() functions currently check the pf->flags ICE_FLAG_PFR_REQ bit to determine if the current reset is a PF reset or not. This is problematic, because it is possible that a PF reset and a higher level reset (CORE reset, GLOBAL reset, EMP reset) are requested simultaneously. In that case, the driver performs the highest level reset requested. However, the ICE_FLAG_PFR_REQ flag will still be set. The main driver reset functions take an enum ice_reset_req indicating which reset is actually being performed. Pass this data into the PTP functions and rely on this instead of relying on the driver flags. This ensures that the PTP code performs the proper level of reset that the driver is actually undergoing. Signed-off-by:
-
Jacob Keller authored
Add PTP state machine so that the driver can correctly identify PTP state around resets. When the driver got information about ungraceful reset, PTP was not prepared for reset and it returned error. When this situation occurs, prepare PTP before rebuilding its structures. Signed-off-by:
-
Menglong Dong authored
For now, the packet with an old ack is not accepted if we are in FIN_WAIT1 state, which can cause retransmission. Taking the following case as an example: Client Server | | FIN_WAIT1(Send FIN, seq=10) FIN_WAIT1(Send FIN, seq=20, ack=10) | | | Send ACK(seq=21, ack=11) Recv ACK(seq=21, ack=11) | Recv FIN(seq=20, ack=10) In the case above, simultaneous close is happening, and the FIN and ACK packet that send from the server is out of order. Then, the FIN will be dropped by the client, as it has an old ack. Then, the server has to retransmit the FIN, which can cause delay if the server has set the SO_LINGER on the socket. Old ack is accepted in the ESTABLISHED and TIME_WAIT state, and I think it should be better to keep the same logic. In this commit, we accept old ack in FIN_WAIT1/FIN_WAIT2/CLOSING/LAST_ACK states. Maybe we should limit it to FIN_WAIT1 for now? Signed-off-by:Menglong Dong <menglong8.dong@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240126040519.1846345-1-menglong8.dong@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Arınç ÜNAL says: ==================== MT7530 DSA Subdriver Improvements Act I This patch series simplifies the MT7530 DSA subdriver and improves the logic of the support for MT7530, MT7531, and the switch on the MT7988 SoC. I have done a simple ping test to confirm basic communication on all switch ports on MCM and standalone MT7530, and MT7531 switch with this patch series applied. MT7621 Unielec, MCM MT7530: rgmii-only-gmac0-mt7621-unielec-u7621-06-16m.dtb gmac0-and-gmac1-mt7621-unielec-u7621-06-16m.dtb tftpboot 0x80008000 mips-uzImage.bin; tftpboot 0x83000000 mips-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootm 0x80008000 0x83000000 0x83f00000 MT7622 Bananapi, MT7531: gmac0-and-gmac1-mt7622-bananapi-bpi-r64.dtb tftpboot 0x40000000 arm64-Image; tftpboot 0x45000000 arm64-rootfs.cpio.uboot; tftpboot 0x4a000000 $dtb; booti 0x40000000 0x45000000 0x4a000000 MT7623 Bananapi, standalone MT7530: rgmii-only-gmac0-mt7623n-bananapi-bpi-r2.dtb gmac0-and-gmac1-mt7623n-bananapi-bpi-r2.dtb tftpboot 0x80008000 arm-zImage; tftpboot 0x83000000 arm-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootz 0x80008000 0x83000000 0x83f00000 This patch series is the continuation of the patch series linked below. https://lore.kernel.org/r/20230522121532.86610-1-arinc.unal@arinc9.com v2: https://lore.kernel.org/r/20231227044347.107291-1-arinc.unal@arinc9.com v1: https://lore.kernel.org/r/20231118123205.266819-1-arinc.unal@arinc9.comSigned-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> ==================== Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-0-042401f2b279@arinc9.comSigned-off-by:
-
Arınç ÜNAL authored
There's no need to run all the code on mt7530_setup_port5() if port 5 is disabled. The only case for calling mt7530_setup_port5() from mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not defined as a port on the devicetree, therefore, it cannot be controlled by phylink. Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from mt7530_setup_port5(). Stop initialising the interface variable as the remaining cases will always call mt7530_setup_port5() with it initialised. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-7-042401f2b279@arinc9.comSigned-off-by:
-
Arınç ÜNAL authored
Running mt7530_setup_port5() from mt7530_setup() used to handle all cases of configuring port 5, including phylink. Setting priv->p5_interface under mt7530_setup_port5() makes sure that mt7530_setup_port5() from mt753x_phylink_mac_config() won't run. The commit ("net: dsa: mt7530: improve code path for setting up port 5") makes so that mt7530_setup_port5() from mt7530_setup() runs only on non-phylink cases. Get rid of unnecessarily setting priv->p5_interface under mt7530_setup_port5() as port 5 phylink configuration will be done by running mt7530_setup_port5() from mt753x_phylink_mac_config() now. Signed-off-by: -
Arınç ÜNAL authored
There're two code paths for setting up port 5: mt7530_setup() -> mt7530_setup_port5() mt753x_phylink_mac_config() -> mt753x_mac_config() -> mt7530_mac_config() -> mt7530_setup_port5() Currently mt7530_setup_port5() from mt7530_setup() always runs. If port 5 is used as a CPU, DSA, or user port, mt7530_setup_port5() from mt753x_phylink_mac_config() won't run. That is because priv->p5_interface set on mt7530_setup_port5() will match state->interface on mt753x_phylink_mac_config() which will stop running mt7530_setup_port5() again. Therefore, mt7530_setup_port5() will never run from mt753x_phylink_mac_config(). Address this by not running mt7530_setup_port5() from mt7530_setup() if port 5 is used as a CPU, DSA, or user port. This driver isn't in the dsa_switches_apply_workarounds[] array so phylink will always be present. To keep the cases where port 5 isn't controlled by phylink working as before, preserve the mt7530_setup_port5() call from mt7530_setup(). Do not set priv->p5_intf_sel to P5_DISABLED. It is already set to that when "priv" is allocated. Move setting the interface to a more specific location. It's supposed to be overwritten if PHY muxing is detected. Improve the comment which explains the process. Signed-off-by:
-
