- 20 Oct, 2021 12 commits
-
-
Lorenzo Bianconi authored
Fix the following sparse warning in mt76x02_mac_write_txwi and mt76x02_mac_tx_rate_val routines: drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:237:19: warning: restricted __le16 degrades to intege warning: cast from restricted __le16 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:383:28: warning: incorrect type in assignment (different base types) expected restricted __le16 [usertype] rate got unsigned long Fixes: db9f11d3 ("mt76: store wcid tx rate info in one u32 reduce locking") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Lorenzo Bianconi authored
Fix MIB tx-rx MIB counters for survey-dump reporting. Fixes: 163f4d22 ("mt76: mt7921: add MAC support") Signed-off-by:
-
Sean Wang authored
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:114:10: error: implicit conversion from enumeration type 'enum mt76_cipher_type' to different enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion] return MT_CIPHER_NONE; ~~~~~~ ^~~~~~~~~~~~~~ drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:10: error: implicit conversion from enumeration type 'enum mt76_cipher_type' to different enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion] return MT_CIPHER_NONE; ~~~~~~ ^~~~~~~~~~~~~~ Fixes: c368362c ("mt76: fix iv and CCMP header insertion") Signed-off-by:Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
mt7921 is mainly used in NB, CE and IoT application where battery life is much concerned so the patch enabled PCIe ASPM by default to shut off the clocks related PCIe as much as possible when MT7921 is either in suspend state or in runtime pm to lower power consumption. We still leave disable aspm as an option with module_param for users to disable ASPM if necessary. Signed-off-by:
-
Leon Yen authored
The mistaken structure is introduced since we added the GTK rekey offload to mt7663. The patch fixes mt76_connac_gtk_rekey_tlv structure according to the MT7663 and MT7921 firmware we have submitted into linux-firmware.git. Fixes: b47e21e7 ("mt76: mt7615: add gtk rekey offload support") Signed-off-by:
Leon Yen <Leon.Yen@mediatek.com> Signed-off-by:
-
Bo Jiao authored
It will cause maximum connectable STA to be one less when calling mt76_wcid_alloc with parameter MT7915_WTBL_STA - 1. Signed-off-by:
Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by:
Sujuan Chen <sujuan.chen@mediatek.com> Reviewed-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Dan Carpenter authored
Zero out all the unused members of "req" so that we don't disclose stack information. Fixes: 495184ac ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Lorenzo Bianconi authored
Fix the following sparse warning in mt7615_mac_write_txwi routine: drivers/net/wireless/mediatek/mt76/mt7615/mac.c:758:17: warning: incorrect type in assignment expected restricted __le32 [usertype] got unsigned long Fixes: 04b8e659 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: d4bf77bd ("mt76: mt7615: introduce mt7663u support to mt7615_write_txwi") Signed-off-by:
-
Lorenzo Bianconi authored
Fix the following sparse warning in mt7921_update_txs routine: drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31: warning: restricted __le32 degrades to integer Fixes: e5bca8c5 ("mt76: mt7921: improve code readability for mt7921_update_txs") Signed-off-by:
-
Lorenzo Bianconi authored
Fix the following sparse warning in mt7915_mac_add_txs_skb routine: drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:29: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:23: warning: restricted __le32 degrades to integer Fixes: 3de4cb17 ("mt76: mt7915: add support for tx status reporting") Signed-off-by:
-
Lorenzo Bianconi authored
Do not grab the spinlock in mt7921_mcu_tx_done_event routine if not necessary. Signed-off-by:
-
Lorenzo Bianconi authored
Fix endianness in mt7921_mcu_tx_done_event event reported by the firmware. Fixes: 3cce2b98 ("mt76: mt7921: introduce mac tx done handling") Signed-off-by:
-
- 18 Oct, 2021 5 commits
-
-
Colin Ian King authored
The function rtw89_mac_enable_bb_rf is a void return type, so there is no return error code to ret, so the following check for an error in ret is redundant dead code and can be removed. Addresses-Coverity: ("Logically dead code") Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015152113.33179-1-colin.king@canonical.com
-
Colin Ian King authored
There are two spelling mistakes in rtw89_debug messages. Fix them. Signed-off-by:
-
Ping-Ke Shih authored
Add maintainer and email to MAINTAINERS file. Signed-off-by:
-
Jonas Dreßler authored
It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by:
Jonas Dreßler <verdre@v0yd.nl> Signed-off-by:
-
Jonas Dreßler authored
On the 88W8897 PCIe+USB card the firmware randomly crashes after setting the TX ring write pointer. The issue is present in the latest firmware version 15.68.19.p21 of the PCIe+USB card. Those firmware crashes can be worked around by reading any PCI register of the card after setting that register, so read the PCI_VENDOR_ID register here. The reason this works is probably because we keep the bus from entering an ASPM state for a bit longer, because that's what causes the cards firmware to crash. This fixes a bug where during RX/TX traffic and with ASPM L1 substates enabled (the specific substates where the issue happens appear to be platform dependent), the firmware crashes and eventually a command timeout appears in the logs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by:
-
- 13 Oct, 2021 4 commits
-
-
Christophe JAILLET authored
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read, it is assigned later on with a different value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Jakub Kicinski <kubakici@wp.pl> Signed-off-by:
-
Colin Ian King authored
The variable version is being initialized with a value that is never read, it is being updated afterwards in both branches of an if statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Ping-Ke Shih authored
This driver named rtw89, which is the next generation of rtw88, supports Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC, Spatial reuse, TWT and BSS coloring; now some of them aren't implemented though. The chip architecture is entirely different from the chips supported by rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges are totally redefined, so it's impossible to reuse register definition. To communicate with firmware, new H2C/C2H format is proposed. In order to have better utilization, TX DMA flow is changed to two stages DMA. To provide rich RX status information, additional RX PPDU packets are added. Since there are so many differences mentioned above, we decide to propose a new driver. It has many authors, they are listed in alphabetic order: Chin-Yen Lee <timlee@realtek.com> Ping-Ke Shih <pkshih@realtek.com> Po Hao Huang <phhuang@realtek.com> Tzu-En Huang <tehuang@realtek.com> Vincent Fann <vincent_fann@realtek.com> Yan-Hsuan Chuang <tony0620emma@gmail.com> Zong-Zhe Yang <kevin_yang@realtek.com> Tested-by:
Aaron Ma <aaron.ma@canonical.com> Tested-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
- 11 Oct, 2021 2 commits
-
-
Dan Carpenter authored
The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: ef1a628d ("b43: Implement dynamic PHY API") Signed-off-by:Michael Büsch <m@bues.ch> Signed-off-by:
-
Dan Carpenter authored
The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: 75388acd ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Signed-off-by:
-
- 10 Oct, 2021 17 commits
-
-
Subbaraya Sundeep authored
This patch separates the logic of configuring hardware maximum transmit frame size and receive frame size. This simplifies the logic to calculate receive buffer size and using cqe descriptor of different size. Also additional size of skb_shared_info structure is allocated for each receive buffer pointer given to hardware which is not necessary. Hence change the size calculation to remove the size of skb_shared_info. Add a check for array out of bounds while adding fragments to the network stack. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Christophe JAILLET authored
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by:
-
Li RongQing authored
networking benchmark shows that __rcu_read_lock and __rcu_read_unlock takes some cpu cycles, and we can avoid calling them partially in virtio rx path by check xdp_enabled of vi, and xdp is disabled most of time Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
-
Antoine Tenart authored
Cosmetic commit making dev_get_port_parent_id slightly more readable. There is no need to split the condition to return after calling devlink_compat_switch_id_get and after that 'recurse' is always true. Signed-off-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Ansuel Smith authored
Give a name to known debug regs from Documentation instead of using unknown hex values. Signed-off-by:
Ansuel Smith <ansuelsmth@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Ansuel Smith authored
From original QCA source code the port was set to prefer master as port type in 1000BASE-T mode. Apply the same settings also here. Signed-off-by:
-
Ansuel Smith authored
QCA8327 internal phy require DAC amplitude adjustement set to +6% with 100m speed. Also add additional define to report a change of the same reg in QCA8337. (different scope it does set 1000m voltage) Add link_change_notify function to set the proper amplitude adjustement on PHY_RUNNING state and disable on any other state. Fixes: b4df02b5 ("net: phy: at803x: add support for qca 8327 A variant internal phy") Signed-off-by:
-
Ansuel Smith authored
From Documentation phy resume triggers phy reset and restart auto-negotiation. Add a dedicated function to wait reset to finish as it was notice a regression where port sometime are not reliable after a suspend/resume session. The reset wait logic is copied from phy_poll_reset. Add dedicated suspend function to use genphy_suspend only with QCA8337 phy and set only additional debug settings for QCA8327. With more test it was reported that QCA8327 doesn't proprely support this mode and using this cause the unreliability of the switch ports, especially the malfunction of the port0. Fixes: 15b9df4e ("net: phy: at803x: add resume/suspend function to qca83xx phy") Signed-off-by:
-
David S. Miller authored
Juhee Kang says: ==================== net-next: replace open code with helper functions Currently, there are many helper functions on netdevice.h. However, some code doesn't use the helper functions and remains open code. So this patchset replaces open code with an appropriate helper function. First patch modifies to use netif_is_rxfh_configured instead of dev->priv_flags & IFF_RXFH_CONFIGURED. Second patch replaces open code with netif_is_bond_master. Last patch substitutes netif_is_macsec() for dev->priv_flags & IFF_MACSEC. ==================== Signed-off-by: -
Juhee Kang authored
Open code which is dev->priv_flags & IFF_MACSEC has already defined as netif_is_macsec(). So use netif_is_macsec() instead of open code. This patch doesn't change logic. Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Signed-off-by:
-
Juhee Kang authored
Use netif_is_bond_master() function instead of open code, which is ((event_dev->priv_flags & IFF_BONDING) && (event_dev->flags & IFF_MASTER)). This patch doesn't change logic. Signed-off-by:
-
Juhee Kang authored
The open code which is dev->priv_flags & IFF_RXFH_CONFIGURED is defined as a helper function on netdevice.h. So use netif_is_rxfh_configured() function instead of open code. This patch doesn't change logic. Signed-off-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: add vlanid overflow management Add vlans to the existing rx_filter_sync mechanics currently used for managing mac filters. Older versions of our firmware had no enforced limits on the number of vlans that the driver could request, but requesting large numbers of vlans caused issues in FW memory management, so an arbitrary limit was added in the FW. The FW now returns -ENOSPC when it hits that limit, which the driver needs to handle. Unfortunately, the FW doesn't advertise the vlan id limit, as it does with mac filters, so the driver won't know the limit until it bumps into it. We'll grab the current vlan id count and use that as the limit from there on and thus prevent getting any more -ENOSPC errors. Just as is done for the mac filters, the device puts the device into promiscuous mode when -ENOSPC is seen for vlan ids, and the driver will track the vlans that aren't synced to the FW. When vlans are removed, the driver will retry the un-synced vlans. If all outstanding vlans are synced, the promiscuous mode will be disabled. The first 6 patches rework the existing filter management to make it flexible enough for additional filter types. Next we add the vlan ids into the management. The last 2 patches allow us to catch the max vlan -ENOSPC error without adding an unnecessary error message to the kernel log. ==================== Signed-off-by: -
Shannon Nelson authored
Override the automatic AdminQ error message in order to capture the potential No Space message when we hit the max vlan limit, and add additional messaging to detail what filter failed. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
The AdminQ handler has an error handler that automatically prints an error message when the request has failed. However, there are situations where the caller can expect that it might fail and has an alternative strategy, thus may not want the error message sent to the log, such as hitting -ENOSPC when adding a new vlan id. We add a new interface to the AdminQ API to allow for override of the default behavior, and an interface to the use standard error message formatting. Signed-off-by:
-
Shannon Nelson authored
Add vlans to the existing rx_filter_sync mechanics currently used for managing mac filters. Older versions of our firmware had no enforced limits on the number of vlans that the LIF could request, but requesting large numbers of vlans caused issues in FW memory management, so an arbitrary limit was added in the FW. The FW now returns -ENOSPC when it hits that limit, which the driver needs to handle. Unfortunately, the FW doesn't advertise the vlan id limit, as it does with mac filters, so the driver won't know the limit until it bumps into it. We'll grab the current vlan id count and use that as the limit from there on and thus prevent getting any more -ENOSPC errors. Just as is done for the mac filters, the device puts the device into promiscuous mode when -ENOSPC is seen for vlan ids, and the driver will track the vlans that aren't synced to the FW. When vlans are removed, the driver will retry the un-synced vlans. If all outstanding vlans are synced, the promiscuous mode will be disabled. Signed-off-by:
-
Shannon Nelson authored
Similar to the filter add, make a generic filter delete. Signed-off-by:
-
