- 17 Mar, 2023 7 commits
-
-
Shradha Gupta authored
Extended performance counter stats in 'ethtool -S <interface>' output for MANA VF to facilitate troubleshooting. Tested-on: Ubuntu22 Signed-off-by:
Shradha Gupta <shradhagupta@linux.microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mengyuan Lou authored
Add ngbe and txgbe ndo_change_mtu support. Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Signed-off-by:
-
Luiz Angelo Daros de Luca authored
The rtl8365mb was using a fixed MTU size of 1536, which was probably inspired by the rtl8366rb's initial frame size. However, unlike that family, the rtl8365mb family can specify the max frame size in bytes, rather than in fixed steps. DSA calls change_mtu for the CPU port once the max MTU value among the ports changes. As the max frame size is defined globally, the switch is configured only when the call affects the CPU port. The available specifications do not directly define the max supported frame size, but it mentions a 16k limit. This driver will use the 0x3FFF limit as it is used in the vendor API code. However, the switch sets the max frame size to 16368 bytes (0x3FF0) after it resets. change_mtu uses MTU size, or ethernet payload size, while the switch works with frame size. The frame size is calculated considering the ethernet header (14 bytes), a possible 802.1Q tag (4 bytes), the payload size (MTU), and the Ethernet FCS (4 bytes). The CPU tag (8 bytes) is consumed before the switch enforces the limit. During setup, the driver will use the default 1500-byte MTU of DSA to set the maximum frame size. The current sum will be VLAN_ETH_HLEN+1500+ETH_FCS_LEN, which results in 1522 bytes. Although it is lower than the previous initial value of 1536 bytes, the driver will increase the frame size for a larger MTU. However, if something requires more space without increasing the MTU, such as QinQ, we would need to add the extra length to the rtl8365mb_port_change_mtu() formula. MTU was tested up to 2018 (with 802.1Q) as that is as far as mt7620 (where rtl8367s is stacked) can go. The register was manually manipulated byte-by-byte to ensure the MTU to frame size conversion was correct. For frames without 802.1Q tag, the frame size limit will be 4 bytes over the required size. There is a jumbo register, enabled by default at 6k frame size. However, the jumbo settings do not seem to limit nor expand the maximum tested MTU (2018), even when jumbo is disabled. More tests are needed with a device that can handle larger frames. Signed-off-by:
Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
-
Jakub Kicinski authored
Durai Manickam says: ==================== Add PTP support for sama7g5 This patch series is intended to add PTP capability to the GEM and EMAC for sama7g5. ==================== Link: https://lore.kernel.org/r/20230315095053.53969-1-durai.manickamkr@microchip.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Durai Manickam KR authored
Add PTP capability to the Ethernet MAC. Signed-off-by:
Durai Manickam KR <durai.manickamkr@microchip.com> Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by:
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by:
-
Durai Manickam KR authored
Add PTP capability to the Gigabit Ethernet MAC. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
-
- 16 Mar, 2023 31 commits
-
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to of_property_read_bool(). Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
There are no users of nfcmrvl platform_data struct outside of the driver and none will be added, so move it into the driver. Signed-off-by:
-
Xu Liang authored
GPY2xx devices need 3 seconds to fully switch out of loopback mode before it can safely re-enter loopback mode. Implement timeout mechanism to guarantee 3 seconds waited before re-enter loopback mode. Signed-off-by:
Xu Liang <lxu@maxlinear.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a pr_warn_ratelimited message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20230314082315.26532-1-colin.i.king@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Louis Peens says: ==================== nfp: flower: add support for multi-zone conntrack This series add changes to support offload of connection tracking across multiple zones. Previously the driver only supported offloading of a single goto_chain, spanning a single zone. This was implemented by merging a pre_ct rule, post_ct rule and the nft rule. This series provides updates to let the original post_ct rule act as the new pre_ct rule for a next set of merges if it contains another goto and conntrack action. In pseudo-tc rule format this adds support for: ingress chain 0 proto ip flower action ct zone 1 pipe action goto 1 ingress chain 1 proto ip flower ct_state +tr+new ct_zone 1 action ct_clear pipe action ct zone 2 pipe action goto 2 ingress chain 1 proto ip flower ct_state +tr+est ct_zone 1 action ct_clear pipe action ct zone 2 pipe action goto 2 ingress chain 2 proto ip flower ct_state +tr+new ct_zone 2 action mirred egress redirect dev ... ingress chain 2 proto ip flower ct_state +tr+est ct_zone 2 action mirred egress redirect dev ... This can continue for up to a maximum of 4 zone recirculations. The first few patches are some smaller preparation patches while the last one introduces the functionality. ==================== Link: https://lore.kernel.org/r/20230314063610.10544-1-louis.peens@corigine.comSigned-off-by: -
Wentao Jia authored
If goto_chain action present in the post ct flow rule, merge flow rules in this ct-zone, create a new pre_ct entry as the pre ct flow rule of next ct-zone, but do not offload merged flow rules to firmware. Repeat the process in the next ct-zone until no goto_chain action present in the post ct flow rule in a certain ct-zone, merged all the flow rules. Offload to firmware finally. Signed-off-by:
Wentao Jia <wentao.jia@corigine.com> Acked-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
-
Wentao Jia authored
The fixed number of offload flow rule is only supported scenario of one ct zone, in the scenario of multiple ct zones, dynamic number and more number of offload flow rules are required. In order to support scenario of multiple ct zones, parameter num_rules is added for to offload flow rules Signed-off-by:
-
Wentao Jia authored
The chain_index has different means in pre ct entry and post ct entry. In pre ct entry, it means chain index, but in post ct entry, it means goto chain index, it is confused. chain_index and goto_chain_index may be present in one flow rule, It cannot be distinguished by one field chain_index, both chain_index and goto_chain_index are required in the follow-up patch to support multiple ct zones Another field goto_chain_index is added to record the goto chain index. If no goto action in post ct entry, goto_chain_index is 0. Signed-off-by:
-
Wentao Jia authored
'ct_clear' action only or no ct action is supported for 'post_ct_flow'. But in scenario of multiple ct zones, one non 'ct_clear' ct action or more ct actions, including 'ct_clear action', may be present in one flow rule. If ct state match key is 'ct_established', the flow rule is still expected to be classified as 'post_ct_flow'. Check ct status first in function "is_post_ct_flow" to achieve this. Signed-off-by:
-
Wentao Jia authored
In the scenario of multiple ct zones, ct state key match and ct action is present in one flow rule, the flow rule is classified to post_ct_flow in design. There is no ct state key match for pre ct flow, the judging condition is added to function "is_pre_ct_flow". Chain_index is another field for judging which flows are pre ct flow If chain_index not 0, the flow is not pre ct flow. Signed-off-by:
-
Wentao Jia authored
CT action is a special case different from other actions, CT clear action is not required when get ct action, but this case is not considered. If CT clear action in the flow rule, skip the CT clear action when get ct action, return the first ct action that is not a CT clear action Signed-off-by:
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2023-03-13 1) Trivial cleanup patches 2) By Sandipan Patra: Implement thermal zone to report NIC temperature 3) Adham Faris, Improves devlink health diagnostics for netdev objects 4) From Maor, Enable TC offload for egress and engress MACVLAN over bond 5) From Gal, add devlink hairpin queues parameters to replace debugfs as was discussed in [1]: [1] https://lore.kernel.org/all/20230111194608.7f15b9a1@kernel.org/ ==================== Link: https://lore.kernel.org/all/20230314054234.267365-1-saeed@kernel.org/Signed-off-by:
-
Maor Dickman authored
Support offloading of TC rules that mirror/redirect egress traffic to a MACVLAN device, which is attached to bond device which master mlx5 devices. Signed-off-by:
Maor Dickman <maord@nvidia.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20230314054234.267365-16-saeed@kernel.orgSigned-off-by:
-
Maor Dickman authored
Support offloading of TC rules that filter ingress traffic from a MACVLAN device, which is attached to bond device. Signed-off-by:
-
Maor Dickman authored
In preparation for next patch which will add new check if device block can be setup, extract all existing checks to function to make it more readable and maintainable. Signed-off-by:
-
Gal Pressman authored
Print the number of hairpin queues and size as part of the hairpin table dump. Signed-off-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-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. Per the discussion in [1], move the hairpin queues control (number and size) from debugfs to devlink. Expose two devlink params: - hairpin_num_queues: control the number of hairpin queues - hairpin_queue_size: control the size (in packets) of the hairpin queues [1] https://lore.kernel.org/all/20230111194608.7f15b9a1@kernel.org/Signed-off-by:
-
Gal Pressman authored
Downstream patches require devlink params to access the PTYS register, move the needed functions from mlx5e to the core layer. Signed-off-by:
-
Adham Faris authored
Currently RQ health diagnostics doesn't inform the user whether an RQ is an XSK RQ or not. Address this, by adding XSK state flag to RQ SW state enum in core/en.h. XSK will be '1' if current RQ is an XSK RQ, and it will be '0' if it's not. In this example below, it can be seen that XSK field value is '1' since xdpsock program have been attached to channel 0 before issuing the devlink query command: $ devlink health diagnose auxiliary/mlx5_core.eth.0/65535 reporter rx Output: ======================================================================= Common config: RQ: type: 2 stride size: 4096 size: 16 ts_format: FRC CQ: stride size: 64 size: 1024 RQs: channel ix: 0 rqn: 4236 HW state: 1 WQE counter: 15 posted WQEs: 15 cc: 15 SW State: enabled: 1 recovering: 0 am: 1 no_csum_complete: 1 csum_full: 0 mini_cqe_hw_stridx: 1 shampo: 0 mini_cqe_enhanced: 0 xsk: 1 CQ: cqn: 1085 HW status: 0 ci: 0 size: 1024 EQ: eqn: 7 irqn: 32 vecidx: 0 ci: 5 size: 2048 ICOSQ: sqn: 4229 HW state: 1 cc: 158 pc: 158 WQE size: 2048 CQ: cqn: 1080 cc: 1 size: 2048 Signed-off-by:Adham Faris <afaris@nvidia.com> Reviewed-by:
-
Adham Faris authored
Add SQ SW state textual representation to devlink health diagnostics for tx reporter. SQ SW state can be retrieved by issuing the devlink command below: $ devlink health diagnose auxiliary/mlx5_core.eth.0/65535 reporter tx Output ======================================================================= Common Config: SQ: stride size: 64 size: 1024 ts_format: FRC CQ: stride size: 64 size: 1024 SQs: channel ix: 0 tc: 0 txq ix: 0 sqn: 4170 HW state: 1 stopped: false cc: 0 pc: 0 SW State: enabled: 1 mpwqe: 1 recovering: 0 ipsec: 0 am: 1 vlan_need_l2_inline: 1 pending_xsk_tx: 0 pending_tls_rx_resync: 0 xdp_multibuf: 0 CQ: cqn: 1031 HW status: 0 ci: 0 size: 1024 EQ: eqn: 7 irqn: 32 vecidx: 0 ci: 2 size: 2048 Signed-off-by: -
Adham Faris authored
One of the parameters that is retrieved/printed as a response to devlink health diagnostics for rx reporter is the RQ SW state. It's printed as a bitmap decimal number. Printing it as bitmap is problematic and non informative. In addition User can't count on SW state without accessing the kernel sources (mlx5e rq state enum in en.h). This patch prints RQ SW state in a textual representation, as a key: value pairs, where disabled rq states will appear as '0' and enabled ones will appear as '1'. See below the generated output for rx health diagnostics devlink command: $ devlink health diagnose auxiliary/mlx5_core.eth.0/65535 reporter rx Before: ======================================================================= Common config: RQ: type: 2 stride size: 2048 size: 8 ts_format: FRC CQ: stride size: 64 size: 1024 RQs: channel ix: 0 rqn: 4172 HW state: 1 SW state: 37 WQE counter: 7 posted WQEs: 7 cc: 7 CQ: cqn: 1033 HW status: 0 ci: 0 size: 1024 EQ: eqn: 7 irqn: 32 vecidx: 0 ci: 2 size: 2048 ICOSQ: sqn: 4169 HW state: 1 cc: 74 pc: 74 WQE size: 128 CQ: cqn: 1030 cc: 1 size: 128 channel ix: 1 ... . . After: ======================================================================= Common config: RQ: type: 2 stride size: 2048 size: 8 ts_format: FRC CQ: stride size: 64 size: 1024 RQs: channel ix: 0 rqn: 4172 HW state: 1 WQE counter: 7 posted WQEs: 7 cc: 7 SW State: enabled: 1 recovering: 0 am: 1 no_csum_complete: 0 csum_full: 0 mini_cqe_hw_stridx: 1 shampo: 0 mini_cqe_enhanced: 0 CQ: cqn: 1033 HW status: 0 ci: 0 size: 1024 EQ: eqn: 7 irqn: 32 vecidx: 0 ci: 2 size: 2048 ICOSQ: sqn: 4169 HW state: 1 cc: 74 pc: 74 WQE size: 128 CQ: cqn: 1030 cc: 1 size: 128 channel: ix: 1 ... . . Signed-off-by: -
Adham Faris authored
Dynamic interrupt moderation RQ and SQ feature represented by MLX5E_RQ_STATE_AM and MLX5E_SQ_STATE_AM enums respectively, is not consistent with the feature naming in the driver, and with the formal feature and library names. Hence, change MLX5E_RQ_STATE_AM and MLX5E_SQ_STATE_AM enum type names in core/en.h to MLX5E_RQ_STATE_DIM and MLX5E_SQ_STATE_DIM respectively. Signed-off-by:
-
Rahul Rameshbabu authored
Previous check was comparing against the fifo mask. The mask is size of the fifo (power of two) minus one, so a less than or equal comparator should be used for checking if the fifo has room for the SKB. Signed-off-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Reviewed-by:
-
Sandipan Patra authored
Implement thermal zone support for mlx5 based HW. The NIC uses temperature sensor provided by ASIC to report current temperature to thermal core. Signed-off-by:
Sandipan Patra <spatra@nvidia.com> Reviewed-by:
-
Jiri Pirko authored
Add comment to mlx5_devlink_params_register() functions so it is clear that only driver init params should be registered here. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Moshe Shemesh authored
If driver teardown is called while PCI is turned off, there is a race between health recovery and teardown. If health recovery already started it will wait 60 sec trying to see if PCI gets back and it can recover, but actually there is no need to wait anymore once teardown was called. Use the MLX5_BREAK_FW_WAIT flag which is set on driver teardown to break waiting for PCI up. Signed-off-by:
Moshe Shemesh <moshe@mellanox.com> Signed-off-by:
-
Moshe Shemesh authored
When shutdown or remove callbacks are called the driver sets the flag MLX5_BREAK_FW_WAIT, to stop waiting for FW as teardown was called. There is no need to clear the bit as once shutdown or remove were called as there is no way back, the driver is going down. Furthermore, if not cleared the flag can be used also in other loops where we may wait while teardown was already called. Use test_bit() instead of test_and_clear_bit() as there is no need to clear the flag. Signed-off-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Wolfram Sang authored
'temp' was used before commit c0c99d0c ("net: phy: micrel: remove the use of .ack_interrupt()") refactored the code. Now, we can simplify it a little. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230314124928.44948-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Wolfram Sang authored
Commit 899a3cbb ("net: phy: remove states PHY_STARTING and PHY_PENDING") missed to update a comment in phy_probe. Remove superfluous "Description:" prefix while we are here. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20230314124856.44878-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== ice: refactor mailbox overflow detection Jake Keller says: The primary motivation of this series is to cleanup and refactor the mailbox overflow detection logic such that it will work with Scalable IOV. In addition a few other minor cleanups are done while I was working on the code in the area. First, the mailbox overflow functions in ice_vf_mbx.c are refactored to store the data per-VF as an embedded structure in struct ice_vf, rather than stored separately as a fixed-size array which only works with Single Root IOV. This reduces the overall memory footprint when only a handful of VFs are used. The overflow detection functions are also cleaned up to reduce the need for multiple separate calls to determine when to report a VF as potentially malicious. Finally, the ice_is_malicious_vf function is cleaned up and moved into ice_virtchnl.c since it is not Single Root IOV specific, and thus does not belong in ice_sriov.c I could probably have done this in fewer patches, but I split pieces out to hopefully aid in reviewing the overall sequence of changes. This does cause some additional thrash as it results in intermediate versions of the refactor, but I think its worth it for making each step easier to understand. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg() ice: move ice_is_malicious_vf() to ice_virtchnl.c ice: print message if ice_mbx_vf_state_handler returns an error ice: pass mbxdata to ice_is_malicious_vf() ice: remove unnecessary &array[0] and just use array ice: always report VF overflowing mailbox even without PF VSI ice: declare ice_vc_process_vf_msg in ice_virtchnl.h ice: initialize mailbox snapshot earlier in PF init ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler ice: remove ice_mbx_deinit_snapshot ice: move VF overflow message count into struct ice_mbx_vf_info ice: track malicious VFs in new ice_mbx_vf_info structure ice: convert ice_mbx_clear_malvf to void and use WARN ice: re-order ice_mbx_reset_snapshot function ==================== Link: https://lore.kernel.org/r/20230313182123.483057-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it might not be relevant here). This also fixes !CONFIG_OF error: drivers/ptp/ptp_ines.c:783:34: error: ‘ines_ptp_ctrl_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20230312132637.352755-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
- 15 Mar, 2023 2 commits
-
-
Alexander Mikhalitsyn authored
Currently, kernel would set MSG_CTRUNC flag if msg_control buffer wasn't provided and SO_PASSCRED was set or if there was pending SCM_RIGHTS. For some reason we have no corresponding check for SO_PASSSEC. In the recvmsg(2) doc we have: MSG_CTRUNC indicates that some control data was discarded due to lack of space in the buffer for ancillary data. So, we need to set MSG_CTRUNC flag for all types of SCM. This change can break applications those don't check MSG_CTRUNC flag. 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: Leon Romanovsky <leon@kernel.org> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> v2: - commit message was rewritten according to Eric's suggestion Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
David S. Miller authored
Wenjia Zhang says: ==================== smc: Updates 2023-03-01 The 1st patch is to make implements later do not need to adhere to a specific SEID format. The 2nd patch does some cleanup. ==================== Signed-off-by:
-
