summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-16ice: Fix stats after PF resetAhmed Zaki1-0/+5
After a core PF reset, the VFs were showing wrong Rx/Tx stats. This is a regression in commit 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") caused by missing to set "stat_offsets_loaded = false" in the ice_vsi_rebuild() path. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-05-16net: bcmgenet: Restore phy_stop() depending upon suspend/closeFlorian Fainelli1-3/+5
Removing the phy_stop() from bcmgenet_netif_stop() ended up causing warnings from the PHY library that phy_start() is called from the RUNNING state since we are no longer stopping the PHY state machine during bcmgenet_suspend(). Restore the call to phy_stop() but make it conditional on being called from the close or suspend path. Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine") Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230515025608.2587012-1-f.fainelli@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-05-15Merge patch series "can: bxcan: add support for single peripheral configuration"Marc Kleine-Budde5-15/+168
Dario Binacchi <dario.binacchi@amarulasolutions.com> says: The series adds support for managing bxCAN controllers in single peripheral configuration. Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. The driver has been tested on the stm32f769i-discovery board with a kernel version 5.19.0-rc2 in loopback + silent mode: | ip link set can[0-2] type can bitrate 125000 loopback on listen-only on | ip link set up can[0-2] | candump can[0-2] -L & | cansend can[0-2] 300#AC.AB.AD.AE.75.49.AD.D1 Changes in v2: - s/fiter/filter/ in the commit message - Replace struct bxcan_mb::primary with struct bxcan_mb::cfg. - Move after the patch "can: bxcan: add support for single peripheral configuration". - Add node gcan3. - Rename gcan as gcan1. - Add property "st,can-secondary" to can2 node. - Drop patch "dt-bindings: mfd: stm32f7: add binding definition for CAN3" because it has been accepted. - Add patch "ARM: dts: stm32f429: put can2 in secondary mode". - Add patch "dt-bindings: net: can: add "st,can-secondary" property". v1: https://lore.kernel.org/all/20230423172528.1398158-1-dario.binacchi@amarulasolutions.com Link: https://lore.kernel.org/all/20230427204540.3126234-1-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15ARM: dts: stm32: add CAN support on stm32f746Dario Binacchi1-0/+47
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. ------------------------------------------------------------------------- | features | CAN1 | CAN2 | CAN 3 | ------------------------------------------------------------------------- | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | ------------------------------------------------------------------------- | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | ------------------------------------------------------------------------- Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-6-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: bxcan: add support for single peripheral configurationDario Binacchi1-11/+23
Add support for bxCAN controller in single peripheral configuration: - primary bxCAN - dedicated Memory Access Controller unit - 512-byte SRAM memory - 14 filter banks Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-5-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15ARM: dts: stm32: add pin map for CAN controller on stm32f7Dario Binacchi1-0/+82
Add pin configurations for using CAN controller on stm32f7. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-4-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15ARM: dts: stm32f429: put can2 in secondary modeDario Binacchi1-0/+1
This is a preparation patch for the upcoming support to manage CAN peripherals in single configuration. The addition ensures backwards compatibility. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-3-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15dt-bindings: net: can: add "st,can-secondary" propertyDario Binacchi1-4/+15
On the stm32f7 Socs the can peripheral can be in single or dual configuration. In the dual configuration, in turn, it can be in primary or secondary mode. The addition of the 'st,can-secondary' property allows you to specify this mode in the dual configuration. CAN peripheral nodes in single configuration contain neither "st,can-primary" nor "st,can-secondary". Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230427204540.3126234-2-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: CAN_BXCAN should depend on ARCH_STM32Geert Uytterhoeven1-1/+1
The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is only present on STM32 SoCs. Hence drop the "|| OF" part from its dependency rule, to prevent asking the user about this driver when configuring a kernel without STM32 SoC support. Fixes: f00647d8127be4d3 ("can: bxcan: add support for ST bxCAN controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: dev: fix missing CAN XL support in can_put_echo_skb()Oliver Hartkopp1-1/+2
can_put_echo_skb() checks for the enabled IFF_ECHO flag and the correct ETH_P type of the given skbuff. When implementing the CAN XL support the new check for ETH_P_CANXL has been forgotten. Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230506184515.39241-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flagOliver Hartkopp1-1/+1
The control message provided by J1939 support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <o.rempel@pengutronix.de> Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/20230505110308.81087-3-mkl@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flagOliver Hartkopp1-1/+1
The control message provided by isotp support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <o.rempel@pengutronix.de> Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Fixes: 42bf50a1795a ("can: isotp: support MSG_TRUNC flag when reading from socket") Link: https://lore.kernel.org/20230505110308.81087-2-mkl@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR valueYun Lu2-1/+4
When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a probability of failure, which shows "authentication with ... timed out". Through debugging, it was found that the RCR register has been inexplicably modified to an incorrect value, resulting in the nic not being able to receive authenticated frames. To fix this problem, add regrcr in rtl8xxxu_priv struct, and store the RCR value every time the register is written, and use it the next time the register need to be modified. Signed-off-by: Yun Lu <luyun@kylinos.cn> Link: https://lore.kernel.org/all/20230427020512.1221062-1-luyun_611@163.com Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230512012055.2990472-1-luyun_611@163.com
2023-05-15wifi: brcmfmac: Check for probe() id argument being NULLHans de Goede3-0/+27
The probe() id argument may be NULL in 2 scenarios: 1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe the device. 2. If a user tries to manually bind the driver from sysfs then the sdio / pcie / usb probe() function gets called with NULL as id argument. 1. Is being hit by users causing the following oops on resume and causing wifi to stop working: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020 Workgueue: events_unbound async_run_entry_fn RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac] <snip> Call Trace: <TASK> brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887] ? pci_pm_resume+0x5b/0xf0 ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x47/0x150 device_resume+0xa2/0x1f0 async_resume+0x1d/0x30 <snip> Fix this by checking for id being NULL. In the PCI and USB cases try a manual lookup of the id so that manually binding the driver through sysfs and more importantly brcmf_pcie_probe() on resume will work. For the SDIO case there is no helper to do a manual sdio_device_id lookup, so just directly error out on a NULL id there. Fixes: da6d9c8ecd00 ("wifi: brcmfmac: add firmware vendor info in driver info") Reported-by: Felix <nimrod4garoa@gmail.com> Link: https://lore.kernel.org/regressions/4ef3f252ff530cbfa336f5a0d80710020fc5cb1e.camel@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230510141856.46532-1-hdegoede@redhat.com
2023-05-15wifi: rtw88: correct qsel_to_ep[] type as intPing-Ke Shih1-1/+1
qsel_to_ep[] can be assigned negative value, so change type from 'u8' to 'int'. Otherwise, Smatch static checker warns: drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn: assigning (-22) to unsigned variable 'rtwusb->qsel_to_ep[8]' Cc: stable@vger.kernel.org Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/linux-wireless/c3f70197-829d-48ed-ae15-66a9de80fa90@kili.mountain/ Cc: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230508085539.46795-1-pkshih@realtek.com
2023-05-15net: phylink: fix ksettings_set() ethtool callRussell King (Oracle)1-4/+4
While testing a Fiberstore SFP-10G-T module (which uses 10GBASE-R with rate adaption) in a Clearfog platform (which can't do that) it was found that the PHYs advertisement was not limited according to the hosts capabilities when using ethtool to change it. Fix this by ensuring that we mask the advertisement with the computed support mask as the very first thing we do. Fixes: cbc1bb1e4689 ("net: phylink: simplify phy case for ksettings_set method") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15Merge branch 'tipc-fixes'David S. Miller4-7/+27
Xin Long says: ==================== tipc: fix the mtu update in link mtu negotiation This patchset fixes a crash caused by a too small MTU carried in the activate msg. Note that as such malicious packet does not exist in the normal env, the fix won't break any application The 1st patch introduces a function to calculate the minimum MTU for the bearer, and the 2nd patch fixes the crash with this helper. While at it, the 3rd patch fixes the udp bearer mtu update by netlink with this helper. ==================== Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15tipc: check the bearer min mtu properly when setting it by netlinkXin Long1-2/+2
Checking the bearer min mtu with tipc_udp_mtu_bad() only works for IPv4 UDP bearer, and IPv6 UDP bearer has a different value for the min mtu. This patch checks with encap_hlen + TIPC_MIN_BEARER_MTU for min mtu, which works for both IPv4 and IPv6 UDP bearer. Note that tipc_udp_mtu_bad() is still used to check media min mtu in __tipc_nl_media_set(), as m->mtu currently is only used by the IPv4 UDP bearer as its default mtu value. Fixes: 682cd3cf946b ("tipc: confgiure and apply UDP bearer MTU on running links") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15tipc: do not update mtu if msg_max is too small in mtu negotiationXin Long1-3/+6
When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4! And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small. Fixes: ed193ece2649 ("tipc: simplify link mtu negotiation") Reported-by: Shuang Li <shuali@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15tipc: add tipc_bearer_min_mtu to calculate min mtuXin Long3-2/+19
As different media may requires different min mtu, and even the same media with different net family requires different min mtu, add tipc_bearer_min_mtu() to calculate min mtu accordingly. This API will be used to check the new mtu when doing the link mtu negotiation in the next patch. Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15net: mdio: i2c: fix rollball accessorsRussell King (Oracle)1-7/+8
Commit 87e3bee0f247 ("net: mdio: i2c: Separate C22 and C45 transactions") separated the non-rollball bus accessors, but left the rollball accessors as is. As rollball accessors are clause 45, this results in the rollball protocol being completely non-functional. Fix this. Fixes: 87e3bee0f247 ("net: mdio: i2c: Separate C22 and C45 transactions") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15virtio_net: Fix error unwinding of XDP initializationFeng Liu1-17/+44
When initializing XDP in virtnet_open(), some rq xdp initialization may hit an error causing net device open failed. However, previous rqs have already initialized XDP and enabled NAPI, which is not the expected behavior. Need to roll back the previous rq initialization to avoid leaks in error unwinding of init code. Also extract helper functions of disable and enable queue pairs. Use newly introduced disable helper function in error unwinding and virtnet_close. Use enable helper function in virtnet_open. Fixes: 754b8a21a96d ("virtio_net: setup xdp_rxq_info") Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: William Tu <witu@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15net: fec: remove the xdp_return_frame when lack of tx BDsShenwei Wang1-1/+0
In the implementation, the sent_frame count does not increment when transmit errors occur. Therefore, bq_xmit_all() will take care of returning the XDP frames. Fixes: 26312c685ae0 ("net: fec: correct the counting of XDP sent frames") Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-15net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()Dong Chenchen1-5/+3
As the call trace shows, skb_panic was caused by wrong skb->mac_header in nsh_gso_segment(): invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1 RIP: 0010:skb_panic+0xda/0xe0 call Trace: skb_push+0x91/0xa0 nsh_gso_segment+0x4f3/0x570 skb_mac_gso_segment+0x19e/0x270 __skb_gso_segment+0x1e8/0x3c0 validate_xmit_skb+0x452/0x890 validate_xmit_skb_list+0x99/0xd0 sch_direct_xmit+0x294/0x7c0 __dev_queue_xmit+0x16f0/0x1d70 packet_xmit+0x185/0x210 packet_snd+0xc15/0x1170 packet_sendmsg+0x7b/0xa0 sock_sendmsg+0x14f/0x160 The root cause is: nsh_gso_segment() use skb->network_header - nhoff to reset mac_header in skb_gso_error_unwind() if inner-layer protocol gso fails. However, skb->network_header may be reset by inner-layer protocol gso function e.g. mpls_gso_segment. skb->mac_header reset by the inaccurate network_header will be larger than skb headroom. nsh_gso_segment nhoff = skb->network_header - skb->mac_header; __skb_pull(skb,nsh_len) skb_mac_gso_segment mpls_gso_segment skb_reset_network_header(skb);//skb->network_header+=nsh_len return -EINVAL; skb_gso_error_unwind skb_push(skb, nsh_len); skb->mac_header = skb->network_header - nhoff; // skb->mac_header > skb->headroom, cause skb_push panic Use correct mac_offset to restore mac_header and get rid of nhoff. Fixes: c411ed854584 ("nsh: add GSO support") Reported-by: syzbot+632b5d9964208bfef8c0@syzkaller.appspotmail.com Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13Merge branch 'hns3-fixes'David S. Miller8-15/+50
Hao Lan says: ==================== net: hns3: fix some bug for hns3 There are some bugfixes for the HNS3 ethernet driver. patch#1 fix miss checking for rx packet. patch#2 fixes VF promisc mode not update when mac table full bug, and patch#3 fixes a nterrupts not initialization in VF FLR bug. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: hns3: fix reset timeout when enable full VFJijie Shao2-5/+28
The timeout of the cmdq reset command has been increased to resolve the reset timeout issue in the full VF scenario. The timeout of other cmdq commands remains unchanged. Fixes: 8d307f8e8cf1 ("net: hns3: create new set of unified hclge_comm_cmd_send APIs") Signed-off-by: Jijie Shao <shaojijie@huawei.com> Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: hns3: fix reset delay time to avoid configuration timeoutJie Wang1-1/+4
Currently the hns3 vf function reset delays 5000ms before vf rebuild process. In product applications, this delay is too long for application configurations and causes configuration timeout. According to the tests, 500ms delay is enough for reset process except PF FLR. So this patch modifies delay to 500ms in these scenarios. Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: hns3: fix sending pfc frames after reset issueJijie Shao3-8/+16
To prevent the system from abnormally sending PFC frames after an abnormal reset. The hns3 driver notifies the firmware to disable pfc before reset. Fixes: 35d93a30040c ("net: hns3: adjust the process of PF reset") Signed-off-by: Jijie Shao <shaojijie@huawei.com> Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: hns3: fix output information incomplete for dumping tx queue info with ↵Jie Wang2-1/+2
debugfs In function hns3_dump_tx_queue_info, The print buffer is not enough when the tx BD number is configured to 32760. As a result several BD information wouldn't be displayed. So fix it by increasing the tx queue print buffer length. Fixes: 630a6738da82 ("net: hns3: adjust string spaces of some parameters of tx bd info in debugfs") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13Merge branch 'dsa-rzn1-a5psw-stp'David S. Miller2-19/+67
Alexis Lothoré says: ==================== net: dsa: rzn1-a5psw: fix STP states handling This small series fixes STP support and while adding a new function to enable/disable learning, use that to disable learning on standalone ports at switch setup as reported by Vladimir Oltean. This series was initially submitted on net-next by Clement Leger, but some career evolutions has made him hand me over those topics. Also, this new revision is submitted on net instead of net-next for V1 based on Vladimir Oltean's suggestion Changes since v2: - fix commit split by moving A5PSW_MGMT_CFG_ENABLE in relevant commit - fix reverse christmas tree ordering in a5psw_port_stp_state_set Changes since v1: - fix typos in commit messages and doc - re-split STP states handling commit - add Fixes: tag and new Signed-off-by - submit series as fix on net instead of net-next - split learning and blocking setting functions - remove unused define A5PSW_PORT_ENA_TX_SHIFT - add boolean for tx/rx enabled for clarity ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: dsa: rzn1-a5psw: disable learning for standalone portsClément Léger1-8/+16
When ports are in standalone mode, they should have learning disabled to avoid adding new entries in the MAC lookup table which might be used by other bridge ports to forward packets. While adding that, also make sure learning is enabled for CPU port. Fixes: 888cdb892b61 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by: Clément Léger <clement.leger@bootlin.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: dsa: rzn1-a5psw: fix STP states handlingAlexis Lothoré2-9/+49
stp_set_state() should actually allow receiving BPDU while in LEARNING mode which is not the case. Additionally, the BLOCKEN bit does not actually forbid sending forwarded frames from that port. To fix this, add a5psw_port_tx_enable() function which allows to disable TX. However, while its name suggest that TX is totally disabled, it is not and can still allow to send BPDUs even if disabled. This can be done by using forced forwarding with the switch tagging mechanism but keeping "filtering" disabled (which is already the case in the rzn1-a5sw tag driver). With these fixes, STP support is now functional. Fixes: 888cdb892b61 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by: Clément Léger <clement.leger@bootlin.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13net: dsa: rzn1-a5psw: enable management frames for CPU portClément Léger2-2/+2
Currently, management frame were discarded before reaching the CPU port due to a misconfiguration of the MGMT_CONFIG register. Enable them by setting the correct value in this register in order to correctly receive management frame and handle STP. Fixes: 888cdb892b61 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by: Clément Léger <clement.leger@bootlin.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-13erspan: get the proto with the md version for collect_mdXin Long1-5/+8
In commit 20704bd1633d ("erspan: build the header with the right proto according to erspan_ver"), it gets the proto with t->parms.erspan_ver, but t->parms.erspan_ver is not used by collect_md branch, and instead it should get the proto with md->version for collect_md. Thanks to Kevin for pointing this out. Fixes: 20704bd1633d ("erspan: build the header with the right proto according to erspan_ver") Fixes: 94d7d8f29287 ("ip6_gre: add erspan v2 support") Reported-by: Kevin Traynor <ktraynor@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12tcp: fix possible sk_priority leak in tcp_v4_send_reset()Eric Dumazet1-2/+3
When tcp_v4_send_reset() is called with @sk == NULL, we do not change ctl_sk->sk_priority, which could have been set from a prior invocation. Change tcp_v4_send_reset() to set sk_priority and sk_mark fields before calling ip_send_unicast_reply(). This means tcp_v4_send_reset() and tcp_v4_send_ack() no longer have to clear ctl_sk->sk_mark after their call to ip_send_unicast_reply(). Fixes: f6c0f5d209fa ("tcp: honor SO_PRIORITY in TIME_WAIT state") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12vsock: avoid to close connected socket after the timeoutZhuang Shengen1-1/+1
When client and server establish a connection through vsock, the client send a request to the server to initiate the connection, then start a timer to wait for the server's response. When the server's RESPONSE message arrives, the timer also times out and exits. The server's RESPONSE message is processed first, and the connection is established. However, the client's timer also times out, the original processing logic of the client is to directly set the state of this vsock to CLOSE and return ETIMEDOUT. It will not notify the server when the port is released, causing the server port remain. when client's vsock_connect timeout，it should check sk state is ESTABLISHED or not. if sk state is ESTABLISHED, it means the connection is established, the client should not set the sk state to CLOSE Note: I encountered this issue on kernel-4.18, which can be fixed by this patch. Then I checked the latest code in the community and found similar issue. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Zhuang Shengen <zhuangshengen@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12sfc: disable RXFCS and RXALL features by defaultPieter Jansen van Vuuren1-1/+3
By default we would not want RXFCS and RXALL features enabled as they are mainly intended for debugging purposes. This does not stop users from enabling them later on as needed. Fixes: 8e57daf70671 ("sfc_ef100: RX path for EF100") Signed-off-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Co-developed-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12ice: Fix undersized tx_flags variableJan Sokolowski3-14/+8
As not all ICE_TX_FLAGS_* fit in current 16-bit limited tx_flags field that was introduced in the Fixes commit, VLAN-related information would be discarded completely. As such, creating a vlan and trying to run ping through would result in no traffic passing. Fix that by refactoring tx_flags variable into flags only and a separate variable that holds VLAN ID. As there is some space left, type variable can fit between those two. Pahole reports no size change to ice_tx_buf struct. Fixes: aa1d3faf71a6 ("ice: Robustify cleaning/completing XDP Tx buffers") Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12wifi: rtw88: use work to update rate to avoid RCU warningPing-Ke Shih3-1/+19
The ieee80211_ops::sta_rc_update must be atomic, because ieee80211_chan_bw_change() holds rcu_read lock while calling drv_sta_rc_update(), so create a work to do original things. Voluntary context switch within RCU read-side critical section! WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x571/0x5d0 CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G W OE Workqueue: phy3 ieee80211_chswitch_work [mac80211] RIP: 0010:rcu_note_context_switch+0x571/0x5d0 Call Trace: <TASK> __schedule+0xb0/0x1460 ? __mod_timer+0x116/0x360 schedule+0x5a/0xc0 schedule_timeout+0x87/0x150 ? trace_raw_output_tick_stop+0x60/0x60 wait_for_completion_timeout+0x7b/0x140 usb_start_wait_urb+0x82/0x160 [usbcore usb_control_msg+0xe3/0x140 [usbcore rtw_usb_read+0x88/0xe0 [rtw_usb rtw_usb_read8+0xf/0x10 [rtw_usb rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core drv_sta_rc_update+0x7c/0x160 [mac80211 ieee80211_chan_bw_change+0xfb/0x110 [mac80211 ieee80211_change_chanctx+0x38/0x130 [mac80211 ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211 ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211 ieee80211_chswitch_work+0x95/0x170 [mac80211 process_one_work+0x201/0x410 worker_thread+0x4a/0x3b0 ? process_one_work+0x410/0x410 kthread+0xe1/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Cc: stable@vger.kernel.org Fixes: c1edc86472fc ("rtw88: add ieee80211:sta_rc_update ops") Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/linux-wireless/f1e31e8e-f84e-3791-50fb-663a83c5c6e9@lwfinger.net/T/#t Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230508085429.46653-1-pkshih@realtek.com
2023-05-12wifi: rtw89: 8852b: adjust quota to avoid SER L1 caused by access null pagePing-Ke Shih3-14/+20
Though SER can recover this case, traffic can get stuck for a while. Fix it by adjusting page quota to avoid hardware access null page of CMAC/DMAC. Fixes: a1cb097168fa ("wifi: rtw89: 8852b: configure DLE mem") Fixes: 3e870b481733 ("wifi: rtw89: 8852b: add HFC quota arrays") Cc: stable@vger.kernel.org Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Link: https://github.com/lwfinger/rtw89/issues/226#issuecomment-1520776761 Link: https://github.com/lwfinger/rtw89/issues/240 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230426034737.24870-1-pkshih@realtek.com
2023-05-12wifi: mt76: connac: fix stats->tx_bytes calculationRyder Lee2-2/+3
The stats->tx_bytes shall subtract retry byte from tx byte. Fixes: 43eaa3689507 ("wifi: mt76: add PPDU based TxS support for WED device") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b3cd45596943cf5a06b2e08e2fe732ab0b51311b.1682285873.git.ryder.lee@mediatek.com
2023-05-12wifi: mt76: mt7996: fix endianness of MT_TXD6_TX_RATERyder Lee1-1/+1
To avoid sparse warning: sparse: warning: invalid assignment: |= sparse: left side has type restricted __le32 sparse: right side has type unsigned lon Fixes: 15ee62e73705 ("wifi: mt76: mt7996: enable BSS_CHANGED_BASIC_RATES support") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/16fa938373e3b145cb07a2c98d2428fea2abadba.1682285873.git.ryder.lee@mediatek.com
2023-05-12MAINTAINERS: exclude wireless drivers from netdevJakub Kicinski1-0/+1
It seems that we mostly get netdev CCed on wireless patches which are written by people who don't know any better and CC everything that get_maintainers spits out. Rather than patches which indeed could benefit from general networking review. Marking them down in patchwork as Awaiting Upstream is a bit tedious. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12nfp: fix NFP_NET_MAX_DSCP definition errorHuayu Chen1-1/+1
The patch corrects the NFP_NET_MAX_DSCP definition in the main.h file. The incorrect definition result DSCP bits not being mapped properly when DCB is set. When NFP_NET_MAX_DSCP was defined as 4, the next 60 DSCP bits failed to be set. Fixes: 9b7fe8046d74 ("nfp: add DCB IEEE support") Cc: stable@vger.kernel.org Signed-off-by: Huayu Chen <huayu.chen@corigine.com> Acked-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12MAINTAINERS: don't CC docs@ for netlink spec changesJakub Kicinski1-0/+2
Documentation/netlink/ contains machine-readable protocol specs in YAML. Those are much like device tree bindings, no point CCing docs@ for the changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com>
2023-05-12MAINTAINERS: sctp: move Neil to CREDITSMarcelo Ricardo Leitner2-2/+5
Neil moved away from SCTP related duties. Move him to CREDITS then and while at it, update SCTP project website. Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12net: phy: dp83867: add w/a for packet errors seen with short cablesGrygorii Strashko1-1/+21
Introduce the W/A for packet errors seen with short cables (<1m) between two DP83867 PHYs. The W/A recommended by DM requires FFE Equalizer Configuration tuning by writing value 0x0E81 to DSP_FFE_CFG register (0x012C), surrounded by hard and soft resets as follows: write_reg(0x001F, 0x8000); //hard reset write_reg(DSP_FFE_CFG, 0x0E81); write_reg(0x001F, 0x4000); //soft reset Since DP83867 PHY DM says "Changing this register to 0x0E81, will not affect Long Cable performance.", enable the W/A by default. Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-12net: fec: Better handle pm_runtime_get() failing in .remove()Uwe Kleine-König1-4/+11
In the (unlikely) event that pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is that the driver core ignores the error value and continues removing the device. This results in a resource leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the register mapping is already gone which probably results in a crash. Fixes: a31eda65ba21 ("net: fec: fix clock count mis-match") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230510200020.1534610-1-u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-12ipv6: remove nexthop_fib6_nh_bh()Eric Dumazet2-31/+8
After blamed commit, nexthop_fib6_nh_bh() and nexthop_fib6_nh() are the same. Delete nexthop_fib6_nh_bh(), and convert /proc/net/ipv6_route to standard rcu to avoid this splat: [ 5723.180080] WARNING: suspicious RCU usage [ 5723.180083] ----------------------------- [ 5723.180084] include/net/nexthop.h:516 suspicious rcu_dereference_check() usage! [ 5723.180086] other info that might help us debug this: [ 5723.180087] rcu_scheduler_active = 2, debug_locks = 1 [ 5723.180089] 2 locks held by cat/55856: [ 5723.180091] #0: ffff9440a582afa8 (&p->lock){+.+.}-{3:3}, at: seq_read_iter (fs/seq_file.c:188) [ 5723.180100] #1: ffffffffaac07040 (rcu_read_lock_bh){....}-{1:2}, at: rcu_lock_acquire (include/linux/rcupdate.h:326) [ 5723.180109] stack backtrace: [ 5723.180111] CPU: 14 PID: 55856 Comm: cat Tainted: G S I 6.3.0-dbx-DEV #528 [ 5723.180115] Call Trace: [ 5723.180117] <TASK> [ 5723.180119] dump_stack_lvl (lib/dump_stack.c:107) [ 5723.180124] dump_stack (lib/dump_stack.c:114) [ 5723.180126] lockdep_rcu_suspicious (include/linux/context_tracking.h:122) [ 5723.180132] ipv6_route_seq_show (include/net/nexthop.h:?) [ 5723.180135] ? ipv6_route_seq_next (net/ipv6/ip6_fib.c:2605) [ 5723.180140] seq_read_iter (fs/seq_file.c:272) [ 5723.180145] seq_read (fs/seq_file.c:163) [ 5723.180151] proc_reg_read (fs/proc/inode.c:316 fs/proc/inode.c:328) [ 5723.180155] vfs_read (fs/read_write.c:468) [ 5723.180160] ? up_read (kernel/locking/rwsem.c:1617) [ 5723.180164] ksys_read (fs/read_write.c:613) [ 5723.180168] __x64_sys_read (fs/read_write.c:621) [ 5723.180170] do_syscall_64 (arch/x86/entry/common.c:?) [ 5723.180174] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) [ 5723.180177] RIP: 0033:0x7fa455677d2a Fixes: 09eed1192cec ("neighbour: switch to standard rcu, instead of rcu_bh") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230510154646.370659-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-12devlink: change per-devlink netdev notifier to static oneJiri Pirko3-13/+9
The commit 565b4824c39f ("devlink: change port event netdev notifier from per-net to global") changed original per-net notifier to be per-devlink instance. That fixed the issue of non-receiving events of netdev uninit if that moved to a different namespace. That worked fine in -net tree. However, later on when commit ee75f1fc44dd ("net/mlx5e: Create separate devlink instance for ethernet auxiliary device") and commit 72ed5d5624af ("net/mlx5: Suspend auxiliary devices only in case of PCI device suspend") were merged, a deadlock was introduced when removing a namespace with devlink instance with another nested instance. Here there is the bad flow example resulting in deadlock with mlx5: net_cleanup_work -> cleanup_net (takes down_read(&pernet_ops_rwsem) -> devlink_pernet_pre_exit() -> devlink_reload() -> mlx5_devlink_reload_down() -> mlx5_unload_one_devl_locked() -> mlx5_detach_device() -> del_adev() -> mlx5e_remove() -> mlx5e_destroy_devlink() -> devlink_free() -> unregister_netdevice_notifier() (takes down_write(&pernet_ops_rwsem) Steps to reproduce: $ modprobe mlx5_core $ ip netns add ns1 $ devlink dev reload pci/0000:08:00.0 netns ns1 $ ip netns del ns1 Resolve this by converting the notifier from per-devlink instance to a static one registered during init phase and leaving it registered forever. Use this notifier for all devlink port instances created later on. Note what a tree needs this fix only in case all of the cited fixes commits are present. Reported-by: Moshe Shemesh <moshe@nvidia.com> Fixes: 565b4824c39f ("devlink: change port event netdev notifier from per-net to global") Fixes: ee75f1fc44dd ("net/mlx5e: Create separate devlink instance for ethernet auxiliary device") Fixes: 72ed5d5624af ("net/mlx5: Suspend auxiliary devices only in case of PCI device suspend") Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230510144621.932017-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 05:33:14 +0300