<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/wireless/mediatek/mt76/mt7921, branch linux-6.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-05-11T14:11:17Z</updated>
<entry>
<title>wifi: mt76: mt7921e: stop chip reset worker in unregister hook</title>
<updated>2023-05-11T14:11:17Z</updated>
<author>
<name>Quan Zhou</name>
<email>quan.zhou@mediatek.com</email>
</author>
<published>2023-04-12T21:11:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fe82ebac454f1efce789279fba6ad0b5d1b3004b'/>
<id>urn:sha1:fe82ebac454f1efce789279fba6ad0b5d1b3004b</id>
<content type='text'>
[ Upstream commit 3d78c46423c6567ed25ca033e086865b1b4d5ae1 ]

If the chip reset worker is triggered during the remove process, the chip
DMA may not be properly pushed back to the idle state. This can lead to
corruption of the DMA flow due to the chip reset. Therefore, it is
necessary to stop the chip reset before the DMA is finalized.

To avoid resetting the chip after the reset worker is cancelled, use
__mt7921_mcu_drv_pmctrl() instead of mt7921_mcu_drv_pmctrl(). It is safe to
ignore the pm mutex because the pm worker and wake worker have already been
cancelled.

Fixes: 033ae79b3830 ("mt76: mt7921: refactor init.c to be bus independent")
Co-developed-by: Sean Wang &lt;sean.wang@mediatek.com&gt;
Signed-off-by: Sean Wang &lt;sean.wang@mediatek.com&gt;
Co-developed-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Signed-off-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Co-developed-by: Wang Zhao &lt;wang.zhao@mediatek.com&gt;
Signed-off-by: Wang Zhao &lt;wang.zhao@mediatek.com&gt;
Signed-off-by: Quan Zhou &lt;quan.zhou@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: mt7921e: improve reliability of dma reset</title>
<updated>2023-05-11T14:11:17Z</updated>
<author>
<name>Quan Zhou</name>
<email>quan.zhou@mediatek.com</email>
</author>
<published>2023-04-12T21:11:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bb459e062b5f4471b23b9bd5dc1fb7b1db2bc2ce'/>
<id>urn:sha1:bb459e062b5f4471b23b9bd5dc1fb7b1db2bc2ce</id>
<content type='text'>
[ Upstream commit 87714bf6ed1589813e473db5471e6e9857755764 ]

The hardware team has advised the driver that it is necessary to first put
WFDMA into an idle state before resetting the WFDMA. Otherwise, the WFDMA
may enter an unknown state where it cannot be polled with the right state
successfully. To ensure that the DMA can work properly while a stressful
cold reboot test was being made, we have reordered the programming sequence
in the driver based on the hardware team's guidance.

The patch would modify the WFDMA disabling flow from

"DMA reset -&gt; disabling DMASHDL -&gt; disabling WFDMA -&gt; polling and waiting
until DMA idle" to "disabling WFDMA -&gt; polling and waiting for DMA idle -&gt;
disabling DMASHDL -&gt; DMA reset.

Where he polling and waiting until WFDMA is idle is coordinated with the
operation of disabling WFDMA. Even while WFDMA is being disabled, it can
still handle Tx/Rx requests. The additional polling allows sufficient time
for WFDMA to process the last T/Rx request. When the idle state of WFDMA is
reached, it is a reliable indication that DMASHDL is also idle to ensure it
is safe to disable it and perform the DMA reset.

Fixes: 0a1059d0f060 ("mt76: mt7921: move mt7921_dma_reset in dma.c")
Co-developed-by: Sean Wang &lt;sean.wang@mediatek.com&gt;
Signed-off-by: Sean Wang &lt;sean.wang@mediatek.com&gt;
Co-developed-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Signed-off-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Co-developed-by: Wang Zhao &lt;wang.zhao@mediatek.com&gt;
Signed-off-by: Wang Zhao &lt;wang.zhao@mediatek.com&gt;
Signed-off-by: Quan Zhou &lt;quan.zhou@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: mt7921: fix missing unwind goto in `mt7921u_probe`</title>
<updated>2023-05-11T14:11:17Z</updated>
<author>
<name>Jiefeng Li</name>
<email>jiefeng_li@hust.edu.cn</email>
</author>
<published>2023-04-12T06:22:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cf3e33af4ee11449bcc7b50411414f9e5cc41a82'/>
<id>urn:sha1:cf3e33af4ee11449bcc7b50411414f9e5cc41a82</id>
<content type='text'>
[ Upstream commit 5c47cdebbaeb7724df6f9f46917c93e53f791547 ]

