- 27 Jul, 2023 38 commits
-
-
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:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Shay Drory <shayd@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
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:
-
Geert Uytterhoeven authored
The Broadcom ASP 2.0 Ethernet controller is only present on Broadcom STB SoCs. Hence add a dependency on ARCH_BRCMSTB, to prevent asking the user about this driver when configuring a kernel without Broadcom ARM-based set-top box chipset support. Fixes: 490cb412 ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Justin Chen <justin.chen@broadcom.com> Link: https://lore.kernel.org/r/1e8b998aa8dcc6e38323e295ee2430b48245cc79.1690299794.git.geert+renesas@glider.beSigned-off-by:
-
Tristram Ha authored
Microchip LAN8740/LAN8742 PHYs support basic unicast, broadcast, and Magic Packet WoL. They have one pattern filter matching up to 128 bytes of frame data, which can be used to implement ARP or multicast WoL. ARP WoL matches any ARP frame with broadcast address. Multicast WoL matches any multicast frame. Signed-off-by:
Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by:
-
- 26 Jul, 2023 2 commits
-
-
Peter Seiderer authored
Remove unused HAVE_HW_TIME_STAMP feature define (introduced by commit ac45f602 ("net: infrastructure for hardware time stamping"). Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== ice: switchdev bridge offload Wojciech Drewek says: Linux bridge provides ability to learn MAC addresses and vlans detected on bridge's ports. As a result of this, FDB (forward data base) entries are created and they can be offloaded to the HW. By adding VF's port representors to the bridge together with the uplink netdev, we can learn VF's and link partner's MAC addresses. This is achieved by slow/exception-path, where packets that do not match any filters (FDB entries in this case) are send to the bridge ports. Driver keeps track of the netdevs added to the bridge by listening for NETDEV_CHANGEUPPER event. We distinguish two types of bridge ports: uplink port and VF's representor port. Linux bridge always learns src MAC of the packet on rx path. With the current slow-path implementation, it means that we will learn VF's MAC on port repr (when the VF transmits the packet) and link partner's MAC on uplink (when we receive it on uplink from LAN). The driver is notified about learning of the MAC/VLAN by SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation of the HW filter. The direction of the filter is based on port type (uplink or VF repr). In case of the uplink, rule forwards the packets to the LAN (matching on link partner's MAC). When the notification is received on VF repr then the rule forwards the packets to the associated VF (matching on VF's MAC). This approach would not work on its own however. This is because if one of the directions is offloaded, then the bridge would not be able to learn the other one. If the egress rule is added (learned on uplink) then the response from the VF will be sent directly to the LAN. The packet will not got through slow-path, it would not be seen on VF's port repr. Because of that, the bridge would not learn VF's MAC. This is solved by introducing guard rule. It prevents forward rule from working until the opposite direction is offloaded. Aging is not fully supported yet, aging time is static for now. The follow up submissions will introduce counters that will allow us to keep track if the rule is actually being used or not. A few fixes/changes are needed for this feature to work with ice driver. These are introduced in first 5 patches. Reviewed-by:Vlad Buslov <vladbu@nvidia.com> * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: add tracepoints for the switchdev bridge ice: implement static version of ageing ice: implement bridge port vlan ice: Add VLAN FDB support in switchdev mode ice: Add guard rule when creating FDB in switchdev ice: Switchdev FDB events support ice: Implement basic eswitch bridge setup ice: Unset src prune on uplink VSI ice: Disable vlan pruning for uplink VSI ice: Don't tx before switchdev is fully configured ice: Prohibit rx mode change in switchdev mode ice: Skip adv rules removal upon switchdev release ==================== Link: https://lore.kernel.org/r/20230724161152.2177196-1-anthony.l.nguyen@intel.comSigned-off-by:
-
