<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/mediatek, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-01-25T23:27:43+00:00</updated>
<entry>
<title>wifi: mt76: fix broken precal loading from MTD for mt7915</title>
<updated>2024-01-25T23:27:43+00:00</updated>
<author>
<name>Christian Marangi</name>
<email>ansuelsmth@gmail.com</email>
</author>
<published>2023-10-18T13:09:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=debfa60412aff170bf0962ce87216962d46c3c9a'/>
<id>urn:sha1:debfa60412aff170bf0962ce87216962d46c3c9a</id>
<content type='text'>
commit e874a79250b39447765ac13272b67ac36ccf2a75 upstream.

Commit 495184ac91bb ("mt76: mt7915: add support for applying
pre-calibration data") was fundamentally broken and never worked.

The idea (before NVMEM support) was to expand the MTD function and pass
an additional offset. For normal EEPROM load the offset would always be
0. For the purpose of precal loading, an offset was passed that was
internally the size of EEPROM, since precal data is right after the
EEPROM.

Problem is that the offset value passed is never handled and is actually
overwrite by

	offset = be32_to_cpup(list);
	ret = mtd_read(mtd, offset, len, &amp;retlen, eep);

resulting in the passed offset value always ingnored. (and even passing
garbage data as precal as the start of the EEPROM is getting read)

Fix this by adding to the current offset value, the offset from DT to
correctly read the piece of data at the requested location.

Cc: stable@vger.kernel.org
Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data")
Signed-off-by: Christian Marangi &lt;ansuelsmth@gmail.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7921: fix country count limitation for CLC</title>
<updated>2024-01-25T23:27:27+00:00</updated>
<author>
<name>Ming Yen Hsieh</name>
<email>mingyen.hsieh@mediatek.com</email>
</author>
<published>2023-11-22T03:06:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0c9318d49e501a5d50b02bd91a4813bde2353488'/>
<id>urn:sha1:0c9318d49e501a5d50b02bd91a4813bde2353488</id>
<content type='text'>
[ Upstream commit fa6ad88e023ddfa6c5dcdb466d159e89f451e305 ]

Due to the increase in the number of power tables for 6Ghz on CLC,
the variable nr_country is no longer sufficient to represent the
total quantity. Therefore, we have switched to calculating the
length of clc buf to obtain the correct power table. Additionally,
the version number has been incremented to 1.

Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support")
Signed-off-by: Ming Yen Hsieh &lt;mingyen.hsieh@mediatek.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7921s: fix workqueue problem causes STA association fail</title>
<updated>2024-01-25T23:27:27+00:00</updated>
<author>
<name>Wang Zhao</name>
<email>wang.zhao@mediatek.com</email>
</author>
<published>2023-11-17T12:54:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4054b2b1e6def22f7e54e9776ce746427f0f0faf'/>
<id>urn:sha1:4054b2b1e6def22f7e54e9776ce746427f0f0faf</id>
<content type='text'>
[ Upstream commit 92184eae1d5ad804884e2c6e289d885b9e3194d1 ]

The ieee80211_queue_work function queues work into the mac80211
local-&gt;workqueue, which is widely used for mac80211 internal
work processes. In the mt76 driver, both the mt76-sido-status and
mt76-sdio-net threads enqueue workers to the workqueue with this
function. However, in some cases, when two workers are enqueued
to the workqueue almost simultaneously, the second worker may not
be scheduled immediately and may get stuck for a while.
This can cause timing issues. To avoid these timing
conflicts caused by worker scheduling, replace the worker
with an independent thread.

Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Wang Zhao &lt;wang.zhao@mediatek.com&gt;
Signed-off-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7915: fix beamforming availability check</title>
<updated>2023-11-20T10:51:53+00:00</updated>
<author>
<name>MeiChia Chiu</name>
<email>meichia.chiu@mediatek.com</email>
</author>
<published>2023-08-31T06:22:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ebca9ae926df49d52866430c7485dfdd6d023039'/>
<id>urn:sha1:ebca9ae926df49d52866430c7485dfdd6d023039</id>
<content type='text'>
[ Upstream commit ced1a0b8f3944e44e7f4eb3772dea1bada25d38a ]

Without this patch, when ap sets the tx stream number to 2,
ap won't send any beamforming packet.

Fixes: f89f297aef28 ("mt76: mt7915: fix txbf starec TLV issues")
Signed-off-by: MeiChia Chiu &lt;meichia.chiu@mediatek.com&gt;
Signed-off-by: Shayne Chen &lt;shayne.chen@mediatek.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7603: improve stuck beacon handling</title>
<updated>2023-11-20T10:51:53+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2023-07-28T14:21:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b12aebbd324c9723cc1855102b915cc53b39943'/>
<id>urn:sha1:2b12aebbd324c9723cc1855102b915cc53b39943</id>
<content type='text'>
[ Upstream commit 3176205933494bd184c6acd70e796c382bc729b5 ]

Before preparing the new beacon, check the queue status, flush out all
previous beacons and buffered multicast packets, then (if necessary)
try to recover more gracefully from a stuck beacon condition by making a
less invasive attempt at getting the MAC un-stuck.

Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7603: improve watchdog reset reliablity</title>
<updated>2023-11-20T10:51:52+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2023-07-28T14:04:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2fd48179cf26c261fe5b9f9ea5a974e924fbef7'/>
<id>urn:sha1:c2fd48179cf26c261fe5b9f9ea5a974e924fbef7</id>
<content type='text'>
[ Upstream commit c677dda165231c3efffb9de4bace249d5d2a51b9 ]

Only trigger PSE reset if PSE was stuck, otherwise it can cause DMA issues.
Trigger the PSE reset while DMA is fully stopped in order to improve
reliabilty.

Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7603: rework/fix rx pse hang check</title>
<updated>2023-11-20T10:51:52+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2023-07-28T07:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3c46ce78ddf61890fdd246b55822555f69c8b4f'/>
<id>urn:sha1:e3c46ce78ddf61890fdd246b55822555f69c8b4f</id>
<content type='text'>
[ Upstream commit baa19b2e4b7bbb509a7ca7939c8785477dcd40ee ]

It turns out that the code in mt7603_rx_pse_busy() does not detect actual
hardware hangs, it only checks for busy conditions in PSE.
A reset should only be performed if these conditions are true and if there
is no rx activity as well.
Reset the counter whenever a rx interrupt occurs. In order to also deal with
a fully loaded CPU that leaves interrupts disabled with continuous NAPI
polling, also check for pending rx interrupts in the function itself.

Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling</title>
<updated>2023-10-10T20:00:40+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2023-09-19T19:47:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6150d4596861cc564f88f6dcea956f83b5d83ac9'/>
<id>urn:sha1:6150d4596861cc564f88f6dcea956f83b5d83ac9</id>
<content type='text'>
[ Upstream commit 684e45e120b82deccaf8b85633905304a3bbf56d ]

On MT76x0, LNA gain should be applied for both external and internal LNA.
On MT76x2, LNA gain should be treated as 0 for external LNA.
Move the LNA type based logic to mt76x2 in order to fix mt76x0.

Fixes: 2daa67588f34 ("mt76x0: unify lna_gain parsing")
Reported-by: Shiji Yang &lt;yangshiji66@outlook.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230919194747.31647-1-nbd@nbd.name
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mt76: mt7921: don't assume adequate headroom for SDIO headers</title>
<updated>2023-09-23T09:11:01+00:00</updated>
<author>
<name>Matt Whitlock</name>
<email>kernel@mattwhitlock.name</email>
</author>
<published>2023-04-20T19:24:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c8bbb79c7cbca65534badf360f3b1145759c7bc'/>
<id>urn:sha1:5c8bbb79c7cbca65534badf360f3b1145759c7bc</id>
<content type='text'>
[ Upstream commit 98c4d0abf5c478db1ad126ff0c187dbb84c0803c ]

mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and
mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that
adequate headroom will be available in the passed skb. This assumption
typically is satisfied when the skb was allocated in the net core for
transmission via the mt7921 netdev (although even that is only an
optimization and is not strictly guaranteed), but the assumption is
sometimes not satisfied when the skb originated in the receive path of
another netdev and was passed through to the mt7921, such as by the
bridge layer. Blindly prepending bytes to an skb is always wrong.

This commit introduces a call to skb_cow_head() before the call to
mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to
ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be
pushed onto the skb.

Without this fix, I can trivially cause kernel panics by bridging an
MT7921AU-based USB 802.11ax interface with an Ethernet interface on an
Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet
adapter and also on an ARM-based Raspberry Pi 1 using its onboard
SMSC9512 USB Ethernet adapter. Note that the panics do not occur in
every system configuration, as they occur only if the receiving netdev
leaves less headroom in its received skbs than the mt7921 needs for its
SDIO headers.

Here is an example stack trace of this panic on Raspberry Pi OS Lite
2023-02-21 running kernel 6.1.24+ [1]:

 skb_panic from skb_push+0x44/0x48
 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]
 mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]
 mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]
 __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]
 mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]
 mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]
 mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]
 __mt76_worker_fn [mt76] from kthread+0xbc/0xe0
 kthread from ret_from_fork+0x14/0x34

After this fix, bridging the mt7921 interface works fine on both of my
previously problematic systems.

[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a

Link: https://github.com/openwrt/openwrt/issues/11796
Signed-off-by: Matt Whitlock &lt;kernel@mattwhitlock.name&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7915: fix power-limits while chan_switch</title>
<updated>2023-09-13T07:42:31+00:00</updated>
<author>
<name>Ryder Lee</name>
<email>ryder.lee@mediatek.com</email>
</author>
<published>2023-07-26T18:35:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49b6db89ab287f443e6fd9aa178780d76c8f1f60'/>
<id>urn:sha1:49b6db89ab287f443e6fd9aa178780d76c8f1f60</id>
<content type='text'>
[ Upstream commit 6c0570bc21ec2073890aa252c8420ca7bec402e4 ]

If user changes the channel without completely disabling the interface the
txpower_sku values reported track the old channel the device was operating on.
If user bounces the interface the correct power tables are applied.

mt7915_sku_group_len array gets updated before the channel switch happens so it
uses data from the old channel.

Fixes: ecb187a74e18 ("mt76: mt7915: rework the flow of txpower setting")
Fixes: f1d962369d56 ("mt76: mt7915: implement HE per-rate tx power support")
Reported-By: Chad Monroe &lt;chad.monroe@smartrg.com&gt;
Tested-by: Chad Monroe &lt;chad.monroe@smartrg.com&gt;
Signed-off-by: Allen Ye &lt;allen.ye@mediatek.com&gt;
Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
