Newer chips such as MT7915 require up to 16-bits for this field.
Signed-off-by: Chad Monroe <[email protected]>
Acked-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Fix the following sparse warning in mt7915_mac_tx_free routine:
warning: incorrect type in assignment (different base types)
expected unsigned int [usertype] *cur_info
got restricted __le32 *
warning: cast to restricted __le32
Fixes: c17780e7b21ec ("mt76: mt7915: add txfree event v3")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Fix the following sparse warnings:
warning: incorrect type in initializer (different base types)
expected restricted __le16 [usertype] msg_type
got int
warning: incorrect type in assignment (different base types)
expected restricted __le32 [usertype] timestamp
got unsigned int
Fixes: 988845c9361a0 ("mt76: mt7915: add support for passing chip/firmware debug data to user space")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The following error is see from the compiler:
mt7615/debugfs.c: In function ‘mt7615_ext_mac_addr_read’:
mt7615/debugfs.c:465:1: warning: the frame size of 1072 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
The issue is due to allocating a buffer as string storage.
Fix by converting to a dynamical allocation of the buffer.
Reviewed-by: Ryder Lee <[email protected]>
Signed-off-by: Deren Wu <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Fix channel state update error issue due to wrong
register access for mt7916.
Signed-off-by: Sujuan Chen <[email protected]>
Signed-off-by: Bo Jiao <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Add SAR spec support to mt7615 driver to allow configuring SAR power
limitations on the frequency ranges from the userland.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Before, the hardware would be allowed to transmit injected 802.11 MPDUs
as A-MSDU. This resulted in corrupted frames being transmitted. Now,
injected MPDUs are transmitted as-is, without A-MSDU.
The fix was verified with frame injection on MT7915 hardware, both with
and without the injected frame being encrypted.
If the hardware cannot do A-MSDU aggregation on MPDUs, this problem
would also be present in the TX path where mac80211 does the 802.11
encapsulation. However, I have not observed any such problem when
disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode.
Therefore this fix is isolated to injected frames only.
The same A-MSDU logic is also present in the mt7921 driver, so it is
likely that this fix should be applied there too. I do not have access
to mt7921 hardware so I have not been able to test that.
Signed-off-by: Johan Almbladh <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Instead of just taking the maximum per-chain signal strength values,
add an approximation for the sum of the combined signal.
This should more accurately reflect the real signal strength, especially
if the per-chain signal strength values are close to each other
Signed-off-by: Felix Fietkau <[email protected]>
Check ndesc of q_rx to avoid potential hole in iteration.
This is an intermediate patch to add mt7986 support.
Signed-off-by: Sujuan Chen <[email protected]>
Signed-off-by: Bo Jiao <[email protected]>
Reviewed-by: Ryder Lee <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Do not always copy ethernet header in mt{7615,7915,7921}_reverse_frag0_hdr_trans
and use a pointer instead.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Client mode on DFS channels was broken, because the old code was activating
the DFS detector on radar channels while leaving it in CAC state.
This was caused by making the decision based on the channel radar flag,
instead of hw->conf.radar_enabled.
In order to properly deal with the various corner cases, rip out the state
handling code and replace it with something that's much easier to reason
about.
Signed-off-by: Felix Fietkau <[email protected]>
Instead of checking if any queue has not made progress since the last run,
only trigger hang detection if one of the queues has not made any progress
in 10 subsequent runs. This should reduce false positive firmware restarts
Signed-off-by: Felix Fietkau <[email protected]>
On AP mode devices, check beacon tx counters to detect MAC errors.
When an error is detected, stop the MAC before resetting it
Signed-off-by: Felix Fietkau <[email protected]>
Apply sleep mode by default to reduce power consumption as possible.
Signed-off-by: Sean Wang <[email protected]>
Acked-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
We don't have to create a separate sdio.xmit_buf buffer for each queue.
Instead, we just need to create one, reuse it across all queues to reduce
memory consumption further.
And then we should take it into account the actual the host and the device
MMC capability to determine what the appropriate xmit_buf_size can be.
Both MT7921S and MT7663 can support up to Tx FIFO size of 0x3fe00 which
means the device can receive 511 blocks of block size 512 in a row from
the host. So if the driver aggregates the frames as many as possible the
the device can support, we can merge multiple MMC requests into a single
one to get rid of the overhead of the handling and synchronizing in those
unnecessary MMC requests and reduce the SDIO lock contention with the
Bluetooth concurrent traffic and finally to have the higher bus
utilization with less idle cycle.
With the patch, it is helpful for WiFi to have steady throughput
performance especially while running Bluetooth concurrently.
Co-developed-by: Deren Wu <[email protected]>
Signed-off-by: Deren Wu <[email protected]>
Signed-off-by: Sean Wang <[email protected]>
Acked-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
without this change, the fixed MCS only supports 1 Nss.
Fixes: 70fd1333cd32f ("mt76: mt7915: rework .set_bitrate_mask() to support more options")
Reviewed-by: Ryder Lee <[email protected]>
Signed-off-by: MeiChia Chiu <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The maximum max_mpdu_size of mt7915 is 7991, whereas mt7916 can
support 11454.
Reviewed-by: Ryder Lee <[email protected]>
Signed-off-by: Peter Chiu <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Should use peer's bandwidth instead of chandef->width to
get correct mcs_map.
Fixes: 76be6c076c077 ("mt76: mt7915: add .set_bitrate_mask() callback")
Signed-off-by: Peter Chiu <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Always release fw data at the end of mt7921_load_patch routine.
Fixes: 78b217580c509 ("mt76: mt7921s: fix bus hang with wrong privilege")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Free allocated skb in mt7915_mcu_add_sta routine in case of failures.
Fixes: 89bbd3730f382 ("mt76: mt7915: rework starec TLV tags")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The radar detctor is used for dfs channel. So it will start after switching
to dfs channel and will stop after leaving. The TX will be blocked if radar
detctor isn't stopped in non-dfs channel.
This patch resets the dfs state to indicate the radar detector needs to be
stopped.
Signed-off-by: Xing Song <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Check sta_rates pointer value in mt7615_sta_rate_tbl_update routine
since minstrel_ht_update_rates can fail allocating rates array.
Fixes: 04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Check sta_rates pointer value in mt7603_sta_rate_tbl_update routine
since minstrel_ht_update_rates can fail allocating rates array.
Fixes: c8846e1015022 ("mt76: add driver for MT7603E and MT7628/7688")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Remove duplicated DATA4_SU_MU_SPTL_REUSE flag configuration in
mt7921_mac_decode_he_radiotap routine.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Add missing DATA4_TB_SPTL_REUSE1 he radiotap flag to
mt7915_mac_decode_he_radiotap routine.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
mt76_connac_lmac_mapping is shared between mt7921 and mt7915
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Introduce rdd_monitor debugfs node in order to dump rdd2 configuration.
Tested-by: Owen Peng <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Introduce mt7915_mcu_rdd_background_enable and
mt7915_mcu_background_chain_ctrl routines to configure rx dfs dedicated chain.
This is a preliminary patch to add zero-wait dfs support performing CAC
detection on rdd2.
Tested-by: Owen Peng <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
bssinfo/starec disabled commands are sent during removing interface.
However, if we don't set corresponding enabled commands before
removing interface, the fw may enter an exception state due to
some NULL structs.
For example, the following commands can cause fw timeout in our newer
chips:
ifconfig wlan0/mon0 up
ifconfig wlan0/mon0 down
Fix this by setting enabled commands once interface added.
Signed-off-by: Shayne Chen <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Toggle runtime-pm and deep-sleep configuration adding/removing
a montior vif in order to forward all tx/rx frames to mac80211.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Tested-by: Sven Eckelmann <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Fix the following sparse warning in mt7921_mcu_set_tx routine:
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:792:25: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:792:25: expected restricted __le16 [usertype] aifs
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:792:25: got unsigned char [usertype] aifs
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:798:35: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:798:35: expected restricted __le16 [usertype] cw_min
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
It is unnecessary to keep the interrupt enabled in mt76s_sdio_irq because
the driver is already aware of the interrupt, schedules the
mt76s_txrx_worker to handle the corresponding actions, and eventually,
the interrupt would be enabled again when mt76s_txrx_worker finishes its
work.
So we can safely disable the interrupt in mt76s_sdio_irq as soon as
possible to increase the CPU productivity by dropping the redundant
interrupt triggers.
Note that sdio lock acquired/released would be handled in sdio_irq_work
at mmc driver so we don't take care in mt76s_sdio_irq at function driver.
Co-developed-by: Leon Yen <[email protected]>
Signed-off-by: Leon Yen <[email protected]>
Co-developed-by: Deren Wu <[email protected]>
Signed-off-by: Deren Wu <[email protected]>
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
If the nic fails to start, it is possible that the
reset_work has already been scheduled. Ensure the
work item is canceled so we do not have use-after-free
crash in case cleanup is called before the work item
is executed.
This fixes crash on my x86_64 apu2 when mt7921k radio
fails to work. Radio still fails, but OS does not
crash.
Signed-off-by: Ben Greear <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
It doesn't guarantee the mt7921e gets started with ASPM L0 after each
machine reboot on every platform.
If mt7921e gets started with not ASPM L0, it would be possible that the
driver encounters time to time failure in mt7921_pci_probe, like a
weird chip identifier is read
[ 215.514503] mt7921e 0000:05:00.0: ASIC revision: feed0000
[ 216.604741] mt7921e: probe of 0000:05:00.0 failed with error -110
or failing to init hardware because the driver is not allowed to access the
register until the device is in ASPM L0 state. So, we call
__mt7921e_mcu_drv_pmctrl in early mt7921_pci_probe to force the device
to bring back to the L0 state for we can safely access registers in any
case.
In the patch, we move all functions from dma.c to pci.c and register mt76
bus operation earilier, that is the __mt7921e_mcu_drv_pmctrl depends on.
Fixes: bf3747ae2e25 ("mt76: mt7921: enable aspm by default")
Reported-by: Kai-Chuan Hsieh <[email protected]>
Co-developed-by: Deren Wu <[email protected]>
Signed-off-by: Deren Wu <[email protected]>
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
According to the firmware behavior (even the oldest one in linux-firmware)
If the firmware is downloaded, MT7921S must rely on the additional mailbox
mechanism that resides in firmware to check if the device is the right
state for mt7921s_mcu_[fw|drv]_pmctrl. Otherwise, we still apply the old
way for that.
That is a necessary patch before we enable runtime pm for mt7921s as
default.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Co-developed-by: Sean Wang <[email protected]>
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Leon Yen <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>