- 27 Jul, 2023 40 commits
-
-
Jiri Pirko authored
As esw_offloads_load/unload_rep() are used outside eswitch.c it is nicer for them to have "mlx5_" prefix. Add it. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Shay Drory <shayd@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Jiri Pirko authored
mlx5_eswitch_load/unload_vport()() functions are not used outside of eswitch.c. Make them static. Signed-off-by:
-
Jiri Pirko authored
mlx5_esw_offloads_rep_load/unload() functions are not used outside of eswitch_offloads.c. Make them static. Signed-off-by:
-
Jiri Pirko authored
It is guaranteed that the devlink rate leaf is created during init paths. No need to check during cleanup. Remove the checks. Signed-off-by:
-
Jiri Pirko authored
vport->enabled is always set for a vport for which a devlink port is registered, therefore the checks in the ops are pointless. Remove those. Signed-off-by:
-
Parav Pandit authored
Get and set flow classification filters are used in a single file. Hence, make them static. Signed-off-by:
Parav Pandit <parav@nvidia.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Signed-off-by:
-
Parav Pandit authored
Flow table and priority detection is same for IP user flows and other L4 flows. Hence, use same code for all these flow types. Signed-off-by:
-
Shay Drory authored
Command stats is an array with more than 2K entries, which amounts to ~180KB. This is way more than actually needed, as only ~190 entries are being used. Therefore, replace the array with xarray. Signed-off-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Shay Drory authored
There is no need to destroy and allocate cmd SW structs during reload, this is time consuming for no reason. Hence, split mlx5_cmd_init() to probe and reload routines. Signed-off-by:
-
Shay Drory authored
mlx5 is checking the cmdif revision twice, for no reason. Remove the latter check. Signed-off-by:
-
Shay Drory authored
Downstream patch will split mlx5_cmd_init() to probe and reload routines. As a preparation, organize mlx5_cmd struct so that any field that will be used in the reload routine are grouped at new nested struct. Signed-off-by:
-
Roi Dayan authored
New features could use the devcom interface but not necessarily the lag feature although for vport managers and ECPF still check for lag support. Signed-off-by:
-
Roi Dayan authored
Register devcom devices with switch id instead of guid. Devcom interface is used to sync between ports in the eswitch, e.g. Adding miss rules between the ports. New eswitch devices could have the same guid but a different switch id so its more correct to group according to switch id which is the identifier if the ports are on the same eswitch. Signed-off-by:
-
Roi Dayan authored
Update devcom infrastructure to be more generic, without depending on max supported ports definition or a device guid, and also more encapsulated so callers don't need to pass the register devcom component id per event call. Signed-off-by:
Eli Cohen <elic@nvidia.com> Signed-off-by:
-
Roi Dayan authored
Move shared function to check lag is supported to lag header file. Signed-off-by:
-
Paolo Abeni authored
Arseniy Krasnov says: ==================== virtio/vsock: some updates for MSG_PEEK flag This patchset does several things around MSG_PEEK flag support. In general words it reworks MSG_PEEK test and adds support for this flag in SOCK_SEQPACKET logic. Here is per-patch description: 1) This is cosmetic change for SOCK_STREAM implementation of MSG_PEEK: 1) I think there is no need of "safe" mode walk here as there is no "unlink" of skbs inside loop (it is MSG_PEEK mode - we don't change queue). 2) Nested while loop is removed: in case of MSG_PEEK we just walk over skbs and copy data from each one. I guess this nested loop even didn't behave as loop - it always executed just for single iteration. 2) This adds MSG_PEEK support for SOCK_SEQPACKET. It could be implemented be reworking MSG_PEEK callback for SOCK_STREAM to support SOCK_SEQPACKET also, but I think it will be more simple and clear from potential bugs to implemented it as separate function thus not mixing logics for both types of socket. So I've added it as dedicated function. 3) This is reworked MSG_PEEK test for SOCK_STREAM. Previous version just sent single byte, then tried to read it with MSG_PEEK flag, then read it in normal way. New version is more complex: now sender uses buffer instead of single byte and this buffer is initialized with random values. Receiver tests several things: 1) Read empty socket with MSG_PEEK flag. 2) Read part of buffer with MSG_PEEK flag. 3) Read whole buffer with MSG_PEEK flag, then checks that it is same as buffer from 2) (limited by size of buffer from 2) of course). 4) Read whole buffer without any flags, then checks that it is same as buffer from 3). 4) This is MSG_PEEK test for SOCK_SEQPACKET. It works in the same way as for SOCK_STREAM, except it also checks combination of MSG_TRUNC and MSG_PEEK. ==================== Link: https://lore.kernel.org/r/20230725172912.1659970-1-AVKrasnov@sberdevices.ruSigned-off-by:Paolo Abeni <pabeni@redhat.com>
-
Arseniy Krasnov authored
This adds MSG_PEEK test for SOCK_SEQPACKET. It works in the same way as SOCK_STREAM test, except it also tests MSG_TRUNC flag. Signed-off-by:
Arseniy Krasnov <AVKrasnov@sberdevices.ru> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Arseniy Krasnov authored
This new version makes test more complicated by adding empty read, partial read and data comparisons between MSG_PEEK and normal reads. Signed-off-by:
-
Arseniy Krasnov authored
This adds support of MSG_PEEK flag for SOCK_SEQPACKET type of socket. Difference with SOCK_STREAM is that this callback returns either length of the message or error. Signed-off-by:
-
Arseniy Krasnov authored
This reworks current implementation of MSG_PEEK logic: 1) Replaces 'skb_queue_walk_safe()' with 'skb_queue_walk()'. There is no need in the first one, as there are no removes of skb in loop. 2) Removes nested while loop - MSG_PEEK logic could be implemented without it: just iterate over skbs without removing it and copy data from each until destination buffer is not full. Signed-off-by:
Bobby Eshleman <bobby.eshleman@bytedance.com> Reviewed-by:
-
Dan Carpenter authored
These functions returns type bool, not pointers, so return false instead of NULL. Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/52d0814a-7287-4160-94b5-ac7939ac61c6@moroto.mountainSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Daniel Golle says: ==================== net: ethernet: mtk_eth_soc: add basic support for MT7988 SoC The MediaTek MT7988 SoC introduces a new version (3) of the NETSYS block and comes with three instead of two MACs. The first MAC can be internally connected to a built-in Gigabit Ethernet switch with four 1000M/100M/10M twisted pair user ports. The second MAC can be internally connected to a built-in 2500Base-T Ethernet PHY. There are two SerDes units which can be operated in USXGMII, 10GBase-(K)R, 5GBase-R, 2500Base-X, 1000Base-X or SGMII interface mode. This series adds initial support for NETSYS v3 and the first MAC of the MT7988 SoC connecting the built-in DSA switch. The switch is supported since commit 110c18bf ("net: dsa: mt7530: introduce driver for MT7988 built-in switch"). Basic support for the 1000M/100M/10M built-in PHYs connected to the switch ports is present since commit ("98c485ea net: phy: add driver for MediaTek SoC built-in GE PHYs"). ==================== Link: https://lore.kernel.org/r/cover.1690246066.git.daniel@makrotopia.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce support for ethernet chip available in MT7988 SoC to mtk_eth_soc driver. As a first step support only the first GMAC which is hard-wired to the internal DSA switch having 4 built-in gigabit Ethernet PHYs. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/25c8377095b95d186872eeda7aa055da83e8f0ca.1690246605.git.daniel@makrotopia.orgSigned-off-by:
-
Daniel Golle authored
The to-be-added MT7988 SoC adds many new clocks which need to be controlled by the Ethernet driver, which will result in their total number exceeding 32. Prepare by converting clock bitmaps into 64-bit types. Signed-off-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce NETSYS_V3 chipset version support. This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by:
-
Lorenzo Bianconi authored
Get rid of MTK_MAC_COUNT since it is a duplicated of MTK_MAX_DEVS. Signed-off-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add MT7988 SoC support since it runs 3 macs instead of 2. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce version field in mtk_soc_data data structure in order to make mtk_eth driver easier to maintain for chipset configuration codebase. Get rid of MTK_NETSYS_V2 bit in chip capabilities. This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by:
-
Daniel Golle authored
Introduce DT bindings for the MT7988 SoC to mediatek,net.yaml. The MT7988 SoC got 3 Ethernet MACs operating at a maximum of 10 Gigabit/sec supported by 2 packet processor engines for offloading tasks. The first MAC is hard-wired to a built-in switch which exposes four 1000Base-T PHYs as user ports. It also comes with built-in 2500Base-T PHY which can be used with the 2nd GMAC. The 2nd and 3rd GMAC can be connected to external PHYs or provide SFP(+) cages attached via SGMII, 1000Base-X, 2500Base-X, USXGMII, 5GBase-KR or 10GBase-KR. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/3c83d2c0d629dac064ec4396132538c52e77a57f.1690246066.git.daniel@makrotopia.orgSigned-off-by:
-
Daniel Golle authored
Document the Ethernet controller found in the MediaTek MT7621 MIPS SoC family which is supported by the mtk_eth_soc driver. Fixes: 889bcbde ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/ec4371c4b5a331c5217b5f13a0c9e6c444838e14.1690246066.git.daniel@makrotopia.orgSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230724211905.805665-1-robh@kernel.orgSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230724211859.805481-1-robh@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Speed up transceiver module EEPROM dump Ido Schimmel writes: Old firmware versions could only read up to 48 bytes from a transceiver module's EEPROM in one go. Newer versions can read up to 128 bytes, resulting in fewer transactions. Query support for the new capability during driver initialization and if supported, read up to 128 bytes in one go. This is going to be especially useful for upcoming transceiver module firmware flashing support. Before: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 3 devlink:devlink_hwmsg After: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 1 devlink:devlink_hwmsg Patches #1-#4 are preparations / cleanups. Patch #5 adds support for the new read size. ==================== Link: https://lore.kernel.org/r/cover.1690281940.git.petrm@nvidia.comSigned-off-by: -
Ido Schimmel authored
Old firmware versions could only read up to 48 bytes from a transceiver module's EEPROM in one go. Newer versions can read up to 128 bytes, resulting in fewer transactions. Query support for the new capability during driver initialization and if supported, read up to 128 bytes in one go. This is going to be especially useful for upcoming transceiver module firmware flashing support. Before: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 3 devlink:devlink_hwmsg After: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 1 devlink:devlink_hwmsg Signed-off-by:Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
The layout of the register always supported 128 bytes payloads, but the driver defined the register with a shorter length because it uses a maximum payload size of 48 bytes. Increase the register's length in preparation for using 128 bytes payloads. Signed-off-by:
-
Ido Schimmel authored
The 'lock' argument is always set to the default value of '0'. Remove it from the arguments list. Signed-off-by:
-
Amit Cohen authored
MCAM register reports the device supported management features. Querying this register exposes if features are supported with the current firmware version in the current ASIC. Then, the driver can separate between different implementations dynamically. MCAM register supports querying whether the MCIA register supports 128 bytes payloads or only 48 bytes. Add support for the register as preparation for allowing larger MCIA transactions. Note that the access to the bits in the field 'mng_feature_cap_mask' is not same to other mask fields in other registers. In most of the cases bit #0 is the first one in the last dword, in MCAM register, bits #0-#31 are in the first dword and so on. Declare the mask field using bits arrays per dword to simplify the access. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
-
Amit Cohen authored
The array 'mlxsw_reg_infos' is ordered by registers' IDs. The ID of MPSC register is 0x9080, so it should be after MCDA (register ID 0x9063) and not after MTUTC (register ID 0x9055). Note that the register's fields are defined in the correct place in the file, only the definition in 'mlxsw_reg_infos' is wrong. This issue was found while adding new register which supposed to be before mpsc. Signed-off-by:
-
Krzysztof Kozlowski authored
Each regulator node, which references common regulator.yaml schema, should disallow additional or unevaluated properties. Otherwise mistakes in properties will go unnoticed. Signed-off-by:
-
