On Tue, Feb 25, 2025 at 12:25:16PM -0600, Bjorn Helgaas wrote:
> On Thu, Aug 08, 2024 at 08:43:53AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 07.08.24 11:12, Linux regression tracking (Thorsten Leemhuis) wrote:
> > >
> > > Mukesh Sisodiya, I noticed a report about a regression in
> > > bugzilla.kernel.org that appears to be caused by a change of yours:
> > >
> > > 099a47dbe71b75 ("wifi: iwlwifi: Add support for new 802.11be device")
> > > [v6.9-rc1]
> >
> > For the record, turns out the bisection went a bit sideways and the
> > problems apparently is caused by 84ec2d2e960f33 ("wifi: iwlwifi: disable
> > 160 MHz based on subsystem device ID") [v6.9-rc1]. For details, see
> > https://bugzilla.kernel.org/show_bug.cgi?id=219114#c8
>
> Browsing the regression tracker, this seems stalled with no responses
> even though the submitter (bcc'd) has bisected it.
FWIW, it looks like the following commits are relevant:
https://git.kernel.org/linus/d6f2134a3831 ("iwlwifi: add mac/rf types and 160MHz to the device tables")
https://git.kernel.org/linus/568d3434178b ("iwlwifi: pcie: invert values of NO_160 device config entries")
https://git.kernel.org/linus/4886460c4d15 ("iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit.")
https://git.kernel.org/linus/84ec2d2e960f ("wifi: iwlwifi: disable 160 MHz based on subsystem device ID")
4886460c4d15 ("iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the
correct bit.") updated IWL_SUBDEVICE_NO_160() to identify devices that
should not support 160MHz:
-#define IWL_SUBDEVICE_NO_160(subdevice) ((u16)((subdevice) & 0x0100) >> 9)
+#define IWL_SUBDEVICE_NO_160(subdevice) ((u16)((subdevice) & 0x0200) >> 9)
The submitter's device has Subdevice ID 0x1652. Prior to
4886460c4d15, that did not match IWL_SUBDEVICE_NO_160(), but
afterwards it does:
0000:00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
Subsystem: Rivet Networks Dual Band Wi-Fi 6(802.11ax) Killer AX1650i 160MHz 2x2 [Cyclone Peak] [1a56:1652]
But apparently it wasn't until 84ec2d2e960f ("wifi: iwlwifi: disable
160 MHz based on subsystem device ID"), that 160MHz support actually
got disabled for devices that match IWL_SUBDEVICE_NO_160():
@@ -1061,6 +1061,10 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
+ if (trans->no_160)
+ iftype_data->he_cap.he_cap_elem.phy_cap_info[0] &=
+ ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G;
+
@@ -1394,6 +1394,7 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
dev_info = iwl_pci_find_dev_info(pdev->device, pdev->subsystem_device,
...
IWL_SUBDEVICE_NO_160(pdev->subsystem_device),
...);
if (dev_info) {
iwl_trans->cfg = dev_info->cfg;
iwl_trans->name = dev_info->name;
+ iwl_trans->no_160 = dev_info->no_160 == IWL_CFG_NO_160;
}
84ec2d2e960f appeared in v6.9. Per the submitter, the speed reduction
appeared in v6.8.12. Maybe it was backported? I dunno.
If 160MHz is disabled on that device because of regulatory
restrictions, and it worked when it should not have prior to
84ec2d2e960f, I guess the submitter is out of luck.
If that's the case, maybe we could at least update the bugzilla with
the status to close this out? The submitter has done a LOT of work to
isolate this, and I think we owe them the courtesy of resolving it.
Bjorn
