aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-01-26mt76: mt7915: fix endianness warning in mt7915_mcu_set_radar_thLorenzo Bianconi1-3/+3
Fix the following sparse warning in mt7915_mcu_set_radar_th routine: drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3154:17: warning: incorrect type in initializer (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3154:17: expected unsigned int [usertype] min_pri drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3154:17: got restricted __le32 [usertype] drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3155:17: warning: incorrect type in initializer (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3155:17: expected unsigned int [usertype] max_pri drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3155:17: got restricted __le32 [usertype] drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3162:17: warning: incorrect type in initializer (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3162:17: expected unsigned int [usertype] min_stgpr_diff drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:3162:17: got restricted __le32 [usertype] Fixes: cee236e1489ec ("mt76: mt7915: fix endian issues") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: add support for flash modeShayne Chen4-6/+56
Add support for getting rf values from flash. This is used for some test purposes and products. If the mtd partition is configured in dts, driver will read from flash to init eeprom command; if not, still init it with efuse's values. An example: &slot0 { mt7915@0,0 { reg = <0x0000 0 0 0 0>; device_type = "pci"; mediatek,mtd-eeprom = <&factory 0x0000>; }; }; Acked-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: run mt7915_configure_filter holding mt76 mutexLorenzo Bianconi1-1/+4
In order to avoid races, run mt7915_configure_filter routine holding mt76 mutex Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: convert comma to semicolonZheng Yongjun1-1/+1
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7615: convert comma to semicolonZheng Yongjun1-1/+1
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7615: reset token when mac_reset happensRyder Lee3-12/+22
Reset token in mt7615_mac_reset_work() to avoid possible leakege. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: reset token when mac_reset happensRyder Lee3-17/+26
Reset buffering token in mt7915_mac_reset_work() to avoid possible leakege, which leads to Tx stop after mac reset. Tested-by: Bo Jiao <bo.jiao@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: fix MT_CIPHER_BIP_CMAC_128 setkeyRyder Lee2-6/+21
MCU expects to set WLAN_CIPHER_SUITE_CCMP and WLAN_CIPHER_SUITE_AES_CMAC at the same time, so adding an intermediate buffer for batch update. Tested-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7615: add vif check in mt7615_update_vif_beacon()Ryder Lee1-1/+10
This avoids the WARN_ON(1) calltrace in station mode. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26mt76: mt7915: add vif check in mt7915_update_vif_beacon()Ryder Lee1-1/+9
To avoid the warn_on() calltrace in station mode. [ 4522.024382] ieee80211_tx_dequeue+0x1258/0x1298 [mac80211] [ 4522.029868] ieee80211_beacon_get_template+0x10/0x18 [mac80211] [ 4522.035780] mt7915_mcu_add_beacon+0x2c/0x208 [mt7915e] [ 4522.040997] mt7915_mcu_get_rx_rate+0x304/0x878 [mt7915e] [ 4522.046394] ieee80211_delayed_tailroom_dec+0x158/0x180 [mac80211] [ 4522.052573] ieee80211_iterate_interfaces+0x48/0x68 [mac80211] [ 4522.058398] mt7915_mac_reset_work+0x3b4/0x630 [mt7915e] [ 4522.063704] process_one_work+0x1fc/0x390 [ 4522.067703] worker_thread+0x48/0x4d0 [ 4522.071356] kthread+0x120/0x128 Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2021-01-26i40e: acquire VSI pointer only after VF is initializedStefan Assmann1-7/+4
This change simplifies the VF initialization check and also minimizes the delay between acquiring the VSI pointer and using it. As known by the commit being fixed, there is a risk of the VSI pointer getting changed. Therefore minimize the delay between getting and using the pointer. Fixes: 9889707b06ac ("i40e: Fix crash caused by stress setting of VF MAC addresses") Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26ice: Fix MSI-X vector fallback logicBrett Creeley3-12/+14
The current MSI-X enablement logic tries to enable best-case MSI-X vectors and if that fails we only support a bare-minimum set. This includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X for the OICR interrupt. Unfortunately, the driver fails to load when we don't get as many MSI-X as requested for a couple reasons. First, the code to allocate MSI-X in the driver tries to allocate num_online_cpus() MSI-X for LAN traffic without caring about the number of MSI-X actually enabled/requested from the kernel for LAN traffic. So, when calling ice_get_res() for the PF VSI, it returns failure because the number of available vectors is less than requested. Fix this by not allowing the PF VSI to allocation more than pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues. Limiting the number of queues is done because we don't want more than 1 Tx/Rx queue per interrupt due to performance conerns. Second, the driver assigns pf->num_lan_msix = 2, to account for LAN traffic and the OICR. However, pf->num_lan_msix is only meant for LAN MSI-X. This is causing a failure when the PF VSI tries to allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has already been reserved, so there may not be enough MSI-X vectors left. Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for the failure case. Update the related defines used in ice_ena_msix_range() to align with the above behavior and remove the unused RDMA defines because RDMA is currently not supported. Also, remove the now incorrect comment. Fixes: 152b978a1f90 ("ice: Rework ice_ena_msix_range") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26ice: Don't allow more channels than LAN MSI-X availableBrett Creeley1-4/+4
Currently users could create more channels than LAN MSI-X available. This is happening because there is no check against pf->num_lan_msix when checking the max allowed channels and will cause performance issues if multiple Tx and Rx queues are tied to a single MSI-X. Fix this by not allowing more channels than LAN MSI-X available in pf->num_lan_msix. Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26ice: update dev_addr in ice_set_mac_address even if HW filter existsNick Nunley1-1/+7
Fix the driver to copy the MAC address configured in ndo_set_mac_address into dev_addr, even if the MAC filter already exists in HW. In some situations (e.g. bonding) the netdev's dev_addr could have been modified outside of the driver, with no change to the HW filter, so the driver cannot assume that they match. Fixes: 757976ab16be ("ice: Fix check for removing/adding mac filters") Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26ice: Implement flow for IPv6 next header (extension header)Nick Nunley1-3/+6
This patch is based on a similar change to i40e by Slawomir Laba: "i40e: Implement flow for IPv6 next header (extension header)". When a packet contains an IPv6 header with next header which is an extension header and not a protocol one, the kernel function skb_transport_header called with such sk_buff will return a pointer to the extension header and not to the TCP one. The above explained call caused a problem with packet processing for skb with encapsulation for tunnel with ICE_TX_CTX_EIPT_IPV6. The extension header was not skipped at all. The ipv6_skip_exthdr function does check if next header of the IPV6 header is an extension header and doesn't modify the l4_proto pointer if it points to a protocol header value so its safe to omit the comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can return value -1. This means that the skipping process failed and there is something wrong with the packet so it will be dropped. Fixes: a4e82a81f573 ("ice: Add support for tunnel offloads") Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26ice: fix FDir IPv6 flexbyteHenry Tieman1-1/+7
The packet classifier would occasionally misrecognize an IPv6 training packet when the next protocol field was 0. The correct value for unspecified protocol is IPPROTO_NONE. Fixes: 165d80d6adab ("ice: Support IPv6 Flow Director filters") Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-01-26drivers: net: davinci_mdio: Use of_device_get_match_data()Stephen Boyd1-8/+4
Use the more modern API to get the match data out of the of match table. This saves some code, lines, and nicely avoids referencing the match table when it is undefined with configurations where CONFIG_OF=n. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: <linux-omap@vger.kernel.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210123034428.2841052-3-swboyd@chromium.org
2021-01-26wcn36xx: Remove unnecessary memsetZheng Yongjun1-1/+0
memcpy operation is next to memset code, and the size to copy is equals to the size to memset, so the memset operation is unnecessary, remove it. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201223012516.24286-1-zhengyongjun3@huawei.com
2021-01-26ath11k: add ieee80211_unregister_hw to avoid kernel crash caused by NULL pointerWen Gong1-2/+5
When function return fail to __ath11k_mac_register after success called ieee80211_register_hw, then it set wiphy->dev.parent to NULL by SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, then cfg80211_get_drvinfo will be called by below call stack, but the wiphy->dev.parent is NULL, so kernel crash. Call stack to cfg80211_get_drvinfo: NetworkManager 826 [001] 6696.731371: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) ffffffffc107d8f1 cfg80211_get_drvinfo+0x1 (/lib/modules/5.10.0-rc1-wt-ath+/kernel/net/wireless-back/cfg80211.ko) ffffffff9d8fc529 ethtool_get_drvinfo+0x99 (vmlinux) ffffffff9d90080e dev_ethtool+0x1dbe (vmlinux) ffffffff9d8b88f7 dev_ioctl+0xb7 (vmlinux) ffffffff9d8668de sock_do_ioctl+0xae (vmlinux) ffffffff9d866d60 sock_ioctl+0x350 (vmlinux) ffffffff9d2ca30e __x64_sys_ioctl+0x8e (vmlinux) ffffffff9da0dda3 do_syscall_64+0x33 (vmlinux) ffffffff9dc0008c entry_SYSCALL_64_after_hwframe+0x44 (vmlinux) 7feb5f673007 __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so) 0 [unknown] ([unknown]) Code of cfg80211_get_drvinfo, the pdev which is wiphy->dev.parent is NULL when kernel crash: void cfg80211_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { struct wireless_dev *wdev = dev->ieee80211_ptr; struct device *pdev = wiphy_dev(wdev->wiphy); if (pdev->driver) .... kernel crash log: [ 973.619550] ath11k_pci 0000:05:00.0: failed to perform regd update : -16 [ 973.619555] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16 [ 973.619566] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16 [ 973.619618] ath11k_pci 0000:05:00.0: failed to create pdev core: -16 [ 973.636035] BUG: kernel NULL pointer dereference, address: 0000000000000068 [ 973.636046] #PF: supervisor read access in kernel mode [ 973.636050] #PF: error_code(0x0000) - not-present page [ 973.636054] PGD 800000012452e067 P4D 800000012452e067 PUD 12452d067 PMD 0 [ 973.636064] Oops: 0000 [#1] SMP PTI [ 973.636072] CPU: 3 PID: 848 Comm: NetworkManager Kdump: loaded Tainted: G W OE 5.10.0-rc1-wt-ath+ #24 [ 973.636076] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011 [ 973.636161] RIP: 0010:cfg80211_get_drvinfo+0x25/0xd0 [cfg80211] [ 973.636169] Code: e9 c9 fe ff ff 66 66 66 66 90 55 53 ba 20 00 00 00 48 8b af 08 03 00 00 48 89 f3 48 8d 7e 04 48 8b 45 00 48 8b 80 90 01 00 00 <48> 8b 40 68 48 85 c0 0f 84 8d 00 00 00 48 8b 30 e8 a6 cc 72 c7 48 [ 973.636174] RSP: 0018:ffffaafb4040bbe0 EFLAGS: 00010286 [ 973.636180] RAX: 0000000000000000 RBX: ffffaafb4040bbfc RCX: 0000000000000000 [ 973.636184] RDX: 0000000000000020 RSI: ffffaafb4040bbfc RDI: ffffaafb4040bc00 [ 973.636188] RBP: ffff8a84c9568950 R08: 722d302e30312e35 R09: 74612d74772d3163 [ 973.636192] R10: 3163722d302e3031 R11: 2b6874612d74772d R12: ffffaafb4040bbfc [ 973.636196] R13: 00007ffe453707c0 R14: ffff8a84c9568000 R15: 0000000000000000 [ 973.636202] FS: 00007fd3d179b940(0000) GS:ffff8a84fa2c0000(0000) knlGS:0000000000000000 [ 973.636206] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 973.636211] CR2: 0000000000000068 CR3: 00000001153b6002 CR4: 00000000000606e0 [ 973.636215] Call Trace: [ 973.636234] ethtool_get_drvinfo+0x99/0x1f0 [ 973.636246] dev_ethtool+0x1dbe/0x2be0 [ 973.636256] ? mntput_no_expire+0x35/0x220 [ 973.636264] ? inet_ioctl+0x1ce/0x200 [ 973.636274] ? tomoyo_path_number_perm+0x68/0x1d0 [ 973.636282] ? kmem_cache_alloc+0x3cb/0x430 [ 973.636290] ? dev_ioctl+0xb7/0x570 [ 973.636295] dev_ioctl+0xb7/0x570 [ 973.636307] sock_do_ioctl+0xae/0x150 [ 973.636315] ? sock_ioctl+0x350/0x3c0 [ 973.636319] sock_ioctl+0x350/0x3c0 [ 973.636332] ? __x64_sys_ioctl+0x8e/0xd0 [ 973.636339] ? dlci_ioctl_set+0x30/0x30 [ 973.636346] __x64_sys_ioctl+0x8e/0xd0 [ 973.636359] do_syscall_64+0x33/0x80 [ 973.636368] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sequence of function call when wlan load for success case when function __ath11k_mac_register return 0: kworker/u16:3-e 2922 [001] 6696.729734: probe:ieee80211_register_hw: (ffffffffc116ae60) kworker/u16:3-e 2922 [001] 6696.730210: probe:ieee80211_if_add: (ffffffffc1185cc0) NetworkManager 826 [001] 6696.731345: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.731371: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [001] 6696.731639: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.731653: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [001] 6696.732866: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.732893: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) systemd-udevd 3850 [003] 6696.737199: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) systemd-udevd 3850 [003] 6696.737226: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [000] 6696.759950: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [000] 6696.759967: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [000] 6696.760057: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [000] 6696.760062: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) After apply this patch, kernel crash gone, and below is the test case's sequence of function call and log when wlan load with fail by function ath11k_regd_update, and __ath11k_mac_register return fail: kworker/u16:5-e 192 [001] 215.174388: probe:ieee80211_register_hw: (ffffffffc1131e60) kworker/u16:5-e 192 [000] 215.174973: probe:ieee80211_if_add: (ffffffffc114ccc0) NetworkManager 846 [001] 215.175857: probe:ethtool_get_drvinfo: (ffffffff928fc490) kworker/u16:5-e 192 [000] 215.175867: probe:ieee80211_unregister_hw: (ffffffffc1131970) NetworkManager 846 [001] 215.175880: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) NetworkManager 846 [001] 215.176105: probe:ethtool_get_drvinfo: (ffffffff928fc490) NetworkManager 846 [001] 215.176118: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) [ 215.175859] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16 NetworkManager 846 [001] 215.196420: probe:ethtool_get_drvinfo: (ffffffff928fc490) NetworkManager 846 [001] 215.196430: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) [ 215.258598] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16 [ 215.258613] ath11k_pci 0000:05:00.0: failed to create pdev core: -16 When ath11k_regd_update or ath11k_debugfs_register return fail, function ieee80211_unregister_hw of mac80211 will be called, then it will wait untill cfg80211_get_drvinfo finished, the wiphy->dev.parent is not NULL at this moment, after that, it set wiphy->dev.parent to NULL by SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, so not happen kernel crash. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1608607824-16067-1-git-send-email-wgong@codeaurora.org
2021-01-26cfg80211: avoid holding the RTNL when calling the driverJohannes Berg16-26/+61
Currently, _everything_ in cfg80211 holds the RTNL, and if you have a slow USB device (or a few) you can get some bad lock contention on that. Fix that by re-adding a mutex to each wiphy/rdev as we had at some point, so we have locking for the wireless_dev lists and all the other things in there, and also so that drivers still don't have to worry too much about it (they still won't get parallel calls for a single device). Then, we can restrict the RTNL to a few cases where we add or remove interfaces and really need the added protection. Some of the global list management still also uses the RTNL, since we need to have it anyway for netdev management, but we only hold the RTNL for very short periods of time here. Link: https://lore.kernel.org/r/20210122161942.81df9f5e047a.I4a8e1a60b18863ea8c5e6d3a0faeafb2d45b2f40@changeid Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> [marvell driver issues] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-01-26isa: Make the remove callback for isa drivers return voidUwe Kleine-König2-5/+2
The driver core ignores the return value of the remove callback, so don't give isa drivers the chance to provide a value. Adapt all isa_drivers with a remove callbacks accordingly; they all return 0 unconditionally anyhow. Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for drivers/net/can/sja1000/tscan1.c Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Wolfram Sang <wsa@kernel.org> # for drivers/i2c/ Reviewed-by: Takashi Iway <tiwai@suse.de> # for sound/ Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for drivers/media/ Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210122092449.426097-4-uwe@kleine-koenig.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-25bnxt_en: Do not process completion entries after fatal condition detected.Michael Chan1-0/+8
Once the firmware fatal condition is detected, we should cease comminication with the firmware and hardware quickly even if there are many completion entries in the completion rings. This will speed up the recovery process and prevent further I/Os that may cause further exceptions. Do not proceed in the NAPI poll function if fatal condition is detected. Call napi_complete() and return without arming interrupts. Cleanup of all rings and reset are imminent. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Consolidate firmware reset event logging.Michael Chan1-7/+10
Combine the three netdev_warn() calls into a single call, printed at the NETIF_MSG_HW log level. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Improve firmware fatal error shutdown sequence.Michael Chan1-3/+10
In the event of a fatal firmware error, firmware will notify the host and then it will proceed to do core reset when it sees that all functions have disabled Bus Master. To prevent Master Aborts and other hard errors, we need to quiesce all activities in addition to disabling Bus Master before the chip goes into core reset. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Modify bnxt_disable_int_sync() to be called more than once.Michael Chan1-0/+3
In the event of a fatal firmware error, we want to disable IRQ early in the recovery sequence. This change will allow it to be called safely again as part of the normal shutdown sequence. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Add a new BNXT_STATE_NAPI_DISABLED flag to keep track of NAPI state.Michael Chan2-1/+4
Up until now, we don't need to keep track of this state because NAPI is always enabled once and disabled once during bring up and shutdown. For better error recovery in subsequent patches, we want to quiesce the device earlier during fatal error conditions. The normal shutdown sequence will disable NAPI again and the flag will prevent disabling NAPI twice. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Add bnxt_fw_reset_timeout() helper.Michael Chan1-6/+9
This code to check if we have reached the maximum wait time after firmware reset is used multiple times. Add a helper function to do this. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Retry open if firmware is in reset.Vasundhara Volam2-2/+14
Firmware may be in the middle of reset when the driver tries to do ifup. In that case, firmware will return a special error code and the driver will retry 10 times with 50 msecs delay after each retry. Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: attempt to reinitialize after aborted resetEdwin Peer1-2/+27
Drawing a hard line on aborted resets prevents a NIC open in some scenarios that may otherwise be recoverable. For example, if a firmware recovery happened while a PF was down and an attempt was made to bring up an associated VF in this state, then it was impossible to ever bring up this VF without a rebind or reload of its driver. Attempt to reinitialize the firmware when an aborted reset (or failed init after a reset) is discovered during open - it may succeed. Also take care to allow the user to retry opening the NIC even after an aborted reset. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: log firmware debug notificationsEdwin Peer1-0/+8
Firmware is capable of generating asynchronous debug notifications. The event data is opaque to the driver and is simply logged. Debug notifications can be enabled by turning on hardware status messages using the ethtool msglvl interface. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Add an upper bound for all firmware command timeouts.Vasundhara Volam2-0/+3
The timeout period for firmware messages is passed to the driver from the firmware in the response of the first command. This timeout period is multiplied by a factor for certain long running commands such as NVRAM commands. In some cases, the timeout period can become really long and it can cause hung task warnings if firmware has crashed or is not responding. To avoid such long delays, cap all firmware commands to a max timeout value of 40 seconds. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Move reading VPD info after successful handshake with fw.Vasundhara Volam1-3/+3
If firmware is in reset or in bad state, it won't be able to return VPD data. Move bnxt_vpd_read_info() until after bnxt_fw_init_one_p1() successfully returns. By then we would have established proper communications with the firmware. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Retry sending the first message to firmware if it is under reset.Michael Chan2-7/+42
The first HWRM_VER_GET message to firmware during probe may timeout if firmware is under reset. This can happen during hot-plug for example. On P5 and newer chips, we can check if firmware is in the boot stage by reading a status register. Retry 5 times if the status register shows that firmware is not ready and not in error state. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: handle CRASH_NO_MASTER during bnxt_open()Edwin Peer1-28/+39
Add missing support for handling NO_MASTER crashes while ports are administratively down (ifdown). On some SoC platforms, the driver needs to assist the firmware to recover from a crash via OP-TEE. This is performed in a similar fashion to what is done during driver probe. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Define macros for the various health register states.Michael Chan2-4/+13
Define macros to check for the various states in the lower 16 bits of the health register. Replace the C code that checks for these values with the newly defined macros. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25bnxt_en: Update firmware interface to 1.10.2.11.Michael Chan3-53/+203
Updates to backing store APIs, QoS profiles, and push buffer initial index support. Since the new HWRM_FUNC_BACKING_STORE_CFG message size has increased, we need to add some compat. logic to fall back to the smaller legacy size if firmware cannot accept the larger message size. The new fields added to the structure are not used yet. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25net: dsa: mt7530: MT7530 optional GPIO supportDENG Qingfang2-0/+130
MT7530's LED controller can drive up to 15 LED/GPIOs. Add support for GPIO control and allow users to use its GPIOs by setting gpio-controller property in device tree. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25net: ethernet: mediatek: support setting MTUDENG Qingfang2-8/+47
MT762x HW, except for MT7628, supports frame length up to 2048 (maximum length on GDM), so allow setting MTU up to 2030. Also set the default frame length to the hardware default 1518. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210125042046.5599-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25octeontx2-af: Support ESP/AH RSS hashingSubbaraya Sundeep3-1/+65
Support SPI and sequence number fields of ESP/AH header to be hashed for RSS. By default ESP/AH fields are not considered for RSS and needs to be set explicitly as below: ethtool -U eth0 rx-flow-hash esp4 sdfn or ethtool -U eth0 rx-flow-hash ah4 sdfn or ethtool -U eth0 rx-flow-hash esp6 sdfn or ethtool -U eth0 rx-flow-hash ah6 sdfn To disable hashing of ESP fields: ethtool -U eth0 rx-flow-hash esp4 sd or ethtool -U eth0 rx-flow-hash ah4 sd or ethtool -U eth0 rx-flow-hash esp6 sd or ethtool -U eth0 rx-flow-hash ah6 sd Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Link: https://lore.kernel.org/r/1611378552-13288-1-git-send-email-sundeep.lkml@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25tg3: improve PCI VPD accessHeiner Kallweit2-18/+11
When working on the PCI VPD code I also tested with a Broadcom BCM95719 card. tg3 uses internal NVRAM access with this card, so I forced it to PCI VPD mode for testing. PCI VPD access fails (i + PCI_VPD_LRDT_TAG_SIZE + j > len) because only TG3_NVM_VPD_LEN (256) bytes are read, but PCI VPD has 400 bytes on this card. So add a constant TG3_NVM_PCI_VPD_MAX_LEN that defines the maximum PCI VPD size. The actual VPD size is returned by pci_read_vpd(). In addition it's not worth looping over pci_read_vpd(). If we miss the 125ms timeout per VPD dword read then definitely something is wrong, and if the tg3 module loading is killed then there's also not much benefit in retrying the VPD read. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/cb9e9113-0861-3904-87e0-d4c4ab3c8860@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25iwl4965: do not process non-QOS frames on txq->sched_retry pathStanislaw Gruszka1-5/+6
We have already WARN_ON(!qc) for non-QOS frame on txq->sched_retry path, but we continue to process, what makes no sense since tid is not initialized. Non QOS frame should never happen when aggregation is enabled on queue, so do not process that. Patch should fix smatch warning: drivers/net/wireless/intel/iwlegacy/4965-mac.c:2822 il4965_hdl_tx() error: uninitialized symbol 'tid'. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210119100621.439134-1-stf_xl@wp.pl
2021-01-25mt7601u: process tx URBs with status EPROTO properlyLorenzo Bianconi1-0/+1
Similar to commit 0e40dbd56d67 ("mt7601u: process URBs in status EPROTO properly"), do not process tx URBs if marked with status set to EPROTO. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/72392e8341aa8591c0b9962661a6ca26b1198f32.1610919534.git.lorenzo@kernel.org
2021-01-25wlcore: Fix command execute failure 19 for wl12xxTony Lindgren3-20/+1
We can currently get a "command execute failure 19" error on beacon loss if the signal is weak: wlcore: Beacon loss detected. roles:0xff wlcore: Connection loss work (role_id: 0). ... wlcore: ERROR command execute failure 19 ... WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803 ... (wl12xx_queue_recovery_work.part.0 [wlcore]) (wl12xx_cmd_role_start_sta [wlcore]) (wl1271_op_bss_info_changed [wlcore]) (ieee80211_prep_connection [mac80211]) Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware, and seems to mean that the firmware no longer wants to see the quirk handling for WLCORE_QUIRK_START_STA_FAILS done. This quirk got added with commit 18eab430700d ("wlcore: workaround start_sta problem in wl12xx fw"), and it seems that this already got fixed in the firmware long time ago back in 2012 as wl18xx never had this quirk in place to start with. As we no longer even support firmware that early, to me it seems that it's safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks like earlier firmware got disabled back in 2013 with commit 0e284c074ef9 ("wl12xx: increase minimum singlerole firmware version required"). If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any firmware that the driver works with, we can simply revert this patch and add extra checks for firmware version used. With this fix wlcore reconnects properly after a beacon loss. Cc: Raz Bouganim <r-bouganim@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210115065613.7731-1-tony@atomide.com
2021-01-25mt7601u: use ieee80211_rx_list to pass frames to the network stack as a batchLorenzo Bianconi1-5/+14
Similar to mt76 driver, rely on ieee80211_rx_list in order to improve icache footprint Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/5c72fa2dda45c1ae3f285af80c02f3db23341d85.1610580222.git.lorenzo@kernel.org
2021-01-25rtw88: 8723de: adjust the LTR settingChin-Yen Lee1-2/+2
The LTR mechanism enables PCIE Endpoints to report the service latency requirements and CPU will enter appropriate sleep state to save power based on the LTR value. 8723de provides two registers to config the LTR, and the original setting is too short for CPU to ente sleep state. The patch adjust the LTR setting. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210113014342.3615-1-pkshih@realtek.com
2021-01-25rtlwifi: rtl8821ae: fix bool comparison in expressionsAditya Srivastava1-4/+4
There are certain conditional expressions in rtl8821ae, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c, "if (rtlefuse->autoload_failflag == false)" can be replaced with "if (!rtlefuse->autoload_failflag)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-6-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192se: fix bool comparison in expressionsAditya Srivastava1-2/+2
There are certain conditional expressions in rtl8192se, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-5-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8188ee: fix bool comparison in expressionsAditya Srivastava2-6/+6
There are certain conditional expressions in rtl8188ee, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c, "if (mac->act_scanning == true)" can be replaced with "if (mac->act_scanning)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-4-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192c-common: fix bool comparison in expressionsAditya Srivastava1-2/+2
There are certain conditional expressions in rtl8192c-common, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c, "else if (initialized == false) {" can be replaced with "else if (!initialized) {" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-3-yashsri421@gmail.com
2021-01-25rtlwifi: rtl_pci: fix bool comparison in expressionsAditya Srivastava1-2/+2
There are certain conditional expressions in rtl_pci, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c, "if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-2-yashsri421@gmail.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.