Searched +hist:4 +hist:ae57566 (Results 1 - 5 of 5) sorted by relevance
/linux-master/drivers/net/ethernet/mellanox/mlxfw/ | ||
H A D | Kconfig | diff a7f7f624 Sat Jun 13 10:50:22 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | mlxfw.h | diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | mlxfw_fsm.c | diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/net/ethernet/mellanox/mlx5/core/ | ||
H A D | fw.c | diff fe298bdf Sun May 22 22:10:02 MDT 2022 Jianbo Liu <jianbol@nvidia.com> net/mlx5: Prepare for fast crypto key update if hardware supports it Add CAP for crypto offload, do the simple initialization if hardware supports it. Currently set log_dek_obj_range to 12, so 4k DEKs will be created in one bulk allocation. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4ae57566 Fri Feb 21 14:45:58 MST 2020 Saeed Mahameed <saeedm@mellanox.com> net/mlxfw: Generic mlx FW flash status notify FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff b9a7ba55 Sun Jun 30 10:23:23 MDT 2019 Yishai Hadas <yishaih@mellanox.com> net/mlx5: Use event mask based on device capabilities Use the reported device capabilities for the supported user events (i.e. affiliated and un-affiliated) to set the EQ mask. As the event mask can be up to 256 defined by 4 entries of u64 change the applicable code to work accordingly. Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> diff 6c750628 Thu Feb 01 06:34:35 MST 2018 Alaa Hleihel <alaa@mellanox.com> net/mlx5: Change teardown with force mode failure message to warning With ConnectX-4, we expect the force teardown to fail in case that DC was enabled, therefore change the message from error to warning. Signed-off-by: Alaa Hleihel <alaa@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> diff 4ce749bd Thu Jun 08 07:15:10 MDT 2017 Yishai Hadas <yishaih@mellanox.com> net/mlx5: Report enhanced capabilities for IPoIB Report 'ipoib_enhanced_offloads' capabilities from the core layer, it will be used in the next patch from this series. Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Reviewed-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> |
/linux-master/drivers/net/ethernet/mellanox/mlxsw/ | ||
H A D | spectrum.c | diff b46c1f3f Wed Oct 18 16:27:20 MDT 2023 Petr Machata <petrm@nvidia.com> mlxsw: spectrum: Set SW LAG mode on Spectrum>1 On Spectrum-2, Spectrum-3 and Spectrum-4 machines, request SW responsibility for placement of the LAG table. On Spectrum-1, some FW versions claim to support lag_mode field despite quietly ignoring any settings made to that field. Thus refrain from attempting to configure lag_mode on those systems at all. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 74cbc3c0 Mon Feb 06 08:39:22 MST 2023 Ido Schimmel <idosch@nvidia.com> mlxsw: spectrum_acl_tcam: Move devlink param to TCAM code Cited commit added 'DEVLINK_CMD_PARAM_DEL' notifications whenever the network namespace of the devlink instance is changed. Specifically, the notifications are generated after calling reload_down(), but before calling reload_up(). At this stage, the data structures accessed while reading the value of the "acl_region_rehash_interval" devlink parameter are uninitialized, resulting in a use-after-free [1]. Fix by moving the registration and unregistration of the devlink parameter to the TCAM code where it is actually used. This means that the parameter is unregistered during reload_down() and then re-registered during reload_up(), avoiding the use-after-free between these two operations. Reproducer: # ip netns add test123 # devlink dev reload pci/0000:06:00.0 netns test123 [1] BUG: KASAN: use-after-free in mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xb2/0xd0 Read of size 4 at addr ffff888162fd37d8 by task devlink/1323 [...] Call Trace: <TASK> dump_stack_lvl+0x95/0xbd print_report+0x181/0x4a1 kasan_report+0xdb/0x200 mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xb2/0xd0 mlxsw_sp_params_acl_region_rehash_intrvl_get+0x32/0x80 devlink_nl_param_fill.constprop.0+0x29a/0x11e0 devlink_param_notify.constprop.0+0xb9/0x250 devlink_notify_unregister+0xbc/0x470 devlink_reload+0x1aa/0x440 devlink_nl_cmd_reload+0x559/0x11b0 genl_family_rcv_msg_doit.isra.0+0x1f8/0x2e0 genl_rcv_msg+0x558/0x7f0 netlink_rcv_skb+0x170/0x440 genl_rcv+0x2d/0x40 netlink_unicast+0x53f/0x810 netlink_sendmsg+0x961/0xe80 __sys_sendto+0x2a4/0x420 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 7d7e9169a3ec ("devlink: move devlink reload notifications back in between _down() and _up() calls") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff c503d8ae Fri Aug 26 10:06:52 MDT 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Add a copy of 'struct mlxsw_config_profile' for Spectrum-4 Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4 and set the 'max_lag' field to 128, which is the same amount of LAG entries as in Spectrum-{2,3}. Without this configuration, firmware reserves 256 (the value of 'cap_max_lag' resource) entries at beginning of PGT table for LAG identifiers, which means that less entries in PGT will be available. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff c503d8ae Fri Aug 26 10:06:52 MDT 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Add a copy of 'struct mlxsw_config_profile' for Spectrum-4 Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4 and set the 'max_lag' field to 128, which is the same amount of LAG entries as in Spectrum-{2,3}. Without this configuration, firmware reserves 256 (the value of 'cap_max_lag' resource) entries at beginning of PGT table for LAG identifiers, which means that less entries in PGT will be available. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff c503d8ae Fri Aug 26 10:06:52 MDT 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Add a copy of 'struct mlxsw_config_profile' for Spectrum-4 Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4 and set the 'max_lag' field to 128, which is the same amount of LAG entries as in Spectrum-{2,3}. Without this configuration, firmware reserves 256 (the value of 'cap_max_lag' resource) entries at beginning of PGT table for LAG identifiers, which means that less entries in PGT will be available. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff 24157bc6 Wed Jul 27 00:23:25 MDT 2022 Danielle Ratson <danieller@nvidia.com> mlxsw: Send PTP packets as data packets to overcome a limitation In Spectrum-2 and Spectrum-3, the correction field of PTP packets which are sent as control packets is not updated at egress port. To overcome this limitation, PTP packets which require time stamp, should be sent as data packets with the following details: 1. FID valid = 1 2. FID value above the maximum FID 3. rx_router_port = 1 >From Spectrum-4 and on, this limitation will be solved. Extend the function which handles TX header, in case that the packet is a PTP packet, add TX header with type=data and all the above mentioned requirements. Add operation as part of 'struct mlxsw_sp_ptp_ops', to be able to separate the handling of PTP packets between different ASICs. Use the data packet solution only for Spectrum-2 and Spectrum-3. Therefore, add a dedicated operation structure for Spectrum-4, as it will be same to Spectrum-2 in PTP implementation, just will not have the limitation of control packets. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 24157bc6 Wed Jul 27 00:23:25 MDT 2022 Danielle Ratson <danieller@nvidia.com> mlxsw: Send PTP packets as data packets to overcome a limitation In Spectrum-2 and Spectrum-3, the correction field of PTP packets which are sent as control packets is not updated at egress port. To overcome this limitation, PTP packets which require time stamp, should be sent as data packets with the following details: 1. FID valid = 1 2. FID value above the maximum FID 3. rx_router_port = 1 >From Spectrum-4 and on, this limitation will be solved. Extend the function which handles TX header, in case that the packet is a PTP packet, add TX header with type=data and all the above mentioned requirements. Add operation as part of 'struct mlxsw_sp_ptp_ops', to be able to separate the handling of PTP packets between different ASICs. Use the data packet solution only for Spectrum-2 and Spectrum-3. Therefore, add a dedicated operation structure for Spectrum-4, as it will be same to Spectrum-2 in PTP implementation, just will not have the limitation of control packets. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4ec2feb2 Thu Jun 16 04:42:37 MDT 2022 Petr Machata <petrm@nvidia.com> mlxsw: Add a resource describing number of RIFs The Spectrum ASIC has a limit on how many L3 devices (called RIFs) can be created. The limit depends on the ASIC and FW revision, and mlxsw reads it from the FW. In order to communicate both the number of RIFs that there can be, and how many are taken now (i.e. occupancy), introduce a corresponding devlink resource. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 4f8afb68 Sun May 08 02:08:16 MDT 2022 Petr Machata <petrm@nvidia.com> mlxsw: spectrum: Move handling of VRF events to router code Events involving VRF, as L3 concern, are handled in the router code, by the helper mlxsw_sp_netdevice_vrf_event(). The handler is currently invoked from the centralized dispatcher in spectrum.c. Instead, move the call to the newly-introduced router-specific notifier handler. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 47354021 Thu Jan 06 09:06:52 MST 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Extend to support Spectrum-4 ASIC Extend existing driver for Spectrum, Spectrum-2 and Spectrum-3 ASICs to support Spectrum-4 ASIC as well. Currently there is no released firmware version for Spectrum-4, so the driver is not enforcing a minimum version. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff 47354021 Thu Jan 06 09:06:52 MST 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Extend to support Spectrum-4 ASIC Extend existing driver for Spectrum, Spectrum-2 and Spectrum-3 ASICs to support Spectrum-4 ASIC as well. Currently there is no released firmware version for Spectrum-4, so the driver is not enforcing a minimum version. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff 47354021 Thu Jan 06 09:06:52 MST 2022 Amit Cohen <amcohen@nvidia.com> mlxsw: spectrum: Extend to support Spectrum-4 ASIC Extend existing driver for Spectrum, Spectrum-2 and Spectrum-3 ASICs to support Spectrum-4 ASIC as well. Currently there is no released firmware version for Spectrum-4, so the driver is not enforcing a minimum version. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
Completed in 537 milliseconds