From: Gregory Greenman <[email protected]>
Hi,
This patch set includes iwlwifi patches intended for v6.5.
It contains normal developement, cleanups and bugfixes.
Thanks,
Gregory
Benjamin Berg (1):
wifi: iwlwifi: mvm: send LARI configuration earlier
Emmanuel Grumbach (2):
wifi: iwlwifi: mvm: check the right csa_active
wifi: iwlwifi: mvm: make iwl_mvm_set_fw_mu_edca_params mld aware
Ilan Peer (1):
wifi: iwlwifi: mvm: Add support for scan version 17
Johannes Berg (13):
wifi: iwlwifi: pcie: refactor RB status size calculation
wifi: iwlwifi: pcie: add size assertions
wifi: iwlwifi: nvm: handle EHT/320 MHz regulatory flag
wifi: iwlwifi: mvm: use EHT maximum MPDU length on 2.4 GHz
wifi: iwlwifi: mvm: use min_t() for agg_size
wifi: iwlwifi: mvm: add EHT A-MPDU size exponent support
wifi: iwlwifi: limit EHT capabilities based on PCIe link speed
wifi: iwlwifi: remove disable_dummy_notification
wifi: iwlwifi: mvm: support new flush_sta method
wifi: iwlwifi: mvm: indicate HW decrypt for beacon protection
wifi: iwlwifi: mvm: avoid baid size integer overflow
wifi: iwlwifi: mvm: check only affected links
wifi: iwlwifi: mvm: adjust skip-over-dtim in D3
Miri Korenblit (1):
wifi: iwlwifi: fw: send marker cmd before suspend cmd
Mukesh Sisodiya (1):
wifi: iwlwifi: Add support for new PCI Id
.../net/wireless/intel/iwlwifi/fw/api/scan.h | 28 +++--
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 56 ++++++++-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 2 +
.../net/wireless/intel/iwlwifi/fw/debugfs.c | 22 ----
.../net/wireless/intel/iwlwifi/fw/runtime.h | 6 +-
.../net/wireless/intel/iwlwifi/iwl-config.h | 1 -
.../wireless/intel/iwlwifi/iwl-nvm-parse.c | 22 +++-
.../net/wireless/intel/iwlwifi/iwl-trans.h | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/link.c | 2 +-
.../net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 5 +-
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 38 +++++-
.../wireless/intel/iwlwifi/mvm/mld-mac80211.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +-
.../net/wireless/intel/iwlwifi/mvm/power.c | 7 +-
.../net/wireless/intel/iwlwifi/mvm/rs-fw.c | 15 ++-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 113 +++++++++++++-----
drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 34 ++++--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 11 ++
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 24 ++--
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 5 +-
drivers/net/wireless/intel/iwlwifi/queue/tx.c | 7 ++
24 files changed, 302 insertions(+), 122 deletions(-)
--
2.38.1
From: Johannes Berg <[email protected]>
We can use min_t() for the agg_size and avoid
spelling out the (firmware) limit twice.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index ff1ce990a9d8..3c24b25fe661 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -92,9 +92,8 @@ u32 iwl_mvm_get_sta_ampdu_dens(struct ieee80211_link_sta *link_sta,
IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_MASK);
/* Limit to max A-MPDU supported by FW */
- if (agg_size > (STA_FLG_MAX_AGG_SIZE_4M >> STA_FLG_MAX_AGG_SIZE_SHIFT))
- agg_size = (STA_FLG_MAX_AGG_SIZE_4M >>
- STA_FLG_MAX_AGG_SIZE_SHIFT);
+ agg_size = min_t(u32, agg_size,
+ STA_FLG_MAX_AGG_SIZE_4M >> STA_FLG_MAX_AGG_SIZE_SHIFT);
*_agg_size = agg_size;
return mpdu_dens;
--
2.38.1
From: Johannes Berg <[email protected]>
If a discrete NIC is connected to a PCIe link hat isn't at least
Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
that from EHT capabilities in that case.
While at it, also move setting 320 MHz beamformee to the right
place in the code so it's not set while not supporting 320 MHz.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
---
.../net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 15 +++++++++++----
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 ++++
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 9 +++++++++
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index 39f13518ca5b..8c23f57f5c89 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -680,8 +680,7 @@ static const struct ieee80211_sband_iftype_data iwl_he_eht_capa[] = {
IEEE80211_EHT_PHY_CAP0_BEAMFORMEE_SS_80MHZ_MASK,
.phy_cap_info[1] =
IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_80MHZ_MASK |
- IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_160MHZ_MASK |
- IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK,
+ IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_160MHZ_MASK,
.phy_cap_info[3] =
IEEE80211_EHT_PHY_CAP3_NG_16_SU_FEEDBACK |
IEEE80211_EHT_PHY_CAP3_NG_16_MU_FEEDBACK |
@@ -890,6 +889,10 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
const struct iwl_fw *fw)
{
bool is_ap = iftype_data->types_mask & BIT(NL80211_IFTYPE_AP);
+ bool no_320;
+
+ no_320 = !trans->trans_cfg->integrated &&
+ trans->pcie_link_speed < PCI_EXP_LNKSTA_CLS_8_0GB;
if (!data->sku_cap_11be_enable || iwlwifi_mod_params.disable_11be)
iftype_data->eht_cap.has_eht = false;
@@ -916,8 +919,12 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
IEEE80211_EHT_MAC_CAP0_MAX_MPDU_LEN_MASK);
break;
case NL80211_BAND_6GHZ:
- iftype_data->eht_cap.eht_cap_elem.phy_cap_info[0] |=
- IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ if (!no_320) {
+ iftype_data->eht_cap.eht_cap_elem.phy_cap_info[0] |=
+ IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ iftype_data->eht_cap.eht_cap_elem.phy_cap_info[1] |=
+ IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
+ }
fallthrough;
case NL80211_BAND_5GHZ:
iftype_data->he_cap.he_cap_elem.phy_cap_info[0] |=
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index 1fa035decc03..d02943d0ea62 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@ -1067,6 +1067,8 @@ struct iwl_trans_txqs {
* @iwl_trans_txqs: transport tx queues data.
* @mbx_addr_0_step: step address data 0
* @mbx_addr_1_step: step address data 1
+ * @pcie_link_speed: current PCIe link speed (%PCI_EXP_LNKSTA_CLS_*),
+ * only valid for discrete (not integrated) NICs
*/
struct iwl_trans {
bool csme_own;
@@ -1129,6 +1131,8 @@ struct iwl_trans {
u32 mbx_addr_0_step;
u32 mbx_addr_1_step;
+ u8 pcie_link_speed;
+
/* pointer to trans specific struct */
/*Ensure that this pointer will always be aligned to sizeof pointer */
char trans_specific[] __aligned(sizeof(void *));
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index fcc0f3319bcd..18550c03f870 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1760,6 +1760,15 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
trans_pcie->num_rx_bufs = RX_QUEUE_SIZE;
}
+ if (!iwl_trans->trans_cfg->integrated) {
+ u16 link_status;
+
+ pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &link_status);
+
+ iwl_trans->pcie_link_speed =
+ u16_get_bits(link_status, PCI_EXP_LNKSTA_CLS);
+ }
+
ret = iwl_trans_init(iwl_trans);
if (ret)
goto out_free_trans;
--
2.38.1
From: Johannes Berg <[email protected]>
We've already done the 'decryption' here, so tell
mac80211 it need not do it again.
Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 9dbe71d299ae..8d1e44fd9de7 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -279,7 +279,8 @@ static void iwl_mvm_get_signal_strength(struct iwl_mvm *mvm,
static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *sta,
struct ieee80211_hdr *hdr,
struct iwl_rx_mpdu_desc *desc,
- u32 status)
+ u32 status,
+ struct ieee80211_rx_status *stats)
{
struct iwl_mvm_sta *mvmsta;
struct iwl_mvm_vif *mvmvif;
@@ -308,8 +309,10 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *sta,
/* good cases */
if (likely(status & IWL_RX_MPDU_STATUS_MIC_OK &&
- !(status & IWL_RX_MPDU_STATUS_REPLAY_ERROR)))
+ !(status & IWL_RX_MPDU_STATUS_REPLAY_ERROR))) {
+ stats->flag |= RX_FLAG_DECRYPTED;
return 0;
+ }
if (!sta)
return -1;
@@ -378,7 +381,7 @@ static int iwl_mvm_rx_crypto(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
if (unlikely(ieee80211_is_mgmt(hdr->frame_control) &&
!ieee80211_has_protected(hdr->frame_control)))
- return iwl_mvm_rx_mgmt_prot(sta, hdr, desc, status);
+ return iwl_mvm_rx_mgmt_prot(sta, hdr, desc, status, stats);
if (!ieee80211_has_protected(hdr->frame_control) ||
(status & IWL_RX_MPDU_STATUS_SEC_MASK) ==
--
2.38.1
On 6/20/23 3:03 AM, [email protected] wrote:
> From: Johannes Berg <[email protected]>
>
> If a discrete NIC is connected to a PCIe link hat isn't at least
> Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> that from EHT capabilities in that case.
>
> While at it, also move setting 320 MHz beamformee to the right
> place in the code so it's not set while not supporting 320 MHz.
Is there not an advantage to allowing 320Mhz for longer distance connections
where signal is relatively weak, so over-all tput would easily fit in lesser
pcie bus? Especially on 6E band where the US regdom allows more over-all power
when using wider bandwidths?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
> On 6/20/23 3:03 AM, [email protected] wrote:
> > From: Johannes Berg <[email protected]>
> >
> > If a discrete NIC is connected to a PCIe link hat isn't at least
> > Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> > that from EHT capabilities in that case.
> >
> > While at it, also move setting 320 MHz beamformee to the right
> > place in the code so it's not set while not supporting 320 MHz.
>
> Is there not an advantage to allowing 320Mhz for longer distance connections
> where signal is relatively weak, so over-all tput would easily fit in lesser
> pcie bus? Especially on 6E band where the US regdom allows more over-all power
> when using wider bandwidths?
>
I actually don't know. This surely isn't ideal, but it's the only way to
really force the AP to not send too much than the NIC can pass out, and
it gets unhappy if it can't.
johannes
On Wed, 2023-06-21 at 07:48 -0700, Ben Greear wrote:
> On 6/21/23 4:57 AM, Johannes Berg wrote:
> > On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
> > > On 6/20/23 3:03 AM, [email protected] wrote:
> > > > From: Johannes Berg <[email protected]>
> > > >
> > > > If a discrete NIC is connected to a PCIe link hat isn't at least
> > > > Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> > > > that from EHT capabilities in that case.
> > > >
> > > > While at it, also move setting 320 MHz beamformee to the right
> > > > place in the code so it's not set while not supporting 320 MHz.
> > >
> > > Is there not an advantage to allowing 320Mhz for longer distance connections
> > > where signal is relatively weak, so over-all tput would easily fit in lesser
> > > pcie bus? Especially on 6E band where the US regdom allows more over-all power
> > > when using wider bandwidths?
> > >
> >
> > I actually don't know. This surely isn't ideal, but it's the only way to
> > really force the AP to not send too much than the NIC can pass out, and
> > it gets unhappy if it can't.
>
> So this is to work around hardware/firmware bug in NIC? If so, that should
> be mentioned.
I'm not sure that's really even a _bug_, it just doesn't have a lot of
buffer space inside of it; as far as I know, given how the HW
architecture works, the FW doesn't have a lot of options.
> I have heard in the past that higher bandwidth works better than higher NSS
> in a lot of cases, so if HW/FW can be made to deal with floods in unlikely
> case that the RF is perfect enough to saturate the PCI bus, then I think you
> should allow 320Mhz even on slower PCI bus configurations.
Right. I don't think it's likely that the firmware will do, but hey, I
can let them know :)
johannes
On 6/21/23 4:57 AM, Johannes Berg wrote:
> On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
>> On 6/20/23 3:03 AM, [email protected] wrote:
>>> From: Johannes Berg <[email protected]>
>>>
>>> If a discrete NIC is connected to a PCIe link hat isn't at least
>>> Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
>>> that from EHT capabilities in that case.
>>>
>>> While at it, also move setting 320 MHz beamformee to the right
>>> place in the code so it's not set while not supporting 320 MHz.
>>
>> Is there not an advantage to allowing 320Mhz for longer distance connections
>> where signal is relatively weak, so over-all tput would easily fit in lesser
>> pcie bus? Especially on 6E band where the US regdom allows more over-all power
>> when using wider bandwidths?
>>
>
> I actually don't know. This surely isn't ideal, but it's the only way to
> really force the AP to not send too much than the NIC can pass out, and
> it gets unhappy if it can't.
So this is to work around hardware/firmware bug in NIC? If so, that should
be mentioned.
I have heard in the past that higher bandwidth works better than higher NSS
in a lot of cases, so if HW/FW can be made to deal with floods in unlikely
case that the RF is perfect enough to saturate the PCI bus, then I think you
should allow 320Mhz even on slower PCI bus configurations.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com