aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-11-22ath11k: add read variant from SMBIOS for download board dataWen Gong3-0/+96
This is to read variant from SMBIOS such as read from DT, the variant string will be used to one part of string which used to search board data from board-2.bin. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118100033.8384-1-quic_wgong@quicinc.com
2021-11-22ath11k: skip sending vdev down for channel switchWen Gong1-31/+1
The ath11k driver currently sends vdev down to the firmware before updating the channel context, which is followed by a vdev restart command. Sending vdev down is not required before sending a vdev restart, because the firmware internally does vdev down when ath11k sends a vdev restart command. Firmware will happen crash while channel switch without this change. Hence skip the vdev down command sending when updating the channel context and then fix the firmware crash issue. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118095901.8271-1-quic_wgong@quicinc.com
2021-11-22ath11k: fix read fail for htt_stats and htt_peer_stats for single pdevWen Gong6-3/+86
The pdev id is set to 0 for single pdev configured hardware, the real pdev id is not 0 in firmware, for example, its pdev id is 1 for 5G/6G phy and 2 for 2G band phy. For HTT_H2T_MSG_TYPE_EXT_STATS_CFG message, firmware parse the pdev_mask to its pdev id, ath11k set it to 0 for single pdev, it is not correct, need set it with the real pdev id of firmware. Save the real pdev id report by firmware and set it correctly. Below commands run success with this patch: cat /sys/kernel/debug/ieee80211/phy0/ath11k/htt_stats cat /sys/kernel/debug/ieee80211/phy0/netdev\:wls1/stations/00\:03\:7f\:75\:59\:85/htt_peer_stats Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118095700.8149-1-quic_wgong@quicinc.com
2021-11-22ath11k: calculate the correct NSS of peer for HE capabilitiesWen Gong1-1/+36
When connected to 6G mode AP, it does not have VHT/HT capabilities, so the NSS is not set, then it is 1 by default. This patch is to calculate the NSS with supported HE-MCS and NSS set of HE capabilities. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01280-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118095453.8030-1-quic_wgong@quicinc.com
2021-11-22hv_netvsc: Use bitmap_zalloc() when applicableChristophe JAILLET1-6/+4
'send_section_map' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. While at it, change an '== NULL' test into a '!'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22ath11k: change to treat alpha code na as world wide regdomainWen Gong1-1/+7
Some firmware versions for WCN6855 report the default regdomain with alpha code "na" by default when load as a world wide regdomain, ath11k should treat it as a world wide alpha code. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118094848.7776-1-quic_wgong@quicinc.com
2021-11-22net: ax88796c: do not receive data in pointerNicolas Iooss1-1/+1
Function axspi_read_status calls: ret = spi_write_then_read(ax_spi->spi, ax_spi->cmd_buf, 1, (u8 *)&status, 3); status is a pointer to a struct spi_status, which is 3-byte wide: struct spi_status { u16 isr; u8 status; }; But &status is the pointer to this pointer, and spi_write_then_read does not dereference this parameter: int spi_write_then_read(struct spi_device *spi, const void *txbuf, unsigned n_tx, void *rxbuf, unsigned n_rx) Therefore axspi_read_status currently receive a SPI response in the pointer status, which overwrites 24 bits of the pointer. Thankfully, on Little-Endian systems, the pointer is only used in le16_to_cpus(&status->isr); ... which is a no-operation. So there, the overwritten pointer is not dereferenced. Nevertheless on Big-Endian systems, this can lead to dereferencing pointers after their 24 most significant bits were overwritten. And in all systems this leads to possible use of uninitialized value in functions calling spi_write_then_read which expect status to be initialized when the function returns. Moreover function axspi_read_status (and macro AX_READ_STATUS) do not seem to be used anywhere. So currently this seems to be dead code. Fix the issue anyway so that future code works properly when using function axspi_read_status. Fixes: a97c69ba4f30 ("net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Acked-by: Ɓukasz Stelmach <l.stelmach@samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22qed: Use the bitmap API to simplify some functionsChristophe JAILLET1-19/+5
'cid_map' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Also change some 'memset()' into 'bitmap_zero()' to keep consistency. This is also much less verbose. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: stmmac: retain PTP clock time during SIOCSHWTSTAMP ioctlsHolger Assmann3-47/+81
Currently, when user space emits SIOCSHWTSTAMP ioctl calls such as enabling/disabling timestamping or changing filter settings, the driver reads the current CLOCK_REALTIME value and programming this into the NIC's hardware clock. This might be necessary during system initialization, but at runtime, when the PTP clock has already been synchronized to a grandmaster, a reset of the timestamp settings might result in a clock jump. Furthermore, if the clock is also controlled by phc2sys in automatic mode (where the UTC offset is queried from ptp4l), that UTC-to-TAI offset (currently 37 seconds in 2021) would be temporarily reset to 0, and it would take a long time for phc2sys to readjust so that CLOCK_REALTIME and the PHC are apart by 37 seconds again. To address the issue, we introduce a new function called stmmac_init_tstamp_counter(), which gets called during ndo_open(). It contains the code snippet moved from stmmac_hwtstamp_set() that manages the time synchronization. Besides, the sub second increment configuration is also moved here since the related values are hardware dependent and runtime invariant. Furthermore, the hardware clock must be kept running even when no time stamping mode is selected in order to retain the synchronized time base. That way, timestamping can be enabled again at any time only with the need to compensate the clock's natural drifting. As a side effect, this patch fixes the issue that ptp_clock_info::enable can be called before SIOCSHWTSTAMP and the driver (which looks at priv->systime_flags) was not prepared to handle that ordering. Fixes: 92ba6888510c ("stmmac: add the support for PTP hw clock driver") Reported-by: Michael Olbrich <m.olbrich@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Holger Assmann <h.assmann@pengutronix.de> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22Fix coverity issue 'Uninitialized scalar variable"Yacov Simhony1-1/+1
There are three boolean variable which were not initialized and later being used in the code. Signed-off-by: Yacov Simhony <ysimhony@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22tsn: Fix build.David S. Miller1-2/+2
Due to const dev_addr changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: wwan: iosm: device trace collection using relayfsM Chetan Kumar8-13/+271
This patch brings in support for device trace collection. It implements relayfs interface for pushing device trace from kernel space to user space. Driver gets the debugfs base directory associated to WWAN Device and creates trace_control and trace debugfs for device tracing. Both trace_control & trace debugfs are created under /sys/kernel/debug/wwan/wwan0/. In order to collect device trace on trace0 interface, user need to write 1 to trace_ctl interface. Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: wwan: common debugfs base dir for wwan deviceM Chetan Kumar1-2/+28
This patch set brings in a common debugfs base directory i.e. /sys/kernel/debugfs/wwan/ in WWAN Subsystem for a WWAN device instance. So that it avoids driver polluting debugfs root with unrelated directories & possible name collusion. Having a common debugfs base directory for WWAN drivers eases user to match control devices with debugfs entries. WWAN Subsystem creates dentry (/sys/kernel/debugfs/wwan) on module load & removes dentry on module unload. When driver registers a new wwan device, dentry (wwanX) is created for WWAN device instance & on driver unregister dentry is removed. New API is introduced to return the wwan device instance dentry so that driver can create debugfs entries under it. Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22octeon: constify netdev->dev_addrJakub Kicinski1-1/+1
Argument of a helper is missing a const. Reported-by: kernel test robot <lkp@intel.com> Fixes: adeef3e32146 ("net: constify netdev->dev_addr") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: mana: Add XDP supportHaiyang Zhang4-11/+235
Add support of XDP for the MANA driver. Supported XDP actions: XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED XDP actions not yet supported: XDP_REDIRECT Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22tsnep: Add TSN endpoint Ethernet MAC driverGerhard Engleder11-0/+3511
The TSN endpoint Ethernet MAC is a FPGA based network device for real-time communication. It is integrated as Ethernet controller with ethtool and PTP support. For real-time communcation TC_SETUP_QDISC_TAPRIO is supported. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: phylink: handle NA interface mode in phylink_fwnode_phy_connect()Russell King (Oracle)1-1/+8
Commit 4904b6ea1f9db ("net: phy: phylink: Use PHY device interface if N/A") introduced handling for the phy interface mode where this is not known at phylink creation time. This was never added to the OF/fwnode paths, but is necessary when the phy is present in DT, but the phy-mode is not specified. Add this handling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: phylink: Add helpers for c22 registers without MDIOSean Anderson1-44/+60
Some devices expose memory-mapped c22-compliant PHYs. Because these devices do not have an MDIO bus, we cannot use the existing helpers. Refactor the existing helpers to allow supplying the values for c22 registers directly, instead of using MDIO to access them. Only get_state and set_advertisement are converted, since they contain the most complex logic. Because set_advertisement is never actually used outside phylink_mii_c22_pcs_config, move the MDIO-writing part into that function. Because some modes do not need the advertisement register set at all, we use -EINVAL for this purpose. Additionally, a new function phylink_pcs_enable_an is provided to determine whether to enable autonegotiation. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: annotate accesses to dev->gso_max_segsEric Dumazet17-22/+22
dev->gso_max_segs is written under RTNL protection, or when the device is not yet visible, but is read locklessly. Add netif_set_gso_max_segs() helper. Add the READ_ONCE()/WRITE_ONCE() pairs, and use netif_set_gso_max_segs() where we can to better document what is going on. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: annotate accesses to dev->gso_max_sizeEric Dumazet7-10/+10
dev->gso_max_size is written under RTNL protection, or when the device is not yet visible, but is read locklessly. Add the READ_ONCE()/WRITE_ONCE() pairs, and use netif_set_gso_max_size() where we can to better document what is going on. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22nfp: checking parameter process for rx-usecs/tx-usecs is invalidDiana Wang2-4/+1
Use nn->tlv_caps.me_freq_mhz instead of nn->me_freq_mhz to check whether rx-usecs/tx-usecs is valid. This is because nn->tlv_caps.me_freq_mhz represents the clock_freq (MHz) of the flow processing cores (FPC) on the NIC. While nn->me_freq_mhz is not be set. Fixes: ce991ab6662a ("nfp: read ME frequency from vNIC ctrl memory") Signed-off-by: Diana Wang <na.wang@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: dsa: qca8k: fix MTU calculationRobert Marko1-1/+5
qca8k has a global MTU, so its tracking the MTU per port to make sure that the largest MTU gets applied. Since it uses the frame size instead of MTU the driver MTU change function will then add the size of Ethernet header and checksum on top of MTU. The driver currently populates the per port MTU size as Ethernet frame length + checksum which equals 1518. The issue is that then MTU change function will go through all of the ports, find the largest MTU and apply the Ethernet header + checksum on top of it again, so for a desired MTU of 1500 you will end up with 1536. This is obviously incorrect, so to correct it populate the per port struct MTU with just the MTU and not include the Ethernet header + checksum size as those will be added by the MTU change function. Fixes: f58d2598cf70 ("net: dsa: qca8k: implement the port MTU callbacks") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: dsa: qca8k: fix internal delay applied to the wrong PAD configAnsuel Smith1-6/+6
With SGMII phy the internal delay is always applied to the PAD0 config. This is caused by the falling edge configuration that hardcode the reg to PAD0 (as the falling edge bits are present only in PAD0 reg) Move the delay configuration before the reg overwrite to correctly apply the delay. Fixes: cef08115846e ("net: dsa: qca8k: set internal delay also for sgmii") Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: hns3: remove the way to set tx spare buf via module parameterHao Chen1-6/+1
The way to set tx spare buf via module parameter is not such convenient as the way to set it via ethtool. So,remove the way to set tx spare buf via module parameter. Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: hns3: add support to set/get rx buf len via ethtool for hns3 driverHao Chen1-8/+44
Rx buf len is for rx BD buffer size, support setting it via ethtool -G parameter and getting it via ethtool -g parameter. Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22ethtool: extend ringparam setting/getting API with rx_buf_lenHao Chen93-200/+586
Add two new parameters kernel_ringparam and extack for .get_ringparam and .set_ringparam to extend more ring params through netlink. Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22net: hns3: add support to set/get tx copybreak buf size via ethtool for hns3 driverHao Chen3-2/+60
Tx copybreak buf size is used for tx copybreak feature, the feature is used for small size packet or frag. It adds a queue based tx shared bounce buffer to memcpy the small packet when the len of xmitted skb is below tx_copybreak(value to distinguish small size and normal size), and reduce the overhead of dma map and unmap when IOMMU is on. Support setting it via ethtool --set-tunable parameter and getting it via ethtool --get-tunable parameter. Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-22ath11k: Set IRQ affinity to CPU0 in case of one MSI vectorBaochen Qiang1-2/+23
With VT-d disabled on Intel platform, ath11k gets only one MSI vector. In that case, ath11k does not free IRQ when doing suspend, hence the kernel has to migrate it to CPU0 (if it was affine to other CPUs) and allocates a new MSI vector. However, ath11k has no chance to reconfig it to HW srngs during this phase, thus ath11k fails to resume. This issue can be fixed by setting IRQ affinity to CPU0 before request_irq is called. With such affinity, migration will not happen and thus the vector keeps unchanged during suspend/resume. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211026041732.5323-1-bqiang@codeaurora.org
2021-11-22ath11k: do not restore ASPM in case of single MSI vectorCarl Huang1-1/+7
Current code enables ASPM by default, it allows MHI to enter M2 state. In case of one MSI vector, system hang is observed if ath11k does MHI register reading in this state. The issue was reported on Dell XPS 13 9310 but is seen also on XPS 15 and XPS 17 laptops. The workaround here is to prevent MHI from entering M2 state, this can be done by disabling ASPM if only one MSI vector is used. When using 32 vectors ASPM is enabled as before. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Link: https://lore.kernel.org/r/20211026041722.5271-1-bqiang@codeaurora.org
2021-11-22ath11k: add support one MSI vectorCarl Huang2-15/+51
On some platforms it's not possible to allocate 32 MSI vectors for various reasons, be it kernel configuration, VT-d disabled, buggy BIOS etc. So ath11k was not able to use QCA6390 PCI devices on those platforms. Add support for one MSI vector to solve that. In case of one MSI vector, interrupt migration needs to be disabled. This is because when interrupt migration happens, the msi_data may change. However, msi_data is already programmed to rings during initial phase and ath11k has no way to know that msi_data is changed during run time and reprogram again. In case of one MSI vector, MHI subsystem should not use IRQF_NO_SUSPEND as QCA6390 doesn't set this flag too. Ath11k doesn't need to leave IRQ enabled in suspend state. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Link: https://lore.kernel.org/r/20211026041714.5219-1-bqiang@codeaurora.org
2021-11-22ath11k: refactor multiple MSI vector implementationCarl Huang2-8/+43
This is to prepare for one MSI vector support. IRQ enable and disable of CE and DP are done only in case of multiple MSI vectors. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Link: https://lore.kernel.org/r/20211026041705.5167-1-bqiang@codeaurora.org
2021-11-22ath11k: use ATH11K_PCI_IRQ_DP_OFFSET for DP IRQCarl Huang1-4/+4
Like ATH11K_PCI_IRQ_CE0_OFFSET, define ATH11K_PCI_IRQ_DP_OFFSET for DP to save the IRQ instead of base_vector from MSI config. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Link: https://lore.kernel.org/r/20211026041655.5112-1-bqiang@codeaurora.org
2021-11-22ath11k: add CE and ext IRQ flag to indicate irq_handlerCarl Huang2-0/+18
This change adds two flags to indicate whether IRQ handler for CE and DP can be called. This is because in one MSI vector case, interrupt is not disabled in hif_stop and hif_irq_disable. Otherwise, MHI interrupt is disabled too. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Link: https://lore.kernel.org/r/20211026041646.5060-1-bqiang@codeaurora.org
2021-11-22ath11k: get msi_data again after request_irq is calledCarl Huang1-0/+30
The reservation mode of interrupts in kernel assigns a dummy vector when the interrupt is allocated and assigns a real vector when the request_irq is called. The reservation mode helps to ease vector pressure when devices with a large amount of queues/interrupts are initialized, but only a minimal subset of those queues/interrupts is actually used. So on reservation mode, the msi_data may change after request_irq is called, so ath11k reads msi_data again after request_irq is called, and then the correct msi_data is programmed into QCA6390 hardware components. Without this change, spurious interrupt occurs in case of one MSI vector. When VT-d in BIOS is enabled and ath11k can get 32 MSI vectors, ath11k always get the same msi_data before and after request_irq, that's why this change is only required when one MSI vector is to be supported. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211026041636.5008-1-bqiang@codeaurora.org
2021-11-20bnx2x: constify static inline stub for dev_addrJakub Kicinski1-1/+1
bnx2x_vfpf_config_mac() was constified by not its stub. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-2082596: use eth_hw_addr_set()Jakub Kicinski1-1/+2
Byte by byte assignments. Fixes build on m68k. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: phy: add support for TI DP83561-SP phyHari Nagalla1-20/+22
Add support for the TI DP83561-SP Gigabit ethernet phy device. The dp83561-sp is a radiation hardened space grade gigabit ethernet PHY. It has been tested for single event latch upto 121 MeV, the critical reliability parameter for space designs. It interfaces directly to twisted pair media through an external transformer. And the device also interfaces directly to the MAC layer through Reduced GMII (RGMII) and MII. DP83867, DP83869 and DP83561-SP, all these parts support 1000Base-T/ 100Base-TX/ and 10Base-Te standards and have similar register map for the core functionality. The data sheet for this part is at https://www.ti.com/product/DP83561-SP Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Geet Modi <geet.modi@ti.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20211118102532.9835-1-hnagalla@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-19ethernet: renesas: Use div64_ul instead of do_divYang Li1-4/+2
do_div() does a 64-by-32 division. Here the divisor is an unsigned long which on some platforms is 64 bit wide. So use div64_ul instead of do_div to avoid a possible truncation. Eliminate the following coccicheck warning: ./drivers/net/ethernet/renesas/ravb_main.c:2492:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/1637228883-100100-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-19iavf: Fix VLAN feature flags after VFRBrett Creeley3-23/+56
When a VF goes through a reset, it's possible for the VF's feature set to change. For example it may lose the VIRTCHNL_VF_OFFLOAD_VLAN capability after VF reset. Unfortunately, the driver doesn't correctly deal with this situation and errors are seen from downing/upping the interface and/or moving the interface in/out of a network namespace. When setting the interface down/up we see the following errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF: ice 0000:51:00.1: VF 1 failed opcode 12, retval: -64 iavf 0000:51:09.1: Failed to add VLAN filter, error IAVF_NOT_SUPPORTED ice 0000:51:00.1: VF 1 failed opcode 13, retval: -64 iavf 0000:51:09.1: Failed to delete VLAN filter, error IAVF_NOT_SUPPORTED These add/delete errors are happening because the VLAN filters are tracked internally to the driver and regardless of the VLAN_ALLOWED() setting the driver tries to delete/re-add them over virtchnl. Fix the delete failure by making sure to delete any VLAN filter tracking in the driver when a removal request is made, while preventing the virtchnl request. This makes it so the driver's VLAN list is up to date and the errors are Fix the add failure by making sure the check for VLAN_ALLOWED() during reset is done after the VF receives its capability list from the PF via VIRTCHNL_OP_GET_VF_RESOURCES. If VLAN functionality is not allowed, then prevent requesting re-adding the filters over virtchnl. When moving the interface into a network namespace we see the following errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF: iavf 0000:51:09.1 enp81s0f1v1: NIC Link is Up Speed is 25 Gbps Full Duplex iavf 0000:51:09.1 temp_27: renamed from enp81s0f1v1 iavf 0000:51:09.1 mgmt: renamed from temp_27 iavf 0000:51:09.1 dev27: set_features() failed (-22); wanted 0x020190001fd54833, left 0x020190001fd54bb3 These errors are happening because we aren't correctly updating the netdev capabilities and dealing with ndo_fix_features() and ndo_set_features() correctly. Fix this by only reporting errors in the driver's ndo_set_features() callback when VIRTCHNL_VF_OFFLOAD_VLAN is not allowed and any attempt to enable the VLAN features is made. Also, make sure to disable VLAN insertion, filtering, and stripping since the VIRTCHNL_VF_OFFLOAD_VLAN flag applies to all of them and not just VLAN stripping. Also, after we process the capabilities in the VF reset path, make sure to call netdev_update_features() in case the capabilities have changed in order to update the netdev's feature set to match the VF's actual capabilities. Lastly, make sure to always report success on VLAN filter delete when VIRTCHNL_VF_OFFLOAD_VLAN is not supported. The changed flow in iavf_del_vlans() allows the stack to delete previosly existing VLAN filters even if VLAN filtering is not allowed. This makes it so the VLAN filter list is up to date. Fixes: 8774370d268f ("i40e/i40evf: support for VF VLAN tag stripping control") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-11-19iavf: Fix refreshing iavf adapter stats on ethtool requestJedrzej Jagielski4-0/+25
Currently iavf adapter statistics are refreshed only in a watchdog task, triggered approximately every two seconds, which causes some ethtool requests to return outdated values. Add explicit statistics refresh when requested by ethtool -S. Fixes: b476b0030e61 ("iavf: Move commands processing to the separate function") Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-11-19iavf: Fix deadlock occurrence during resetting VF interfaceJedrzej Jagielski1-2/+5
System hangs if close the interface is called from the kernel during the interface is in resetting state. During resetting operation the link is closing but kernel didn't know it and it tried to close this interface again what sometimes led to deadlock. Inform kernel about current state of interface and turn off the flag IFF_UP when interface is closing until reset is finished. Previously it was most likely to hang the system when kernel (network manager) tried to close the interface in the same time when interface was in resetting state because of deadlock. Fixes: 3c8e0b989aa1 ("i40vf: don't stop me now") Signed-off-by: Jaroslaw Gawin <jaroslawx.gawin@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-11-19iavf: Prevent changing static ITR values if adaptive moderation is onNitesh B Venkatesh1-4/+26
Resolve being able to change static values on VF when adaptive interrupt moderation is enabled. This problem is fixed by checking the interrupt settings is not a combination of change of static value while adaptive interrupt moderation is turned on. Without this fix, the user would be able to change static values on VF with adaptive moderation enabled. Fixes: 65e87c0398f5 ("i40evf: support queue-specific settings for interrupt moderation") Signed-off-by: Nitesh B Venkatesh <nitesh.b.venkatesh@intel.com> Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-11-19nfp: flower: correction of error handlingYu Xiao1-20/+0
Removing reduplicated error handling when running into error path of `nfp_compile_flow_metadata`. Signed-off-by: Yu Xiao <yu.xiao@corigine.com> Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo40-405/+1352
ath.git patches for v5.17. Major changes: ath10k * fetch (pre-)calibration data via nvmem subsystem ath11k * enable 802.11 power save mode in station mode for qca6390 and wcn6855 * trace log support * proper board file detection for WCN6855 based on PCI ids * BSS color change support
2021-11-19stmmac_pci: Fix underflow size in stmmac_rxZekun Shen1-4/+5
This bug report came up when we were testing the device driver by fuzzing. It shows that buf1_len can get underflowed and be 0xfffffffc (4294967292). This bug is triggerable with a compromised/malfunctioning device. We found the bug through QEMU emulation tested the patch with emulation. We did NOT test it on real hardware. Attached is the bug report by fuzzing. BUG: KASAN: use-after-free in stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] Read of size 4294967292 at addr ffff888016358000 by task ksoftirqd/0/9 CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G W 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] __kasan_report.cold+0x37/0x7c ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] kasan_report+0xe/0x20 check_memory_region+0x15a/0x1d0 memcpy+0x20/0x50 stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] ? stmmac_suspend+0x850/0x850 [stmmac] ? __next_timer_interrupt+0xba/0xf0 net_rx_action+0x363/0xbd0 ? call_timer_fn+0x240/0x240 ? __switch_to_asm+0x40/0x70 ? napi_busy_loop+0x520/0x520 ? __schedule+0x839/0x15a0 __do_softirq+0x18c/0x634 ? takeover_tasklets+0x5f0/0x5f0 run_ksoftirqd+0x15/0x20 smpboot_thread_fn+0x2f1/0x6b0 ? smpboot_unregister_percpu_thread+0x160/0x160 ? __kthread_parkme+0x80/0x100 ? smpboot_unregister_percpu_thread+0x160/0x160 kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19atlantic: fix double-free in aq_ring_tx_cleanZekun Shen1-1/+2
We found this bug while fuzzing the device driver. Using and freeing the dangling pointer buff->skb would cause use-after-free and double-free. This bug is triggerable with compromised/malfunctioning devices. We found the bug with QEMU emulation and tested the patch by emulation. We did NOT test on a real device. Attached is the bug report. BUG: KASAN: double-free or invalid-free in consume_skb+0x6c/0x1c0 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? consume_skb+0x6c/0x1c0 kasan_report_invalid_free+0x61/0xa0 ? consume_skb+0x6c/0x1c0 __kasan_slab_free+0x15e/0x170 ? consume_skb+0x6c/0x1c0 kfree+0x8c/0x230 consume_skb+0x6c/0x1c0 aq_ring_tx_clean+0x5c2/0xa80 [atlantic] aq_vec_poll+0x309/0x5d0 [atlantic] ? _sub_I_65535_1+0x20/0x20 [atlantic] ? __next_timer_interrupt+0xba/0xf0 net_rx_action+0x363/0xbd0 ? call_timer_fn+0x240/0x240 ? __switch_to_asm+0x34/0x70 ? napi_busy_loop+0x520/0x520 ? net_tx_action+0x379/0x720 __do_softirq+0x18c/0x634 ? takeover_tasklets+0x5f0/0x5f0 run_ksoftirqd+0x15/0x20 smpboot_thread_fn+0x2f1/0x6b0 ? smpboot_unregister_percpu_thread+0x160/0x160 ? __kthread_parkme+0x80/0x100 ? smpboot_unregister_percpu_thread+0x160/0x160 kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Reviewed-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19sky2: use PCI VPD API in eeprom ethtool opsHeiner Kallweit1-72/+12
Recently pci_read/write_vpd_any() have been added to the PCI VPD API. These functions allow to access VPD address space outside the auto-detected VPD, and they can be used to significantly simplify the eeprom ethtool ops. Tested with a 88E8070 card with 1KB EEPROM. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: marvell: prestera: fix double free issue on err pathVolodymyr Mytnyk1-4/+2
fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380 Fixes: e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: marvell: prestera: fix brige port operationVolodymyr Mytnyk1-1/+1
Return NOTIFY_DONE (dont't care) for switchdev notifications that prestera driver don't know how to handle them. With introduction of SWITCHDEV_BRPORT_[UN]OFFLOADED switchdev events, the driver rejects adding swport to bridge operation which is handled by prestera_bridge_port_join() func. The root cause of this is that prestera driver returns error (EOPNOTSUPP) in prestera_switchdev_blk_event() handler for unknown swdev events. This causes switchdev_bridge_port_offload() to fail when adding port to bridge in prestera_bridge_port_join(). Fixes: 957e2235e526 ("net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: ipa: Use 'for_each_clear_bit' when possibleChristophe JAILLET1-3/+1
Use 'for_each_clear_bit()' instead of hand writing it. It is much less version. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>