summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2024-01-31net: phy: c45: change genphy_c45_ethtool_[get|set]_eee to use EEE linkmode ↵Heiner Kallweit1-23/+13
bitmaps Change genphy_c45_ethtool_[get|set]_eee to use EEE linkmode bitmaps. This is a prerequisite for adding support for EEE modes beyond bit 31. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-31ethtool: add suffix _u32 to legacy bitmap members of struct ethtool_keeeHeiner Kallweit14-99/+99
This is in preparation of using the existing names for linkmode bitmaps. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-31ethtool: replace struct ethtool_eee with a new struct ethtool_keee on kernel ↵Heiner Kallweit47-127/+127
side In order to pass EEE link modes beyond bit 32 to userspace we have to complement the 32 bit bitmaps in struct ethtool_eee with linkmode bitmaps. Therefore, similar to ethtool_link_settings and ethtool_link_ksettings, add a struct ethtool_keee. In a first step it's an identical copy of ethtool_eee. This patch simply does a s/ethtool_eee/ethtool_keee/g for all users. No functional change intended. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-31net: stmmac: Report taprio offload statusRohan G Thomas1-4/+58
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>
2024-01-31net: stmmac: est: Per Tx-queue error count for HLBFRohan G Thomas2-0/+7
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 <rohan.g.thomas@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-31net: stmmac: Offload queueMaxSDU from tc-taprioRohan G Thomas3-0/+48
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: Rohan G Thomas <rohan.g.thomas@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-31net: stmmac: dwmac-starfive: Add support for JH7100 SoCCristian Ciocaltea2-7/+31
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: 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: David S. Miller <davem@davemloft.net>
2024-01-30mlxsw: remove I2C_CLASS_HWMON from drivers w/o detect and address_listHeiner Kallweit1-1/+0
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.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-30mlxsw: Use refcount_t for reference countingAmit Cohen6-36/+40
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: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30mlxsw: spectrum: Refactor LAG create and destroy codeAmit Cohen1-43/+73
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 <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30mlxsw: spectrum: Search for free LAD ID onceAmit Cohen1-9/+6
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 <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30mlxsw: spectrum: Query max_lag onceAmit Cohen2-25/+8
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 <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30mlxsw: spectrum: Remove mlxsw_sp_lag_get()Amit Cohen1-9/+3
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 <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30mlxsw: spectrum: Change mlxsw_sp_upper to LAG structureAmit Cohen2-16/+17
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: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30net: micrel: Fix set/get PHC time for lan8814Horatiu Vultur1-32/+29
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: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240126073042.1845153-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30net/tun: use reciprocal_scaleStephen Hemminger1-4/+3
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: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20240126002550.169608-1-stephen@networkplumber.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: stop destroying and reinitalizing Tx tracker during resetJacob Keller1-12/+21
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: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: factor out ice_ptp_rebuild_owner()Jacob Keller3-28/+42
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 <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: rename ice_ptp_tx_cfg_intrJacob Keller1-6/+6
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 <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: don't check has_ready_bitmap in E810 functionsJacob Keller1-12/+11
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 <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: rename verify_cached to has_ready_bitmapJacob Keller2-9/+11
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 <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: pass reset type to PTP reset functionsJacob Keller3-12/+21
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 <jacob.e.keller@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-30ice: introduce PTP state machineJacob Keller4-49/+74
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: Jacob Keller <jacob.e.keller@intel.com> Co-developed-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-29net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabledArınç ÜNAL1-6/+3
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: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-7-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: do not set priv->p5_interface on mt7530_setup_port5()Arınç ÜNAL1-2/+0
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 <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-6-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: improve code path for setting up port 5Arınç ÜNAL1-9/+8
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: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-5-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: improve comments regarding switch portsArınç ÜNAL1-10/+20
There's no logic to numerically order the CPU ports. Just state the port number instead. Remove the irrelevant PHY muxing information from mt7530_mac_port_get_caps(). Explain the supported MII modes instead. Remove the out of place PHY muxing information from mt753x_phylink_mac_config(). The function is for MT7530, MT7531, and the switch on the MT7988 SoC but there's no PHY muxing on MT7531 or the switch on the MT7988 SoC. These comments were gradually introduced with the commits below. commit ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API") commit 38f790a80560 ("net: dsa: mt7530: Add support for port 5") commit 88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a new hardware") commit c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-4-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: store port 5 SGMII capability of MT7531Arınç ÜNAL3-39/+22
Introduce the p5_sgmii field to store the information for whether port 5 has got SGMII or not. Instead of reading the MT7531_TOP_SIG_SR register multiple times, the register will be read once and the value will be stored on the p5_sgmii field. This saves unnecessary reads of the register. Move the comment about MT7531AE and MT7531BE to mt7531_setup(), where the switch is identified. Get rid of mt7531_dual_sgmii_supported() now that priv->p5_sgmii stores the information. Address the code where mt7531_dual_sgmii_supported() is used. Get rid of mt7531_is_rgmii_port() which just prints the opposite of priv->p5_sgmii. Instead of calling mt7531_pll_setup() then returning, do not call it if port 5 is SGMII. Remove P5_INTF_SEL_GMAC5_SGMII. The p5_interface_select enum is supposed to represent the mode that port 5 is being used in, not the hardware information of port 5. Set p5_intf_sel to P5_INTF_SEL_GMAC5 instead, if port 5 is not dsa_is_unused_port(). Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-3-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: use p5_interface_select as data type for p5_intf_selArınç ÜNAL1-2/+2
Use the p5_interface_select enumeration as the data type for the p5_intf_sel field. This ensures p5_intf_sel can only take the values defined in the p5_interface_select enumeration. Remove the explicit assignment of 0 to P5_DISABLED as the first enum item is automatically assigned 0. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-2-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: always trap frames to active CPU port on MT7530Arınç ÜNAL2-6/+35
On the MT7530 switch, the CPU_PORT field indicates which CPU port to trap frames to, regardless of the affinity of the inbound user port. When multiple CPU ports are in use, if the DSA conduit interface is down, trapped frames won't be passed to the conduit interface. To make trapping frames work including this case, implement ds->ops->conduit_state_change() on this subdriver and set the CPU_PORT field to the numerically smallest CPU port whose conduit interface is up. Introduce the active_cpu_ports field to store the information of the active CPU ports. Correct the macros, CPU_PORT is bits 4 through 6 of the register. Add a comment to explain frame trapping for this switch. Currently, the driver doesn't support the use of multiple CPU ports so this is not necessarily a bug fix. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-1-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: fill in MODULE_DESCRIPTION()s for arcnetBreno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to arcnet module. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for PCS driversBreno Leitao3-0/+3
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Lynx, XPCS and LynxI PCS drivers. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for ec_bhfBreno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Beckhoff CX5020 EtherCAT Ethernet driver. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for cpsw-commonBreno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the TI CPSW switch module. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for dwmac-socfpgaBreno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the STMicro DWMAC for Altera SOCs. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for Qualcom driversBreno Leitao2-0/+2
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Qualcom rmnet and emac drivers. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for SMSC driversBreno Leitao3-0/+3
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the SMSC 91x/911x/9420 Ethernet drivers. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for ocelotBreno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Ocelot SoCs (VSC7514) helpers driver. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: fill in MODULE_DESCRIPTION()s for encx24j600Breno Leitao1-0/+1
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Microchip ENCX24J600 helpers driver. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29octeontx2-af: Add filter profiles in hardware to extract packet headersSuman Ghosh4-69/+571
This patch adds hardware profile supports for extracting packet headers. It makes sure that hardware is capabale of extracting ICMP, CPT, ERSPAN headers. Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-27net: txgbe: use irq_domain for interrupt controllerJiawen Wu9-54/+193
In the current interrupt controller, the MAC interrupt acts as the parent interrupt in the GPIO IRQ chip. But when the number of Rx/Tx ring changes, the PCI IRQ vector needs to be reallocated. Then this interrupt controller would be corrupted. So use irq_domain structure to avoid the above problem. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-27net: txgbe: move interrupt codes to a separate fileJiawen Wu4-127/+144
In order to change the interrupt response structure, there will be a lot of code added next. Move these interrupt codes to a new file, to make the codes cleaner. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-26net: dsa: microchip: implement PHY loopback configuration for KSZ8794 and ↵Oleksij Rempel2-7/+70
KSZ8873 Correct the PHY loopback bit handling in the ksz8_w_phy_bmcr and ksz8_r_phy_bmcr functions for KSZ8794 and KSZ8873 variants in the ksz8795 driver. Previously, the code erroneously used Bit 7 of port register 0xD for both chip variants, which is actually for LED configuration. This update ensures the correct registers and bits are used for the PHY loopback feature: - For KSZ8794: Use 0xF / Bit 7. - For KSZ8873: Use 0xD / Bit 0. The lack of loopback support was seen on KSZ8873 system by using "ethtool -t lanX". After this patch, the ethtool selftest will work, but only if port is not part of a bridge. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-4-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: microchip: Remove redundant optimization in ksz8_w_phy_bmcrOleksij Rempel1-67/+29
Remove the manual checks for register value changes in the ksz8_w_phy_bmcr function. Instead, rely on regmap_update_bits() for optimizing register updates. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-3-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: microchip: ksz8: move BMCR specific code to separate functionOleksij Rempel1-126/+240
Isolate the Basic Mode Control Register (BMCR) operations in the ksz8795 driver by moving the BMCR-related code segments from the ksz8_r_phy() and ksz8_w_phy() functions to newly created ksz8_r_phy_bmcr() and ksz8_w_phy_bmcr() functions. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: phy: at803x: add LED support for qca808xChristian Marangi1-0/+327
Add LED support for QCA8081 PHY. Documentation for this LEDs PHY is very scarce even with NDA access to Documentation for OEMs. Only the blink pattern are documented and are very confusing most of the time. No documentation is present about forcing the LED on/off or to always blink. Those settings were reversed by poking the regs and trying to find the correct bits to trigger these modes. Some bits mode are not clear and maybe the documentation option are not 100% correct. For the sake of LED support the reversed option are enough to add support for current LED APIs. Supported HW control modes are: - tx - rx - link_10 - link_100 - link_1000 - link_2500 - half_duplex - full_duplex Also add support for LED polarity set to set LED polarity to active high or low. QSDK sets this value to high by default but PHY reset value doesn't have this enabled by default. QSDK also sets 2 additional bits but their usage is not clear, info about this is added in the header. It was verified that for correct function of the LED if active high is needed, only BIT 6 is needed. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240125203702.4552-6-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: phy: add support for PHY LEDs polarity modesChristian Marangi1-0/+16
Add support for PHY LEDs polarity modes. Some PHY require LED to be set to active low to be turned ON. Adds support for this by declaring active-low property in DT. PHY driver needs to declare .led_polarity_set() to configure LED polarity modes. Function will pass the index with the LED index and a bitmap with all the required modes to set. Current supported modes are: - active-low with the flag PHY_LED_ACTIVE_LOW. LED is set to active-low to turn it ON. - inactive-high-impedance with the flag PHY_LED_INACTIVE_HIGH_IMPEDANCE. LED is set to high impedance to turn it OFF. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240125203702.4552-4-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26bnx2x: Fix firmware version string character countsKees Cook3-12/+13
A potential string truncation was reported in bnx2x_fill_fw_str(), when a long bp->fw_ver and a long phy_fw_ver might coexist, but seems unlikely with real-world hardware. Use scnprintf() to indicate the intent that truncations are tolerated. While reading this code, I found a collection of various buffer size counting issues. None looked like they might lead to a buffer overflow with current code (the small buffers are 20 bytes and might only ever consume 10 bytes twice with a trailing %NUL). However, early truncation (due to a %NUL in the middle of the string) might be happening under likely rare conditions. Regardless fix the formatters and related functions: - Switch from a separate strscpy() to just adding an additional "%s" to the format string that immediately follows it in bnx2x_fill_fw_str(). - Use sizeof() universally instead of using unbound defines. - Fix bnx2x_7101_format_ver() and bnx2x_null_format_ver() to report the number of characters written, not including the trailing %NUL (as already done with the other firmware formatting functions). - Require space for at least 1 byte in bnx2x_get_ext_phy_fw_version() for the trailing %NUL. - Correct the needed buffer size in bnx2x_3_seq_format_ver(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401260858.jZN6vD1k-lkp@intel.com/ Cc: Ariel Elior <aelior@marvell.com> Cc: Sudarsana Kalluru <skalluru@marvell.com> Cc: Manish Chopra <manishc@marvell.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240126041044.work.220-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: mt7530: select MEDIATEK_GE_PHY for NET_DSA_MT7530_MDIOArınç ÜNAL1-1/+1
Quoting from commit 4223f8651287 ("net: dsa: mt7530: make NET_DSA_MT7530 select MEDIATEK_GE_PHY"): Make MediaTek MT753x DSA driver enable MediaTek Gigabit PHYs driver to properly control MT7530 and MT7531 switch PHYs. A noticeable change is that the behaviour of switchport interfaces going up-down-up-down is no longer there. Now, the switch can be used without the PHYs but, at the moment, every hardware design out there that I have seen uses them. For that, it would make the most sense to force the selection of MEDIATEK_GE_PHY for the MDIO interface which currently controls the MT7530 and MT7531 switches. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122053451.8004-1-arinc.unal@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-25tsnep: Add link down PHY loopback supportGerhard Engleder1-1/+3
PHY loopback turns off link state change signalling. Therefore, the loopback only works if the link is already up before the PHY loopback is activated. Ensure that PHY loopback works even if the link is not already up during activation by calling netif_carrier_on() explicitly. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://lore.kernel.org/r/20240123200151.60848-1-gerhard@engleder-embedded.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-17 05:44:15 +0000