`mt7921u_dma_init` can only return zero or negative number according to its
definition. When it returns non-zero number, there exists an error and this
function should handle this error rather than return directly.

Fixes: 0d2afe09fad5 ("mt76: mt7921: add mt7921u driver")
Signed-off-by: Jiefeng Li &lt;jiefeng_li@hust.edu.cn&gt;
Reviewed-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Reviewed-by: Sridhar Samudrala &lt;sridhar.samudrala@intel.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>mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data</title>
<updated>2023-05-11T14:11:17Z</updated>
<author>
<name>Sean Wang</name>
<email>sean.wang@mediatek.com</email>
</author>
<published>2023-04-11T21:23:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c8ba6780c65f681d217de79e17d63d5d538a239f'/>
<id>urn:sha1:c8ba6780c65f681d217de79e17d63d5d538a239f</id>
<content type='text'>
[ Upstream commit 12db28c3ef31f719bd18fa186a40bb152e6a527c ]

The MT7921 driver no longer uses eeprom.data, but the relevant code has not
been removed completely since
commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").
This could result in potential invalid memory access.

To fix the kernel panic issue in mt7921, it is necessary to avoid accessing
unallocated eeprom.data which can lead to invalid memory access.

Furthermore, it is possible to entirely eliminate the
mt7921_mcu_parse_eeprom function and solely depend on
mt7921_mcu_parse_response to divide the RxD header.

