<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless, branch v6.12</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.12</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.12'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2024-10-25T15:53:47Z</updated>
<entry>
<title>wifi: iwlwifi: mvm: fix 6 GHz scan construction</title>
<updated>2024-10-25T15:53:47Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2024-10-23T07:17:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7245012f0f496162dd95d888ed2ceb5a35170f1a'/>
<id>urn:sha1:7245012f0f496162dd95d888ed2ceb5a35170f1a</id>
<content type='text'>
If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.

Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32.

Cc: stable@vger.kernel.org
Fixes: eae94cf82d74 ("iwlwifi: mvm: add support for 6GHz")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219375
Link: https://patch.msgid.link/20241023091744.f4baed5c08a1.I8b417148bbc8c5d11c101e1b8f5bf372e17bf2a7@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "wifi: iwlwifi: remove retry loops in start"</title>
<updated>2024-10-25T15:53:37Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2024-10-22T07:22:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=bfc0ed73e095cc3858d35731f191fa6e3d813262'/>
<id>urn:sha1:bfc0ed73e095cc3858d35731f191fa6e3d813262</id>
<content type='text'>
Revert commit dfdfe4be183b ("wifi: iwlwifi: remove retry loops in
start"), it turns out that there's an issue with the PNVM load
notification from firmware not getting processed, that this patch
has been somewhat successfully papering over. Since this is being
reported, revert the loop removal for now.

We will later at least clean this up to only attempt to retry if
there was a timeout, but currently we don't even bubble up the
failure reason to the correct layer, only returning NULL.

Fixes: dfdfe4be183b ("wifi: iwlwifi: remove retry loops in start")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Link: https://patch.msgid.link/20241022092212.4aa82a558a00.Ibdeff9c8f0d608bc97fc42024392ae763b6937b7@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: don't add default link in fw restart flow</title>
<updated>2024-10-25T15:53:35Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2024-10-10T11:05:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=734a377e1eacc5153bae0ccd4423365726876e93'/>
<id>urn:sha1:734a377e1eacc5153bae0ccd4423365726876e93</id>
<content type='text'>
When we add the vif (and its default link) in fw restart we may
override the link that already exists. We take care of this but if
link 0 is a valid MLO link, then we will re-create a default link on
mvmvif-&gt;link[0] and we'll loose the real link we had there.

In non-MLO, we need to re-create the default link upon the interface
creation, this is fine. In MLO, we'll just wait for change_vif_links()
to re-build the links.

Fixes: bf976c814c86 ("wifi: iwlwifi: mvm: implement link change ops")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.385bfea1b2e9.I4a127312285ccb529cc95cc4edf6fbe1e0a136ad@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()</title>
<updated>2024-10-25T15:53:33Z</updated>
<author>
<name>Daniel Gabay</name>
<email>daniel.gabay@intel.com</email>
</author>
<published>2024-10-10T11:05:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=07a6e3b78a65f4b2796a8d0d4adb1a15a81edead'/>
<id>urn:sha1:07a6e3b78a65f4b2796a8d0d4adb1a15a81edead</id>
<content type='text'>
1. The size of the response packet is not validated.
2. The response buffer is not freed.

Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer.

Fixes: f130bb75d881 ("iwlwifi: add FW recovery flow")
Signed-off-by: Daniel Gabay &lt;daniel.gabay@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.76c73185951e.Id3b6ca82ced2081f5ee4f33c997491d0ebda83f7@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: SAR table alignment</title>
<updated>2024-10-25T15:53:31Z</updated>
<author>
<name>Anjaneyulu</name>
<email>pagadala.yesu.anjaneyulu@intel.com</email>
</author>
<published>2024-10-10T11:05:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=32d95ab330069f9c551b8e99770bb4e799730b55'/>
<id>urn:sha1:32d95ab330069f9c551b8e99770bb4e799730b55</id>
<content type='text'>
SAR table format in ACPI and local data base are different,
So modified code to read data properly.

Signed-off-by: Anjaneyulu &lt;pagadala.yesu.anjaneyulu@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.f077aced4dee.I4dc618f12d01f7ad19f9f8881f6e09eea77e9a14@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: Use the sync timepoint API in suspend</title>
<updated>2024-10-25T15:53:29Z</updated>
<author>
<name>Daniel Gabay</name>
<email>daniel.gabay@intel.com</email>
</author>
<published>2024-10-10T11:05:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9715246ca0bfc9feaec1b4ff5b3d38de65a7025d'/>
<id>urn:sha1:9715246ca0bfc9feaec1b4ff5b3d38de65a7025d</id>
<content type='text'>
When starting the suspend flow, HOST_D3_START triggers an _async_
firmware dump collection for debugging purposes. The async worker
may race with suspend flow and fail to get NIC access, resulting in
the following warning:
"Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)"

Fix this by switching to the sync version to ensure the dump
completes before proceeding with the suspend flow, avoiding
potential race issues.

Signed-off-by: Daniel Gabay &lt;daniel.gabay@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.9aae318cd593.I4b322009f39489c0b1d8893495c887870f73ed9c@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd</title>
<updated>2024-10-25T15:53:26Z</updated>
<author>
<name>Miri Korenblit</name>
<email>miriam.rachel.korenblit@intel.com</email>
</author>
<published>2024-10-10T11:05:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cbe84e9ad5e28ef083beff7f6edf2e623fac09e4'/>
<id>urn:sha1:cbe84e9ad5e28ef083beff7f6edf2e623fac09e4</id>
<content type='text'>
iwl_mvm_send_ap_tx_power_constraint_cmd is a no-op if the link is not
active (we need to know the band etc.)
However, for the station case it will be called just before we set the
link to active (by calling iwl_mvm_link_changed with
the LINK_CONTEXT_MODIFY_ACTIVE bit set in the 'changed' flags and
active = true), so it will end up doing nothing.

Fix this by calling iwl_mvm_send_ap_tx_power_constraint_cmd before
iwl_mvm_link_changed.

Fixes: 6b82f4e119d1 ("wifi: iwlwifi: mvm: handle TPE advertised by AP")
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.5c235fccd3f1.I2d40dea21e5547eba458565edcb4c354d094d82a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: don't leak a link on AP removal</title>
<updated>2024-10-25T15:53:24Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2024-10-10T11:04:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3ed092997a004d68a3a5b0eeb94e71b69839d0f7'/>
<id>urn:sha1:3ed092997a004d68a3a5b0eeb94e71b69839d0f7</id>
<content type='text'>
Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.

Fixes: a8b5d4809b50 ("wifi: iwlwifi: mvm: Configure the link mapping for non-MLD FW")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20241010140328.c54c42779882.Ied79e0d6244dc5a372e8b6ffa8ee9c6e1379ec1d@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'wireless-2024-10-21' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless</title>
<updated>2024-10-25T09:44:41Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2024-10-25T09:44:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e31a8219fbfcf9dc65ba1e1c10cade12b6754e00'/>
<id>urn:sha1:e31a8219fbfcf9dc65ba1e1c10cade12b6754e00</id>
<content type='text'>
wireless fixes for v6.12-rc5

The first set of wireless fixes for v6.12. We have been busy and have
not been able to send this earlier, so there are more fixes than
usual. The fixes are all over, both in stack and in drivers, but
nothing special really standing out.
</content>
</entry>
<entry>
<title>Merge tag 'ath-current-20241016' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath</title>
<updated>2024-10-17T14:25:37Z</updated>
<author>
<name>Kalle Valo</name>
<email>kvalo@kernel.org</email>
</author>
<published>2024-10-17T14:25:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a940b3a1ad0f5bab139fd710dd433aec4eeaea85'/>
<id>urn:sha1:a940b3a1ad0f5bab139fd710dd433aec4eeaea85</id>
<content type='text'>
ath.git patches for v6.12-rc4

Fix two instances of memory leaks, one in ath10k and one in ath11k.
</content>
</entry>
</feed>
