linux-stable.git/drivers/net/wireless, branch v6.7.2

wifi: mwifiex: fix uninitialized firmware_stat

2024-01-25T23:45:16+00:00

commit 3df95e265924ac898c1a38a0c01846dd0bd3b354 upstream.

Variable firmware_stat is possible to be used without initialization.

Signed-off-by: David Lin 
Fixes: 1c5d463c0770 ("wifi: mwifiex: add extra delay for firmware ready")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/r/202312192236.ZflaWYCw-lkp@intel.com/
Acked-by: Brian Norris 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20231221015511.1032128-1-yu-hao.lin@nxp.com
Signed-off-by: Greg Kroah-Hartman

wifi: mwifiex: configure BSSID consistently when starting AP

2024-01-25T23:45:16+00:00

commit f0dd488e11e71ac095df7638d892209c629d9af2 upstream.

AP BSSID configuration is missing at AP start.  Without this fix, FW returns
STA interface MAC address after first init.  When hostapd restarts, it gets MAC
address from netdev before driver sets STA MAC to netdev again. Now MAC address
between hostapd and net interface are different causes STA cannot connect to
AP.  After that MAC address of uap0 mlan0 become the same. And issue disappears
after following hostapd restart (another issue is AP/STA MAC address become the
same).

This patch fixes the issue cleanly.

Signed-off-by: David Lin 
Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers")
Cc: stable@vger.kernel.org
Reviewed-by: Francesco Dolcini 
Tested-by: Rafael Beims  # Verdin iMX8MP/SD8997 SD
Acked-by: Brian Norris 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20231215005118.17031-1-yu-hao.lin@nxp.com
Signed-off-by: Greg Kroah-Hartman

wifi: mwifiex: add extra delay for firmware ready

2024-01-25T23:45:15+00:00

commit 1c5d463c0770c6fa2037511a24fb17966fd07d97 upstream.

For SDIO IW416, due to a bug, FW may return ready before complete full
initialization. Command timeout may occur at driver load after reboot.
Workaround by adding 100ms delay at checking FW status.

Signed-off-by: David Lin 
Cc: stable@vger.kernel.org
Reviewed-by: Francesco Dolcini 
Acked-by: Brian Norris 
Tested-by: Marcel Ziswiler  # Verdin AM62 (IW416)
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20231208234029.2197-1-yu-hao.lin@nxp.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors

2024-01-25T23:45:15+00:00

commit 5894d0089cbc146063dcc0239a78ede0a8142efb upstream.

The rtlwifi driver comes with custom code to write into PCIe Link
Control register. RMW access for the Link Control register requires
locking that is already provided by the standard PCIe capability
accessors.

Convert the custom RMW code writing into LNKCTL register to standard
RMW capability accessors. The accesses are changed to cover the full
LNKCTL register instead of touching just a single byte of the register.

Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20231124084725.12738-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code

2024-01-25T23:45:15+00:00

commit b3943b3c2971444364e03224cfc828c5789deada upstream.

