aboutsummaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2023-04-19net/mlx5e: XDP, Remove doubtful unlikely callsTariq Toukan1-5/+5
It is not likely nor unlikely that the xdp buff has fragments, it depends on the program loaded and size of the packet received. Reviewed-by: Saeed Mahameed <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-04-19net/mlx5e: Introduce extended version for mlx5e_xmit_dataTariq Toukan5-34/+44
Introduce struct mlx5e_xmit_data_frags to be used for non-linear xmit buffers. Let it include sinfo pointer. Take one bit from the len field to indicate if the descriptor has fragments and can be casted-up into the extended version. Zero-init to make sure has_frags, and potentially future fields, are zero when not explicitly assigned. Another field will be added in a downstream patch to indicate and point to dma addresses of the different frags, for redirect-in requests. This simplifies the mlx5e_xmit_xdp_frame/mlx5e_xmit_xdp_frame_mpwqe functions params. Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-04-19net/mlx5e: Move struct mlx5e_xmit_data to datapath headerTariq Toukan2-6/+7
Move TX datapath struct from the generic en.h to the datapath txrx.h header, where it belongs. Reviewed-by: Saeed Mahameed <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-04-19net/mlx5e: Move XDP struct and enum to XDP headerTariq Toukan2-35/+35
Move struct mlx5e_xdp_info and enum mlx5e_xdp_xmit_mode from the generic en.h to the XDP header, where they belong. Reviewed-by: Saeed Mahameed <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-04-19bonding: Fix memory leak when changing bond type to EthernetIdo Schimmel1-3/+4
When a net device is put administratively up, its 'IFF_UP' flag is set (if not set already) and a 'NETDEV_UP' notification is emitted, which causes the 8021q driver to add VLAN ID 0 on the device. The reverse happens when a net device is put administratively down. When changing the type of a bond to Ethernet, its 'IFF_UP' flag is incorrectly cleared, resulting in the kernel skipping the above process and VLAN ID 0 being leaked [1]. Fix by restoring the flag when changing the type to Ethernet, in a similar fashion to the restoration of the 'IFF_SLAVE' flag. The issue can be reproduced using the script in [2], with example out before and after the fix in [3]. [1] unreferenced object 0xffff888103479900 (size 256): comm "ip", pid 329, jiffies 4294775225 (age 28.561s) hex dump (first 32 bytes): 00 a0 0c 15 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0 [<ffffffff8406426c>] vlan_vid_add+0x30c/0x790 [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0 [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0 [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150 [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0 [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180 [<ffffffff8379af36>] do_setlink+0xb96/0x4060 [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0 [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0 [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00 [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839a738f>] netlink_unicast+0x53f/0x810 [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90 [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70 [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0 unreferenced object 0xffff88810f6a83e0 (size 32): comm "ip", pid 329, jiffies 4294775225 (age 28.561s) hex dump (first 32 bytes): a0 99 47 03 81 88 ff ff a0 99 47 03 81 88 ff ff ..G.......G..... 81 00 00 00 01 00 00 00 cc cc cc cc cc cc cc cc ................ backtrace: [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0 [<ffffffff84064369>] vlan_vid_add+0x409/0x790 [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0 [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0 [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150 [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0 [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180 [<ffffffff8379af36>] do_setlink+0xb96/0x4060 [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0 [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0 [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00 [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839a738f>] netlink_unicast+0x53f/0x810 [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90 [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70 [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0 [2] ip link add name t-nlmon type nlmon ip link add name t-dummy type dummy ip link add name t-bond type bond mode active-backup ip link set dev t-bond up ip link set dev t-nlmon master t-bond ip link set dev t-nlmon nomaster ip link show dev t-bond ip link set dev t-dummy master t-bond ip link show dev t-bond ip link del dev t-bond ip link del dev t-dummy ip link del dev t-nlmon [3] Before: 12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/netlink 12: t-bond: <BROADCAST,MULTICAST,MASTER,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 46:57:39:a4:46:a2 brd ff:ff:ff:ff:ff:ff After: 12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/netlink 12: t-bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 66:48:7b:74:b6:8a brd ff:ff:ff:ff:ff:ff Fixes: e36b9d16c6a6 ("bonding: clean muticast addresses when device changes type") Fixes: 75c78500ddad ("bonding: remap muticast addresses without using dev_close() and dev_open()") Fixes: 9ec7eb60dcbc ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change") Reported-by: Mirsad Goran Todorovac <[email protected]> Link: https://lore.kernel.org/netdev/[email protected]/ Tested-by: Mirsad Goran Todorovac <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Jay Vosburgh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-04-19wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtraceHans de Goede1-1/+4
A received TKIP key may be up to 32 bytes because it may contain MIC rx/tx keys too. These are not used by iwl and copying these over overflows the iwl_keyinfo.key field. Add a check to not copy more data to iwl_keyinfo.key then will fit. This fixes backtraces like this one: memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16) WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm] <snip> Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017 RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm] <snip> Call Trace: <TASK> iwl_set_dynamic_key+0x1f0/0x220 [iwldvm] iwlagn_mac_set_key+0x1e4/0x280 [iwldvm] drv_set_key+0xa4/0x1b0 [mac80211] ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211] ieee80211_key_replace+0x22d/0x8e0 [mac80211] <snip> Link: https://www.alionet.org/index.php?topic=1469.0 Link: https://lore.kernel.org/linux-wireless/[email protected]/ Link: https://lore.kernel.org/linux-wireless/[email protected]/ Cc: Kees Cook <[email protected]> Suggested-by: Johannes Berg <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-04-18net: ethernet: stmmac: dwmac-sti: remove stih415/stih416/stid127Alain Volmat1-59/+1
Remove no more supported platforms (stih415/stih416 and stid127) Signed-off-by: Alain Volmat <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Reviewed-by: Horatiu Vultur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-18net: mscc: ocelot: remove incompatible prototypesArnd Bergmann1-3/+0
The types for the register argument changed recently, but there are still incompatible prototypes that got left behind, and gcc-13 warns about these: In file included from drivers/net/ethernet/mscc/ocelot.c:13: drivers/net/ethernet/mscc/ocelot.h:97:5: error: conflicting types for 'ocelot_port_readl' due to enum/integer mismatch; have 'u32(struct ocelot_port *, u32)' {aka 'unsigned int(struct ocelot_port *, unsigned int)'} [-Werror=enum-int-mismatch] 97 | u32 ocelot_port_readl(struct ocelot_port *port, u32 reg); | ^~~~~~~~~~~~~~~~~ Just remove the two prototypes, and rely on the copy in the global header. Fixes: 9ecd05794b8d ("net: mscc: ocelot: strengthen type of "u32 reg" in I/O accessors") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-18net: stmmac: propagate feature flags to vlanCorinna Vinschen1-0/+4
stmmac_dev_probe doesn't propagate feature flags to VLANs. So features like offloading don't correspond with the general features and it's not possible to manipulate features via ethtool -K to affect VLANs. Propagate feature flags to vlan features. Drop TSO feature because it does not work on VLANs yet. Signed-off-by: Corinna Vinschen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-18bonding: add software tx timestamping supportHangbin Liu1-0/+30
Currently, bonding only obtain the timestamp (ts) information of the active slave, which is available only for modes 1, 5, and 6. For other modes, bonding only has software rx timestamping support. However, some users who use modes such as LACP also want tx timestamp support. To address this issue, let's check the ts information of each slave. If all slaves support tx timestamping, we can enable tx timestamping support for the bond. Add a note that the get_ts_info may be called with RCU, or rtnl or reference on the device in ethtool.h> Suggested-by: Miroslav Lichvar <[email protected]> Signed-off-by: Hangbin Liu <[email protected]> Acked-by: Jay Vosburgh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-18Change DEFINE_SEMAPHORE() to take a number argumentPeter Zijlstra1-1/+1
Fundamentally semaphores are a counted primitive, but DEFINE_SEMAPHORE() does not expose this and explicitly creates a binary semaphore. Change DEFINE_SEMAPHORE() to take a number argument and use that in the few places that open-coded it using __SEMAPHORE_INITIALIZER(). Signed-off-by: Peter Zijlstra (Intel) <[email protected]> [mcgrof: add some tribal knowledge about why some folks prefer binary sempahores over mutexes] Reviewed-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Davidlohr Bueso <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2023-04-18veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features ↵Lorenzo Bianconi1-6/+11
flag For veth pairs, NETDEV_XDP_ACT_NDO_XMIT is supported by the current device if the peer one is running a XDP program or if it has GRO enabled. Fix the xdp_features flags reporting considering peer device and not current one for NETDEV_XDP_ACT_NDO_XMIT. Fixes: fccca038f300 ("veth: take into account device reconfiguration for xdp_features flag") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://lore.kernel.org/r/4f1ca6f6f6b42ae125bfdb5c7782217c83968b2e.1681767806.git.lorenzo@kernel.org Signed-off-by: Alexei Starovoitov <[email protected]>
2023-04-18wifi: iwlwifi: bump FW API to 78 for AX devicesGregory Greenman1-1/+1
Start supporting API version 78 for AX devices. Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.5a4dcbf5a2c1.I125808566fe892ee0865e392bf1b1872daafe8ad@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: check firmware response sizeJohannes Berg1-0/+10
Check the firmware response size for responses to the memory read/write command in debugfs before using it. Fixes: 2b55f43f8e47 ("iwlwifi: mvm: Add mem debugfs entry") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: add MLO support to SF - use sta pointerJohannes Berg1-21/+8
For MLO support, use the pointer to the peer MLD instead of the default link station id, since the default link is only used for non-MLO cases. Using the default link sta id is meaningless for MLO. Also remove the rcu protected section since we now avoid the lookup based on sta id. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.40cef48c0592.I8dd666d603d6e1854033e5369c70e78d9303d236@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: configure TLC on link activationJohannes Berg1-0/+24
If the AP station already exists on link activation (which means we're during link switch), configure the TLC in FW so we can immediately transmit once the link is activated. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.1a93de9b7c1f.I42022f24bbe3572f5a082da8c99794ae14281875@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: fix iwl_mvm_max_amsdu_size() for MLOJohannes Berg1-3/+34
For MLO, we cannot use vif->bss_conf.chandef.chan->band, since that will lead to a NULL-ptr dereference as bss_conf isn't used. However, in case of real MLO, we also need to take both LMACs into account if they exist, since the station might be active on both LMACs at the same time. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.3588afc85d79.I11592893bbc191b9548518b8bd782de568a9f848@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: remove RS rate init update argumentJohannes Berg5-26/+31
Track instead whether or not the station was authorized, that's clearer than trying to indicate in the code whether or not the full bandwidth should be used via an 'update' argument. While at it, give rs_fw_rate_init() the iwl_mvm_ prefix. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.92bd8d36e311.I1877a109104d5ffeaaad6a623e89f0c44decc38e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: initialize per-link STA ratescale dataJohannes Berg3-14/+28
When allocating a new link station, initialize the ratescaling data for it. To do that, refactor the initialization code out into a new iwl_mvm_rs_add_sta_link() function. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.441b6a8c60fd.I34f1b3555c25aaa22cc34d1112fc3b6393a20b7c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: rs-fw: properly access sband->iftype_dataJohannes Berg1-9/+12
We need to look up the correct version of this struct depending on the interface type, rather than just checking if the pointer is non-NULL. Fix that. Fixes: befebbb30af0 ("iwlwifi: rs: consider LDPC capability in case of HE") Fixes: b009cf71a982 ("iwlwifi: mvm: only enable HE DCM if we also support TX") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.1fd54368a02c.Ie4db5e8ae224d9a4a63b528da5d63e1b957b9cef@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: only clients can be 20MHz-onlyJohannes Berg4-12/+24
Since only clients to an AP can be 20MHz-only STAs, adjust the code to not make the use of EHT capabilities depend on only the bandwidth, but also the type of interface. Fixes: 701404f1091d ("wifi: iwlwifi: rs: add support for parsing max MCS per NSS/BW in 11be") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.a3a4c931e4a3.I693a07f4d88044c889eee04793883a83bc5ee362@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: fix iwl_mvm_sta_rc_update for MLOJohannes Berg1-7/+3
When this is called it might crash due to the use of deflink's phy context, update all links instead. It really shouldn't be called right now though, but it's better to have safer code until we update this to be with a link parameter. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.fd47d0de8319.I87c5e5bcb2fadd70acc32021eed394fc1eea12a4@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: remove per-STA MFP settingJohannes Berg1-1/+0
When we first add the STA before sending an authentication frame this is false. However, in some cases such as FT or certainly in MLO link switch scenarios, it will be true. If it happens to be true, it causes a firmware assert (in LMAC, 0x2528), because the same bit is used by the firmware for tracking this setting as well as for tracking if the management key has been installed, and then we get this assert from the firmware when installing the MFP key as it thinks it has already been installed. Remove the setting for now, until the firmware disentangles the two. We should be able to set it, in fact we should be setting it speculatively before authentication/association, to avoid processing management frames that should have been protected/encrypted before the key is set. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.adbeb0e0bfed.I400d0ee3721dc4f294313be992d277ba4d9c88d9@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENTJohannes Berg1-0/+2
We can allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT since we just use the elements from mac80211. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.88b1a70365fd.If5030437707ab67e2146291c1517a9b0e31d01ab@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: use BSSID when building probe requestsJohannes Berg1-1/+4
A long time, ago in commit 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID"), the stack started passing the BSSID that should be scanned for. Use it in iwlwifi for the intended optimisation, and to also allow the use of this for an implementation sending multi-link probe requests. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.0be90360cad7.If279c28079a1db34280a824cee7c3f6545fd8b9e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: update mac id managementGregory Greenman1-9/+13
The restriction where MAC ID 0 could be used only for the managed/IBSS vif is not required when using the new MLO FW API. Update the driver. Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.e4355615da92.Iba934ccf8589c3c27a25a390dc5e938312889b45@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18wifi: iwlwifi: mvm: adopt the latest firmware APIEmmanuel Grumbach2-17/+0
The firmware no longer wants the beacon template inside the MAC command. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230417113648.92aed4180a06.I277efa343c88081cb3fc890dcbeae3161cdffe16@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-04-18mlxfw: fix null-ptr-deref in mlxfw_mfa2_tlv_next()Nikita Zhandarovich1-0/+2
Function mlxfw_mfa2_tlv_multi_get() returns NULL if 'tlv' in question does not pass checks in mlxfw_mfa2_tlv_payload_get(). This behaviour may lead to NULL pointer dereference in 'multi->total_len'. Fix this issue by testing mlxfw_mfa2_tlv_multi_get()'s return value against NULL. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Co-developed-by: Natalia Petrova <[email protected]> Signed-off-by: Nikita Zhandarovich <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18net: stmmac: dwmac-starfive: Add phy interface settingsSamin Guo1-0/+48
dwmac supports multiple modess. When working under rmii and rgmii, you need to set different phy interfaces. According to the dwmac document, when working in rmii, it needs to be set to 0x4, and rgmii needs to be set to 0x1. The phy interface needs to be set in syscon, the format is as follows: starfive,syscon: <&syscon, offset, shift> Tested-by: Tommaso Merciai <[email protected]> Signed-off-by: Samin Guo <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18net: stmmac: Add glue layer for StarFive JH7110 SoCSamin Guo3-0/+136
This adds StarFive dwmac driver support on the StarFive JH7110 SoC. Tested-by: Tommaso Merciai <[email protected]> Co-developed-by: Emil Renner Berthing <[email protected]> Signed-off-by: Emil Renner Berthing <[email protected]> Signed-off-by: Samin Guo <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18net: stmmac: platform: Add snps,dwmac-5.20 IP compatible stringEmil Renner Berthing1-1/+2
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid to define some platform data in the glue layer. Tested-by: Tommaso Merciai <[email protected]> Signed-off-by: Emil Renner Berthing <[email protected]> Signed-off-by: Samin Guo <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18r8169: use new macro netif_subqueue_completed_wake in the tx cleanup pathHeiner Kallweit1-12/+4
Use new net core macro netif_subqueue_completed_wake to simplify the code of the tx cleanup path. Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18r8169: use new macro netif_subqueue_maybe_stop in rtl8169_start_xmitHeiner Kallweit1-28/+11
Use new net core macro netif_subqueue_maybe_stop in the start_xmit path to simplify the code. Whilst at it, set the tx queue start threshold to twice the stop threshold. Before values were the same, resulting in stopping/starting the queue more often than needed. Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18bnxt_en: Fix a possible NULL pointer dereference in unload pathKalesh AP1-9/+10
In the driver unload path, the driver currently checks the valid BNXT_FLAG_ROCE_CAP flag in bnxt_rdma_aux_device_uninit() before proceeding. This is flawed because the flag may not be set initially during driver load. It may be set later after the NVRAM setting is changed followed by a firmware reset. Relying on the BNXT_FLAG_ROCE_CAP flag may crash in bnxt_rdma_aux_device_uninit() if the aux device was never initialized: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 8ae6aa067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 39 PID: 42558 Comm: rmmod Kdump: loaded Tainted: G OE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R750/0WT8Y6, BIOS 1.5.4 12/17/2021 RIP: 0010:device_del+0x1b/0x410 Code: 89 a5 50 03 00 00 4c 89 a5 58 03 00 00 eb 89 0f 1f 44 00 00 41 56 41 55 41 54 4c 8d a7 80 00 00 00 55 53 48 89 fb 48 83 ec 18 <48> 8b 2f 4c 89 e7 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 RSP: 0018:ff7f82bf469a7dc8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000000 RBP: ff31b7cd114b0ac0 R08: 0000000000000000 R09: ffffffff935c3400 R10: ff31b7cd45bc3440 R11: 0000000000000001 R12: 0000000000000080 R13: ffffffffc1069f40 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fc9903ce740(0000) GS:ff31b7d4ffac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000992fee004 CR4: 0000000000773ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: bnxt_rdma_aux_device_uninit+0x1f/0x30 [bnxt_en] bnxt_remove_one+0x2f/0x1f0 [bnxt_en] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x103/0x1f0 driver_detach+0x54/0x88 bus_remove_driver+0x77/0xc9 pci_unregister_driver+0x2d/0xb0 bnxt_exit+0x16/0x2c [bnxt_en] __x64_sys_delete_module+0x139/0x280 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7fc98f3af71b Fix this by modifying the check inside bnxt_rdma_aux_device_uninit() to check for bp->aux_priv instead. We also need to make some changes in bnxt_rdma_aux_device_init() to make sure that bp->aux_priv is set only when the aux device is fully initialized. Fixes: d80d88b0dfff ("bnxt_en: Add auxiliary driver support") Reviewed-by: Ajit Khaparde <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18bnxt_en: Do not initialize PTP on older P3/P4 chipsMichael Chan1-1/+1
The driver does not support PTP on these older chips and it is assuming that firmware on these older chips will not return the PORT_MAC_PTP_QCFG_RESP_FLAGS_HWRM_ACCESS flag in __bnxt_hwrm_ptp_qcfg(), causing the function to abort quietly. But newer firmware now sets this flag and so __bnxt_hwrm_ptp_qcfg() will proceed further. Eventually it will fail in bnxt_ptp_init() -> bnxt_map_ptp_regs() because there is no code to support the older chips. The driver will then complain: "PTP initialization failed.\n" Fix it so that we abort quietly earlier without going through the unnecessary steps and alarming the user with the warning log. Fixes: ae5c42f0b92c ("bnxt_en: Get PTP hardware capability from firmware") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-04-18cxgb4: fix use after free bugs caused by circular dependency problemDuoming Zhou1-1/+1
The flower_stats_timer can schedule flower_stats_work and flower_stats_work can also arm the flower_stats_timer. The process is shown below: ----------- timer schedules work ------------ ch_flower_stats_cb() //timer handler schedule_work(&adap->flower_stats_work); ----------- work arms timer ------------ ch_flower_stats_handler() //workqueue callback function mod_timer(&adap->flower_stats_timer, ...); When the cxgb4 device is detaching, the timer and workqueue could still be rearmed. The process is shown below: (cleanup routine) | (timer and workqueue routine) remove_one() | free_some_resources() | ch_flower_stats_cb() //timer cxgb4_cleanup_tc_flower() | schedule_work() del_timer_sync() | | ch_flower_stats_handler() //workqueue | mod_timer() cancel_work_sync() | kfree(adapter) //FREE | ch_flower_stats_cb() //timer | adap->flower_stats_work //USE This patch changes del_timer_sync() to timer_shutdown_sync(), which could prevent rearming of the timer from the workqueue. Fixes: e0f911c81e93 ("cxgb4: fetch stats for offloaded tc flower flows") Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-04-17net: mscc: ocelot: add support for preemptible traffic classesVladimir Oltean4-3/+71
In order to not transmit (preemptible) frames which will be received by the link partner as corrupted (because it doesn't support FP), the hardware requires the driver to program the QSYS_PREEMPTION_CFG_P_QUEUES register only after the MAC Merge layer becomes active (verification succeeds, or was disabled). There are some cases when FP is known (through experimentation) to be broken. Give priority to FP over cut-through switching, and disable FP for known broken link modes. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: dsa: felix: act upon the mqprio qopt in taprio offloadVladimir Oltean1-5/+17
The mqprio queue configuration can appear either through TC_SETUP_QDISC_MQPRIO or through TC_SETUP_QDISC_TAPRIO. Make sure both are treated in the same way. Code does nothing new for now (except for rejecting multiple TXQs per TC, which is a useless concept with DSA switches). Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ferenc Fejes <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: mscc: ocelot: add support for mqprio offloadVladimir Oltean2-0/+59
This doesn't apply anything to hardware and in general doesn't do anything that the software variant doesn't do, except for checking that there isn't more than 1 TXQ per TC (TXQs for a DSA switch are a dubious concept anyway). The reason we add this is to be able to parse one more field added to struct tc_mqprio_qopt_offload, namely preemptible_tcs. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ferenc Fejes <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: mscc: ocelot: don't rely on cached verify_status in ocelot_port_get_mm()Vladimir Oltean1-0/+1
ocelot_mm_update_port_status() updates mm->verify_status, but when the verification state of a port changes, an IRQ isn't emitted, but rather, only when the verification state reaches one of the final states (like DISABLED, FAILED, SUCCEEDED) - things that would affect mm->tx_active, which is what the IRQ *is* actually emitted for. That is to say, user space may miss reports of an intermediary MAC Merge verification state (like from INITIAL to VERIFYING), unless there was an IRQ notifying the driver of the change in mm->tx_active as well. This is not a huge deal, but for reliable reporting to user space, let's call ocelot_mm_update_port_status() synchronously from ocelot_port_get_mm(), which makes user space see the current MM status. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: mscc: ocelot: optimize ocelot_mm_irq()Vladimir Oltean1-2/+28
The MAC Merge IRQ of all ports is shared with the PTP TX timestamp IRQ of all ports, which means that currently, when a PTP TX timestamp is generated, felix_irq_handler() also polls for the MAC Merge layer status of all ports, looking for changes. This makes the kernel do more work, and under certain circumstances may make ptp4l require a tx_timestamp_timeout argument higher than before. Changes to the MAC Merge layer status are only to be expected under certain conditions - its TX direction needs to be enabled - so we can check early if that is the case, and omit register access otherwise. Make ocelot_mm_update_port_status() skip register access if mm->tx_enabled is unset, and also call it once more, outside IRQ context, from ocelot_port_set_mm(), when mm->tx_enabled transitions from true to false, because an IRQ is also expected in that case. Also, a port may have its MAC Merge layer enabled but it may not have generated the interrupt. In that case, there's no point in writing to DEV_MM_STATUS to acknowledge that IRQ. We can reduce the number of register writes per port with MM enabled by keeping an "ack" variable which writes the "write-one-to-clear" bits. Those are 3 in number: PRMPT_ACTIVE_STICKY, UNEXP_RX_PFRM_STICKY and UNEXP_TX_PFRM_STICKY. The other fields in DEV_MM_STATUS are read-only and it doesn't matter what is written to them, so writing zero is just fine. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: mscc: ocelot: remove struct ocelot_mm_state :: lockVladimir Oltean1-12/+8
Unfortunately, the workarounds for the hardware bugs make it pointless to keep fine-grained locking for the MAC Merge state of each port. Our vsc9959_cut_through_fwd() implementation requires ocelot->fwd_domain_lock to be held, in order to serialize with changes to the bridging domains and to port speed changes (which affect which ports can be cut-through). Simultaneously, the traffic classes which can be cut-through cannot be preemptible at the same time, and this will depend on the MAC Merge layer state (which changes from threaded interrupt context). Since vsc9959_cut_through_fwd() would have to hold the mm->lock of all ports for a correct and race-free implementation with respect to ocelot_mm_irq(), in practice it means that any time a port's mm->lock is held, it would potentially block holders of ocelot->fwd_domain_lock. In the interest of simple locking rules, make all MAC Merge layer state changes (and preemptible traffic class changes) be serialized by the ocelot->fwd_domain_lock. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: mscc: ocelot: export a single ocelot_mm_irq()Vladimir Oltean2-6/+11
When the switch emits an IRQ, we don't know what caused it, and we iterate through all ports to check the MAC Merge status. Move that iteration inside the ocelot lib; we will change the locking in a future change and it would be good to encapsulate that lock completely within the ocelot lib. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: stmmac: add Rx HWTS metadata to XDP ZC receive pktSong Yoong Siang1-0/+22
Add receive hardware timestamp metadata support via kfunc to XDP Zero Copy receive packets. Signed-off-by: Song Yoong Siang <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: stmmac: add Rx HWTS metadata to XDP receive pktSong Yoong Siang2-1/+42
Add receive hardware timestamp metadata support via kfunc to XDP receive packets. Suggested-by: Stanislav Fomichev <[email protected]> Signed-off-by: Song Yoong Siang <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net: stmmac: introduce wrapper for struct xdp_buffSong Yoong Siang2-9/+13
Introduce struct stmmac_xdp_buff as a preparation to support XDP Rx metadata via kfuncs. Signed-off-by: Song Yoong Siang <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net/mlx5e: Accept tunnel mode for IPsec packet offloadLeon Romanovsky1-7/+8
Open mlx5 driver to accept IPsec tunnel mode. Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net/mlx5e: Create IPsec table with tunnel support only when encap is disabledLeon Romanovsky3-3/+39
Current hardware doesn't support double encapsulation which is happening when IPsec packet offload tunnel mode is configured together with eswitch encap option. Any user attempt to add new SA/policy after he/she sets encap mode, will generate the following FW syndrome: mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 1904): CREATE_FLOW_TABLE(0x930) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xa43321), err(-22) Make sure that we block encap changes before creating flow steering tables. This is applicable only for packet offload in tunnel mode, while packet offload in transport mode and crypto offload, don't have such limitation as they don't perform encapsulation. Reviewed-by: Raed Salem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net/mlx5: Allow blocking encap changes in eswitchLeon Romanovsky2-0/+62
Existing eswitch encap option enables header encapsulation. Unfortunately currently available hardware isn't able to perform double encapsulation, which can happen once IPsec packet offload tunnel mode is used together with encap mode set to BASIC. So as a solution for misconfiguration, provide an option to block encap changes, which will be used for IPsec packet offload. Reviewed-by: Emeel Hakim <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-04-17net/mlx5e: Listen to ARP events to update IPsec L2 headers in tunnel modeLeon Romanovsky2-7/+130
In IPsec packet offload mode all header manipulations are performed by hardware, which is responsible to add/remove L2 header with source and destinations MACs. CX-7 devices don't support offload of in-kernel routing functionality, as such HW needs external help to fill other side MAC as it isn't available for HW. As a solution, let's listen to neigh ARP updates and reconfigure IPsec rules on the fly once new MAC data information arrives. Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.