- 11 Jan, 2023 15 commits
-
-
zhang songyi authored
Return value from mlx5dr_send_postsend_action() directly instead of taking this in another redundant variable. Signed-off-by:
zhang songyi <zhang.songyi@zte.com.cn> Reviewed-by:
Roi Dayan <roid@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Kees Cook authored
Zero-length arrays are deprecated[1]. Replace struct mlx5e_rx_wqe_cyc's "data" 0-length array with a flexible array. Detected with GCC 13, using -fstrict-flex-arrays=3: drivers/net/ethernet/mellanox/mlx5/core/en_main.c: In function 'mlx5e_alloc_rq': drivers/net/ethernet/mellanox/mlx5/core/en_main.c:827:42: warning: array subscript f is outside array bounds of 'struct mlx5_wqe_data_seg[0]' [-Warray-bounds=] 827 | wqe->data[f].byte_count = 0; | ~~~~~~~~~^~~ In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.h:11, from drivers/net/ethernet/mellanox/mlx5/core/eswitch.h:48, from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:42: drivers/net/ethernet/mellanox/mlx5/core/en.h:250:39: note: while referencing 'data' 250 | struct mlx5_wqe_data_seg data[0]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays Cc: Saeed Mahameed <saeedm@nvidia.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Signed-off-by:Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length array declaration in struct mlx5e_flow_meter_aso_obj with flex-array member. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Link: https://github.com/KSPP/linux/issues/78Signed-off-by:
-
Tariq Toukan authored
Certain connection-based device-offload protocols (like TLS) use per-connection HW objects to track the state, maintain the context, and perform the offload properly. Some of these objects are created, modified, and destroyed via FW commands. Under high connection rate, this type of FW commands might continuously populate all slots of the FW command interface and throttle it, while starving other critical control FW commands. Limit these throttle commands to using only up to a portion (half) of the FW command interface slots. FW commands maximal rate is not hit, and the same high rate is still reached when applying this limitation. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Tariq Toukan authored
Introduce an opcode getter in the FW command interface, and use it. Initialize the entry's opcode field early in cmd_alloc_ent() and use it when possible. Signed-off-by:
-
Shay Drory authored
Enable initialization of DPU Management PF, which is a new loopback PF designed for communication with BMC. For now Management PF doesn't support nor require most upper layer protocols so avoid them. Signed-off-by:
Shay Drory <shayd@nvidia.com> Reviewed-by:
Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by:
-
Gal Pressman authored
We refer to a TC NIC rule that involves forwarding as "hairpin". Hairpin queues are mlx5 hardware specific implementation for hardware forwarding of such packets. For debug purposes, introduce debugfs files which: * Expose the number of active hairpins * Dump the hairpin table * Allow control over the number and size of the hairpin queues instead of the hard-coded values. This allows us to get visibility of the feature in order to improve it for next generation hardware. Add debugfs files: fs/tc/hairpin_num_active fs/tc/hairpin_num_queues fs/tc/hairpin_queue_size fs/tc/hairpin_table_dump Note that the new values will only take effect on the next queues creation, it does not affect existing queues. Signed-off-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
-
Gal Pressman authored
Add a debugfs directory for flow steering related information. The directory is currently empty, and will hold the 'tc' subdirectory in a downstream patch. Signed-off-by:
-
Gal Pressman authored
In preparation for downstream work to expose hairpin queues parameters, introduce a hairpin parameters struct as part of the tc structure. Signed-off-by:
-
Tariq Toukan authored
Add TLS debugfs to improve observability by exposing the size of the tls TX pool. To observe the size of the TX pool: $ cat /sys/kernel/debug/mlx5/<pci>/nic/tls/tx/pool_size Signed-off-by:
-
Gal Pressman authored
Similar to the mlx5_core debugfs, lay the groundwork for mlx5e debugfs files under /sys/kernel/debug/mlx5/<pci>/nic/.. Signed-off-by:
-
Maher Sanalla authored
Currently, the user can modify device's receive buffer size, modify the mapping between QoS priority groups to buffers and change the buffer state to become lossy/lossless via pfc command. However, the shared receive buffer pool alignments, as a result of such commands, is performed only when the shared buffer is in FW ownership. When a user changes the mapping of priority groups or buffer size, the shared buffer is moved to SW ownership. Therefore, for devices that support shared buffer, handle the shared buffer alignments in accordance to user's desired configurations. Meaning, the following will be performed: 1. For every change of buffer's headroom, recalculate the size of shared buffer to be equal to "total_buffer_size" - "new_headroom_size". The new shared buffer size will be split in ratio of 3:1 between lossy and lossless pools, respectively. 2. For each port buffer change, count the number of lossless buffers. If there is only one lossless buffer, then set its lossless pool usage threshold to be infinite. Otherwise, if there is more than one lossless buffer, set a usage threshold for each lossless buffer. While at it, add more verbosity to debug prints when handling user commands, to assist in future debug. Signed-off-by:
Maher Sanalla <msanalla@nvidia.com> Reviewed-by:
-
Maher Sanalla authored
To allow users to configure shared receive buffer parameters through dcbnl callbacks, expose an API to query and modify SBPR and SBCM registers, which will be used in the upcoming patch. Signed-off-by:
-
Maher Sanalla authored
Add the shared receive buffer management and configuration registers: 1. SBPR - Shared Buffer Pools Register 2. SBCM - Shared Buffer Class Management Register Signed-off-by:
-
Dai Shixin authored
Fix a typo of "permision" which should be "permission". Signed-off-by:
Dai Shixin <dai.shixin@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com.cn> Link: https://lore.kernel.org/r/202301091935262709751@zte.com.cnSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 10 Jan, 2023 23 commits
-
-
Jakub Kicinski authored
Michael Walle says: ==================== net: mdio: Start separating C22 and C45 This patch set starts the separation of C22 and C45 MDIO bus transactions at the API level to the MDIO Bus drivers. C45 read and write ops are added to the MDIO bus driver structure, and the MDIO core will try to use these ops if requested to perform a C45 transfer. If not available a fallback to the older API is made, to allow backwards compatibility until all drivers are converted. A few drivers are then converted to this new API. The core DSA patch was dropped for now as there is still an ongoing discussion. It will be picked up in a later series again. v2: https://lore.kernel.org/r/20221227-v6-2-rc1-c45-seperation-v2-0-ddb37710e5a7@walle.cc v1: https://lore.kernel.org/r/20220508153049.427227-1-andrew@lunn.ch ==================== Link: https://lore.kernel.org/r/20221227-v6-2-rc1-c45-seperation-v3-0-ade1deb438da@walle.ccSigned-off-by:
-
Andrew Lunn authored
The global2 SMI MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Update the SERDES code to make use of these new accessors. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Andrew Lunn authored
Some DSA devices pass through PHY access to the MDIO bus the switch is on. Add C45 versions of the current C22 helpers for nested accesses to MDIO busses, so that C22 and C45 can be separated in these DSA drivers. Signed-off-by:
-
Andrew Lunn authored
The fec MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
Wei Fang <wei.fang@nxp.com> Signed-off-by:
-
Andrew Lunn authored
The xgmac MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. While at it, remove the misleading comment. According to Vladimir Oltean: - miimcom is a register accessed by fsl_pq_mdio.c, not by xgmac_mdio.c - "device dev" doesn't really refer to anything (maybe "dev_addr"). - I don't understand what is meant by the comment "All PHY configuration has to be done through the TSEC1 MIIM regs". Or rather said, I think I understand, but it is irrelevant to the driver for 2 reasons: * TSEC devices use the fsl_pq_mdio.c driver, not this one * It doesn't matter to this driver whose TSEC registers are used for MDIO access. The driver just works with the registers it's given, which is a concern for the device tree. - barring the above, the rest just describes the MDIO bus API, which is superfluous Signed-off-by: -
Andrew Lunn authored
The marvell MDIO driver supports two different hardware blocks. The XSMI block is C45 only. Convert this block to the new API, and only populate the c45 calls in the bus structure. Signed-off-by:
-
Andrew Lunn authored
The bitbbanging bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new driver API calls. The SH Ethernet driver places wrappers around these functions. In order to not break boards which might be using C45, add similar wrappers for C45 operations. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Andrew Lunn authored
Now that mdiobus_c45_addr() is only used within the MDIO code during fallback, move the function next to its only users. This function should not be used any more in drivers, the c45 helpers should be used in its place, so hiding it away will prevent any new users from being added. Signed-off-by:
-
Andrew Lunn authored
When performing a C22 operation, check that the bus driver actually provides the methods, and return -EOPNOTSUPP if not. C45 only busses do exist, and in future their C22 methods will be NULL. Signed-off-by:
-
Andrew Lunn authored
Now that C45 uses its own read/write methods, the validation performed when a bus is registers needs updating. All combinations of C22 and C45 are supported, but both read and write methods must be provided, read only busses are not supported etc. Signed-off-by:
-
Andrew Lunn authored
Convert the PCS-XPCS driver to make use of the C45 MDIO bus API for modify_change(). Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Currently C22 and C45 transactions are mixed over a combined API calls which make use of a special bit in the reg address to indicate if a C45 transaction should be performed. This makes it impossible to know if the bus driver actually supports C45. Additionally, many C22 only drivers don't return -EOPNOTSUPP when asked to perform a C45 transaction, they mistaking perform a C22 transaction. This is the first step to cleanly separate C22 from C45. To maintain backwards compatibility until all drivers which are capable of performing C45 are converted to this new API, the helper functions will fall back to the older API if the new API is not supported. Eventually this fallback will be removed. Signed-off-by:
-
Paolo Abeni authored
Michael Walle says: ==================== net: phy: mxl-gpy: broken interrupt fixes The GPY215 has a broken interrupt pin. This patch series tries to workaround that and because in general that is not possible, disables the interrupts by default and falls back to polling mode. There is an opt-in via the devicetree. ==================== Link: https://lore.kernel.org/r/20230109123013.3094144-1-michael@walle.ccSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Michael Walle authored
The interrupts on the GPY215B and GPY215C are broken and the only viable fix is to disable them altogether. There is still the possibilty to opt-in via the device tree. Signed-off-by:
-
Michael Walle authored
Until now, it is not possible for a PHY driver to disable interrupts during runtime. If a driver offers the .config_intr() as well as the .handle_interrupt() ops, it is eligible for interrupt handling. Introduce a new flag for the dev_flags property of struct phy_device, which can be set by PHY driver to skip interrupt setup and fall back to polling mode. At the moment, this is used for the MaxLinear PHY which has broken interrupt handling and there is a need to disable interrupts in some cases. Signed-off-by:
-
Michael Walle authored
Add the device tree bindings for the MaxLinear GPY2xx PHYs, which essentially adds just one flag: maxlinear,use-broken-interrupts. One might argue, that if interrupts are broken, just don't use the interrupt property in the first place. But it needs to be more nuanced. First, this interrupt line is also used to wake up systems by WoL, which has nothing to do with the (broken) PHY interrupt handling. Second and more importantly, there are devicetrees which have this property set. Thus, within the driver we have to switch off interrupt handling by default as a workaround. But OTOH, a systems designer who knows the hardware and knows there are no shared interrupts for example, can use this new property as a hint to the driver that it can enable the interrupt nonetheless. Signed-off-by:
-
Michael Walle authored
MaxLinear is a manufacturer of integrated circuits. https://www.maxlinear.comSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Paolo Abeni authored
Hans J. Schultz says: ==================== mv88e6xxx: Add MAB offload support This patch-set adds MAB [1] offload support in mv88e6xxx. Patch #1: Correct default return value for mv88e6xxx_port_bridge_flags. Patch #2: Shorten the locked section in mv88e6xxx_g1_atu_prob_irq_thread_fn(). Patch #3: The MAB implementation for mv88e6xxx. [1] https://git.kernel.org/netdev/net-next/c/4bf24ad09bc0 ==================== Link: https://lore.kernel.org/r/20230108094849.1789162-1-netdev@kapio-technology.comSigned-off-by: -
Hans J. Schultz authored
This implementation for the Marvell mv88e6xxx chip series is based on handling ATU miss violations occurring when packets ingress on a port that is locked with learning on. This will trigger a SWITCHDEV_FDB_ADD_TO_BRIDGE event, which will result in the bridge module adding a locked FDB entry. This bridge FDB entry will not age out as it has the extern_learn flag set. Userspace daemons can listen to these events and either accept or deny access for the host, by either replacing the locked FDB entry with a simple entry or leave the locked entry. If the host MAC address is already present on another port, a ATU member violation will occur, but to no real effect, and the packet will be dropped in hardware. Statistics on these violations can be shown with the command and example output of interest: ethtool -S ethX NIC statistics: ... atu_member_violation: 5 atu_miss_violation: 23 ... Where ethX is the interface of the MAB enabled port. Furthermore, as added vlan interfaces where the vid is not added to the VTU will cause ATU miss violations reporting the FID as MV88E6XXX_FID_STANDALONE, we need to check and skip the miss violations handling in this case. Signed-off-by:Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Hans J. Schultz authored
As only the hardware access functions up til and including mv88e6xxx_g1_atu_mac_read() called under the interrupt handler need to take the chip lock, we release the chip lock after this call. The follow up code that handles the violations can run without the chip lock held. In further patches, the violation handler function will even be incompatible with having the chip lock held. This due to an AB/BA ordering inversion with rtnl_lock(). Signed-off-by:
-
Hans J. Schultz authored
The default return value -EOPNOTSUPP of mv88e6xxx_port_bridge_flags() came from the return value of the DSA method port_egress_floods() in commit 4f85901f ("net: dsa: mv88e6xxx: add support for bridge flags"), but the DSA API was changed in commit a8b659e7 ("net: dsa: act as passthrough for bridge port flags"), resulting in the return value -EOPNOTSUPP not being valid anymore, and sections for new flags will not need to set the return value to zero on success, as with the new mab flag added in a following patch. Signed-off-by:
-
Raju Rangoju authored
Add the necessary changes to support 10 Mbps speed for BaseT and SFP port modes. This is supported in MAC ver >= 30H. Signed-off-by:
Raju Rangoju <Raju.Rangoju@amd.com> Link: https://lore.kernel.org/r/20230109101819.747572-1-Raju.Rangoju@amd.comSigned-off-by:
-
Jamie Gloudon authored
This enables link partner advertised support to show link modes and pause frame use. Signed-off-by:
Jamie Gloudon <jamie.gloudon@gmx.fr> Tested-by:
Naama Meir <naamax.meir@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by:
-
- 09 Jan, 2023 2 commits
-
-
Jakub Kicinski authored
Since commit ce098da1 ("skbuff: Introduce slab_build_skb()") drivers trying to build skb around slab-backed buffers should go via slab_build_skb() rather than passing frag_size = 0 to the main build_skb(). Remove the copy'n'pasted comments about 0 meaning slab. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjørn Mork says: ==================== r8152: allow firmwares with NCM support Some device and firmware combinations with NCM support will end up using the cdc_ncm driver by default. This is sub- optimal for the same reasons we've previously accepted the blacklist hack in cdc_ether. The recent support for subclassing the generic USB device driver allows us to create a very slim driver with the same functionality. This patch set uses that to implement a device specific configuration default which is independent of any USB interface drivers. This means that it works equally whether the device initially ends up in NCM or ECM mode, without depending on any code in the respective class drivers. ==================== Signed-off-by:
-