[2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550
[2.702740] #PF: supervisor write access in kernel mode
[2.702741] #PF: error_code(0x0002) - not-present page
[2.702743] PGD 0 P4D 0
[2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI
[2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]
[2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286
[2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000
[2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500
[2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005
[2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40
[2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40
[2.702768] FS:  000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000
[2.702769] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0
[2.702776] PKRU: 55555554
[2.702777] Call Trace:
[2.702782]  mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 &lt;HASH:1bc4 5&gt;]
[2.702785]  mt7921_run_firmware+0x241/0x853 [mt7921_common &lt;HASH:6a2f 6&gt;]
[2.702789]  mt7921e_mcu_init+0x2b/0x56 [mt7921e &lt;HASH:d290 7&gt;]
[2.702792]  mt7921_register_device+0x2eb/0x5a5 [mt7921_common &lt;HASH:6a2f 6&gt;]
[2.702795]  ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e &lt;HASH:d290 7&gt;]
[2.702797]  mt7921_pci_probe+0x2d6/0x319 [mt7921e &lt;HASH:d290 7&gt;]
[2.702799]  pci_device_probe+0x9f/0x12a

Fixes: 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability")
Signed-off-by: Sean Wang &lt;sean.wang@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: mt7921e: fix probe timeout after reboot</title>
<updated>2023-05-11T14:11:16Z</updated>
<author>
<name>Quan Zhou</name>
<email>quan.zhou@mediatek.com</email>
</author>
<published>2023-03-18T07:41:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a633f68901f9d9c91f0ecf85537447a49d743a36'/>
<id>urn:sha1:a633f68901f9d9c91f0ecf85537447a49d743a36</id>
<content type='text'>
[ Upstream commit c397fc1e6365a2a9e5540a85b2c1d4ea412aa0e2 ]

In system warm reboot scene, due to the polling timeout(now 1000us)
is too short to wait dma idle in time, it may make driver probe fail
with error code -ETIMEDOUT. Meanwhile, we also found the dma may take
around 70ms to enter idle state. Change the polling idle timeout to
100ms to avoid the probabilistic probe fail.

Tested pass with 5000 times warm reboot on x86 platform.

[4.477496] pci 0000:01:00.0: attach allowed to drvr mt7921e [internal device]
[4.478306] mt7921e 0000:01:00.0: ASIC revision: 79610010
[4.480063] mt7921e: probe of 0000:01:00.0 failed with error -110

Fixes: 0a1059d0f060 ("mt76: mt7921: move mt7921_dma_reset in dma.c")
Signed-off-by: Quan Zhou &lt;quan.zhou@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: mt7921: fix PCI DMA hang after reboot</title>
<updated>2023-05-11T14:11:16Z</updated>
<author>
<name>Deren Wu</name>
<email>deren.wu@mediatek.com</email>
</author>
<published>2023-02-14T02:49:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a76eaaaafd8b408238d7865bbbbd311f08988f3d'/>
<id>urn:sha1:a76eaaaafd8b408238d7865bbbbd311f08988f3d</id>
<content type='text'>
[ Upstream commit 9270270d62191b7549296721e8d5f3dc0df01563 ]

mt7921 just stop some workers and clean up chip status before reboot.
In stress test, there are working activities still running at the period
of .shutdown callback and that would cause some hosts cannot recover
DMA after reboot. To avoid the floating state in reboot, we use
mt7921_pci_remove() to fully deinit all resources.

Fixes: f23a0cea8bd6 ("wifi: mt76: mt7921e: add pci .shutdown() support")
Signed-off-by: Deren Wu &lt;deren.wu@mediatek.com&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.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: mt7921: fix wrong command to set STA channel</title>
<updated>2023-05-11T14:11:15Z</updated>
<author>
<name>Deren Wu</name>
<email>deren.wu@mediatek.com</email>
</author>
<published>2023-02-11T01:01:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=261fcfc94e4689e56649776cf7ca1ea7bac4ebaf'/>
<id>urn:sha1:261fcfc94e4689e56649776cf7ca1ea7bac4ebaf</id>
<content type='text'>
[ Upstream commit fcc51acfebb85dbc3ab1bea3ce4997d7c0a3a38d ]

Should not use AND operator to check vif type NL80211_IFTYPE_MONITOR, and
that will cause we go into sniffer command for both STA and MONITOR
mode. However, the sniffer command would set channel properly (with some
extra options), the STA mode still works even if using the wrong
command.

Fix vif type check to make sure we using the right command to update
channel.

Fixes: 914189af23b8 ("wifi: mt76: mt7921: fix channel switch fail in monitor mode")
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: mt7921e: Set memory space enable in PCI_COMMAND if unset</title>
<updated>2023-05-11T14:10:48Z</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2023-03-29T19:57:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ca268fbb9279a1e845ee8539dbcc636f51e5b0f3'/>
<id>urn:sha1:ca268fbb9279a1e845ee8539dbcc636f51e5b0f3</id>
<content type='text'>
commit 09d4d6da1b65d09414e7bce61459593f3c80ead1 upstream.

When the BIOS has been configured for Fast Boot, systems with mt7921e
have non-functional wifi.  Turning on Fast boot caused both bus master
enable and memory space enable bits in PCI_COMMAND not to get configured.

The mt7921 driver already sets bus master enable, but explicitly check
and set memory access enable as well to fix this problem.

Tested-by: Anson Tsao &lt;anson.tsao@amd.com&gt;
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Acked-by: Sean Wang &lt;sean.wang@mediatek.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 use-after-free in fw features query.</title>
<updated>2023-05-11T14:10:47Z</updated>
<author>
<name>Ben Greear</name>
<email>greearb@candelatech.com</email>
</author>
<published>2023-03-22T16:37:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f1d2977584eb315a88956e457de7c800cb010478'/>
<id>urn:sha1:f1d2977584eb315a88956e457de7c800cb010478</id>
<content type='text'>
[ Upstream commit 2ceb76f734e37833824b7fab6af17c999eb48d2b ]

Stop referencing 'features' memory after release_firmware is called.

Fixes this crash:

RIP: 0010:mt7921_check_offload_capability+0x17d
mt7921_pci_probe+0xca/0x4b0
...

Signed-off-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Acked-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/51fd8f76494348aa9ecbf0abc471ebe47a983dfd.1679502607.git.lorenzo@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: ignore key disable commands</title>
<updated>2023-04-13T15:02:55Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2023-03-30T09:12:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dd6777595d7921c1f3e4b519f0d519364c4f6bf2'/>
<id>urn:sha1:dd6777595d7921c1f3e4b519f0d519364c4f6bf2</id>
<content type='text'>
commit e6db67fa871dee37d22701daba806bfcd4d9df49 upstream.

This helps avoid cleartext leakage of already queued or powersave buffered
packets, when a reassoc triggers the key deletion.

Cc: stable@vger.kernel.org
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/20230330091259.61378-1-nbd@nbd.name
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