Ever since introduction in the commit 0c8173385e54 ("rtl8192ce: Add new
driver") the rtlwifi code has, according to comments, attempted to
disable/enable ASPM of the upstream bridge by writing into its LNKCTL
register. However, the code has never been correct because it performs
the writes to the device instead of the upstream bridge.

Worse yet, the offset where the PCIe capabilities reside is derived
from the offset of the upstream bridge. As a result, the write will use
an offset on the device that does not relate to the LNKCTL register
making the ASPM disable/enable code outright dangerous.

Because of those problems, there is no indication that the driver needs
disable/enable ASPM on the upstream bridge. As the Capabilities offset
is not correctly calculated for the write to target device's LNKCTL
register, the code is not disabling/enabling device's ASPM either.
Therefore, just remove the upstream bridge related ASPM disable/enable
code entirely.

The upstream bridge related ASPM code was the only user of the struct
mp_adapter members num4bytes, pcibridge_pciehdr_offset, and
pcibridge_linkctrlreg so those are removed as well.

Note: This change does not remove the code related to changing the
device's ASPM on purpose (which is independent of this flawed code
related to upstream bridge's ASPM).

Suggested-by: Bjorn Helgaas 
Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
Fixes: 886e14b65a8f ("rtlwifi: Eliminate raw reads and writes from PCIe portion")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20231124084725.12738-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

wifi: mt76: fix broken precal loading from MTD for mt7915

2024-01-25T23:45:15+00:00

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, &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 
Signed-off-by: Felix Fietkau 
Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: assign phy_ctxt before eSR activation

2024-01-25T23:44:55+00:00

[ Upstream commit 9b6614e5ead5d19a71893bcca3f1a6569ca0c456 ]

eSR is activated when a chanctx is assigned to more than one link.
During eSR activation we should disable RLC for both phys, and configure
the FW with a special phy command for both phys.
Currently we assign the phy_ctxt to the link only after eSR activation,
so RLC is not disabled for the new phy_ctxt, and a cmd is not sent to FW.
Fix this by first assigning the new phy_ctxt to the link and then
doing the eSR activation.

Fixes: 12bacfc2c065 ("wifi: iwlwifi: handle eSR transitions")
Reviewed-by: Gregory Greenman 
Signed-off-by: Miri Korenblit 
Link: https://msgid.link/20231219215605.3d94507f5d9a.I537fcd73aedf94c7348c03157e486f24301fef14@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: fix out of bound copy_from_user

2024-01-25T23:44:55+00:00

[ Upstream commit cb2dfacb197bed0241fbb4f84bd0995a47f4465e ]

The driver copies the userspace buffer into an internal NUL
byte terminated buffer. While doing so, it was reading beyond
the end of the userspace buffer, overwriting its own NUL
termination in the process.

Fix this by only copying the correct number of bytes.

Fixes: 3f244876ef73 ("wifi: iwlwifi: make debugfs entries link specific")
Signed-off-by: Anjaneyulu 
Reviewed-by: Gregory Greenman 
Reviewed-by: Benjamin Berg 
Signed-off-by: Miri Korenblit 
Link: https://msgid.link/20231219215605.e4913deb2ad4.Idcf6a7e909ff4b7801cd49c2f691f84a2f68eff9@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: Do not warn if valid link pair was not found

2024-01-25T23:44:55+00:00

[ Upstream commit c5bfdb46636a2ea7f0678243c6d3e9f8d26b027a ]

It is possible that though multiple links are enabled we cannot enabled
EMLSR enable more than a single link, e.g., all valid links are on the
same band etc. Thus, do not warn in case no valid link pair is found.

Fixes: b9be67fb4207 ("wifi: iwlwifi: mvm: Add basic link selection logic")
Signed-off-by: Ilan Peer 
Reviewed-by: Gregory Greenman 
Signed-off-by: Miri Korenblit 
Link: https://msgid.link/20231219215605.142e57a05230.I7cfe78c94c3d15c4c744bccadd8f187e43594932@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: send TX path flush in rfkill

2024-01-25T23:44:55+00:00

[ Upstream commit 2afc3dad39ea84a072d04ff40a417234326adc47 ]

If we want to drop packets, that's surely a good thing to
do when we want to enter rfkill. Send this command despite
rfkill so we can successfully clean up everything, we need
to handle it separately since it has CMD_WANT_SKB, so it's
not going to automatically return success when in rfkill.

Fixes: d4e3a341b87b ("iwlwifi: mvm: add support for new flush queue response")
Signed-off-by: Johannes Berg 
Reviewed-by: Gregory Greenman 
Signed-off-by: Miri Korenblit 
Link: https://msgid.link/20231219215605.c528a6fa6cec.Ibe5e9560359ccc0fba60c35e01de285c376748a2@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin