* Re: [PATCHv6 2/9] nl80211: Add new netlink attribute for TID speicific retry count
From: Johannes Berg @ 2019-08-21 7:41 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: ath10k, linux-wireless
In-Reply-To: <66f9219ed5bd03f96f23947c2bb6f990@codeaurora.org>
On Sat, 2019-08-10 at 17:36 +0530, Tamizh chelvam wrote:
>
> > > + [NL80211_TID_ATTR_CONFIG_RETRY] = { .type = NLA_FLAG },
> > > + [NL80211_TID_ATTR_CONFIG_RETRY_SHORT] = NLA_POLICY_MIN(NLA_U8, 0),
> > > + [NL80211_TID_ATTR_CONFIG_RETRY_LONG] = NLA_POLICY_MIN(NLA_U8, 0),
> >
> > min of 0 doesn't make sense, maybe you meant 1? otherwise just don't
> > set
> > anything here.
> >
> The min value changed to 0 from 1 as per the previous discussions, since
> this is a retry count and not a tx count.
> Or Shall I remove this min value to avoid the confusion ?
Yeah, I think then you should just remove the min value. Perhaps a max
value is needed, but I don't know.
> > > + tid_conf->retry_short = -1;
> > > +
> >
> > I guess you should document that -1 means no changes? Not sure how the
> > IEEE80211_TID_CONF_RETRY comes in, you're always setting it, so that's
> > useless - better remove that and document that -1 means no changes?
> >
> The value -1 is to notify the driver to use default value by removing
> peer specific retry count.
Oh. So I think that's slightly different, please document that.
johannes
^ permalink raw reply
* Re: [PATCHv6 1/9] nl80211: New netlink command for TID specific configuration
From: Johannes Berg @ 2019-08-21 7:42 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: ath10k, linux-wireless
In-Reply-To: <be096df17632b1a71441a23a373682bf@codeaurora.org>
On Sat, 2019-08-10 at 18:10 +0530, Tamizh chelvam wrote:
> On 2019-07-31 14:55, Johannes Berg wrote:
> > On Tue, 2019-06-18 at 10:57 +0530, Tamizh chelvam wrote:
> > > /**
> > > + * enum nl80211_tid_config - TID config state
> > > + * @NL80211_TID_CONFIG_DEFAULT: Default config for the TID
> > > + * @NL80211_TID_CONFIG_ENABLE: Enable config for the TID
> > > + * NL80211_TID_CONFIG_DISABLE: Disable config for the TID
> > > + */
> > > +enum nl80211_tid_config {
> > > + NL80211_TID_CONFIG_DEFAULT,
> > > + NL80211_TID_CONFIG_ENABLE,
> > > + NL80211_TID_CONFIG_DISABLE,
> > > +};
> >
> > Hmm. Looking at this in more detail in patch 3, I don't understand.
> >
> > How is DEFAULT different from "attribute not present", i.e. "no
> > changes"?
> >
> This DEFAULT is used to notify the driver to use default configuration
> value of driver/vif.
> This will be used when the attribute is not present.
Hm, but then why is it valid in the nl80211 attribute? That seems
confusing. Maybe there should rather be a validity bit somewhere in the
internal API, so the nl82011 API doesn't need to be concerned with this?
johannes
^ permalink raw reply
* Re: [PATCH] `iwlist scan` fails with many networks available
From: Johannes Berg @ 2019-08-21 7:59 UTC (permalink / raw)
To: James Nylen; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <CABVa4Nga1vyvyWNpTTJLa44rZo8wu4-bE=mXX1nZgvzktbSq6A@mail.gmail.com>
On Tue, 2019-08-13 at 00:43 +0000, James Nylen wrote:
> > I suppose we could consider applying a workaround like this if it has a
> > condition checking that the buffer passed in is the maximum possible
> > buffer (65535 bytes, due to iw_point::length being u16)
>
> This is what the latest patch does (attached to my email from
> yesterday / https://lkml.org/lkml/2019/8/10/452 ).
Hmm, yes, you're right. I evidently missed the comparisons to 0xFFFF
there, sorry about that.
> If you'd like to apply it, I'm happy to make any needed revisions.
> Otherwise I'm going to have to keep patching my kernels for this
> issue, unfortunately I don't have the time to try to get wicd to
> migrate to a better solution.
Not sure which would be easier, but ok :-)
Can you please fix the patch to
1) use /* */ style comments (see
https://www.kernel.org/doc/html/latest/process/coding-style.html)
2) remove extra braces (also per coding style)
3) use U16_MAX instead of 0xFFFF
I'd also consider renaming "maybe_current_ev" to "next_ev" or something
shorter anyway, and would probably argue that rewriting this
> + if (IS_ERR(maybe_current_ev)) {
> + err = PTR_ERR(maybe_current_ev);
> + if (err == -E2BIG) {
> + // Last BSS failed to copy into buffer. As
> + // above, only report an error if `iwlist` will
> + // retry again with a larger buffer.
> + if (len >= 0xFFFF) {
> + err = 0;
> + }
> + }
> break;
> + } else {
> + current_ev = maybe_current_ev;
> }
to something like
next_ev = ...
if (IS_ERR(next_ev)) {
err = PTR_ERR(next_ev);
/* mask error and truncate in case buffer cannot be
* increased
*/
if (err == -E2BIG && len < U16_MAX)
err = 0;
break;
}
current_ev = next_ev;
could be more readable, but that's just editorial really.
Thanks,
johannes
^ permalink raw reply
* [PATCH] mt76: add default implementation for mt76_sw_scan/mt76_sw_scan_complete
From: Lorenzo Bianconi @ 2019-08-21 8:00 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka, ryder.lee, royluo
Introduce a default implementation for mt76_sw_scan and
mt76_sw_scan_complete in mt76 module and remove duplicated code
since most of the drivers share the same implementation
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 17 +++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ++++
.../net/wireless/mediatek/mt76/mt7603/main.c | 21 ++-----------------
.../net/wireless/mediatek/mt76/mt7615/main.c | 21 ++-----------------
.../net/wireless/mediatek/mt76/mt76x0/pci.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02.h | 2 --
.../net/wireless/mediatek/mt76/mt76x02_util.c | 9 --------
.../wireless/mediatek/mt76/mt76x2/pci_main.c | 2 +-
.../wireless/mediatek/mt76/mt76x2/usb_main.c | 2 +-
10 files changed, 29 insertions(+), 53 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index ba67b0a55390..532d8576f7ae 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -870,3 +870,20 @@ int mt76_get_rate(struct mt76_dev *dev,
return 0;
}
EXPORT_SYMBOL_GPL(mt76_get_rate);
+
+void mt76_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ const u8 *mac)
+{
+ struct mt76_dev *dev = hw->priv;
+
+ set_bit(MT76_SCANNING, &dev->state);
+}
+EXPORT_SYMBOL_GPL(mt76_sw_scan);
+
+void mt76_sw_scan_complete(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
+{
+ struct mt76_dev *dev = hw->priv;
+
+ clear_bit(MT76_SCANNING, &dev->state);
+}
+EXPORT_SYMBOL_GPL(mt76_sw_scan_complete);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 0668ddb1ccbd..16884ba88af5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -765,6 +765,10 @@ void mt76_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id);
int mt76_get_rate(struct mt76_dev *dev,
struct ieee80211_supported_band *sband,
int idx, bool cck);
+void mt76_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ const u8 *mac);
+void mt76_sw_scan_complete(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif);
/* internal */
void mt76_tx_free(struct mt76_dev *dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 7adf2f8cd2b0..e35c1e4da7ea 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -536,23 +536,6 @@ mt7603_conf_tx(struct ieee80211_hw *hw, struct ieee80211_vif *vif, u16 queue,
return 0;
}
-static void
-mt7603_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- const u8 *mac)
-{
- struct mt7603_dev *dev = hw->priv;
-
- set_bit(MT76_SCANNING, &dev->mt76.state);
-}
-
-static void
-mt7603_sw_scan_complete(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
-{
- struct mt7603_dev *dev = hw->priv;
-
- clear_bit(MT76_SCANNING, &dev->mt76.state);
-}
-
static void
mt7603_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u32 queues, bool drop)
@@ -683,8 +666,8 @@ const struct ieee80211_ops mt7603_ops = {
.sta_state = mt76_sta_state,
.set_key = mt7603_set_key,
.conf_tx = mt7603_conf_tx,
- .sw_scan_start = mt7603_sw_scan,
- .sw_scan_complete = mt7603_sw_scan_complete,
+ .sw_scan_start = mt76_sw_scan,
+ .sw_scan_complete = mt76_sw_scan_complete,
.flush = mt7603_flush,
.ampdu_action = mt7603_ampdu_action,
.get_txpower = mt76_get_txpower,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 0b833c7a21d4..e2a84f717051 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -490,23 +490,6 @@ mt7615_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
-static void
-mt7615_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- const u8 *mac)
-{
- struct mt7615_dev *dev = hw->priv;
-
- set_bit(MT76_SCANNING, &dev->mt76.state);
-}
-
-static void
-mt7615_sw_scan_complete(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
-{
- struct mt7615_dev *dev = hw->priv;
-
- clear_bit(MT76_SCANNING, &dev->mt76.state);
-}
-
const struct ieee80211_ops mt7615_ops = {
.tx = mt7615_tx,
.start = mt7615_start,
@@ -523,8 +506,8 @@ const struct ieee80211_ops mt7615_ops = {
.set_rts_threshold = mt7615_set_rts_threshold,
.wake_tx_queue = mt76_wake_tx_queue,
.sta_rate_tbl_update = mt7615_sta_rate_tbl_update,
- .sw_scan_start = mt7615_sw_scan,
- .sw_scan_complete = mt7615_sw_scan_complete,
+ .sw_scan_start = mt76_sw_scan,
+ .sw_scan_complete = mt76_sw_scan_complete,
.release_buffered_frames = mt76_release_buffered_frames,
.get_txpower = mt76_get_txpower,
.channel_switch_beacon = mt7615_channel_switch_beacon,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index b2ff1fd20162..f84a7df296ea 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -69,7 +69,7 @@ static const struct ieee80211_ops mt76x0e_ops = {
.sta_state = mt76_sta_state,
.set_key = mt76x02_set_key,
.conf_tx = mt76x02_conf_tx,
- .sw_scan_start = mt76x02_sw_scan,
+ .sw_scan_start = mt76_sw_scan,
.sw_scan_complete = mt76x02_sw_scan_complete,
.ampdu_action = mt76x02_ampdu_action,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index a06930bfd75d..c3379db88a1f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -128,7 +128,7 @@ static const struct ieee80211_ops mt76x0u_ops = {
.sta_state = mt76_sta_state,
.set_key = mt76x02_set_key,
.conf_tx = mt76x02_conf_tx,
- .sw_scan_start = mt76x02_sw_scan,
+ .sw_scan_start = mt76_sw_scan,
.sw_scan_complete = mt76x02_sw_scan_complete,
.ampdu_action = mt76x02_ampdu_action,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02.h b/drivers/net/wireless/mediatek/mt76/mt76x02.h
index fb7008562ebf..5d0591b43c36 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02.h
@@ -177,8 +177,6 @@ int mt76x02_tx_prepare_skb(struct mt76_dev *mdev, void *txwi,
enum mt76_txq_id qid, struct mt76_wcid *wcid,
struct ieee80211_sta *sta,
struct mt76_tx_info *tx_info);
-void mt76x02_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- const u8 *mac);
void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
struct ieee80211_vif *vif);
void mt76x02_sta_ps(struct mt76_dev *dev, struct ieee80211_sta *sta, bool ps);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 81d98030fc7a..dbd9d99225ff 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -603,15 +603,6 @@ void mt76x02_remove_hdr_pad(struct sk_buff *skb, int len)
}
EXPORT_SYMBOL_GPL(mt76x02_remove_hdr_pad);
-void mt76x02_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- const u8 *mac)
-{
- struct mt76x02_dev *dev = hw->priv;
-
- set_bit(MT76_SCANNING, &dev->mt76.state);
-}
-EXPORT_SYMBOL_GPL(mt76x02_sw_scan);
-
void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
index 3921d965a106..4971685aafe8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
@@ -165,7 +165,7 @@ const struct ieee80211_ops mt76x2_ops = {
.sta_state = mt76_sta_state,
.set_key = mt76x02_set_key,
.conf_tx = mt76x02_conf_tx,
- .sw_scan_start = mt76x02_sw_scan,
+ .sw_scan_start = mt76_sw_scan,
.sw_scan_complete = mt76x02_sw_scan_complete,
.flush = mt76x2_flush,
.ampdu_action = mt76x02_ampdu_action,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index 1b692fba5a89..eb73cb856c81 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -114,7 +114,7 @@ const struct ieee80211_ops mt76x2u_ops = {
.bss_info_changed = mt76x02_bss_info_changed,
.configure_filter = mt76x02_configure_filter,
.conf_tx = mt76x02_conf_tx,
- .sw_scan_start = mt76x02_sw_scan,
+ .sw_scan_start = mt76_sw_scan,
.sw_scan_complete = mt76x02_sw_scan_complete,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
.get_txpower = mt76_get_txpower,
--
2.21.0
^ permalink raw reply related
* Re: Flag for detecting 802.11r Fast BSS Transition support
From: Johannes Berg @ 2019-08-21 8:03 UTC (permalink / raw)
To: Brian Norris, Matthew Wang; +Cc: linux-wireless, Kirtika Ruchandani
In-Reply-To: <20190403210200.GA93453@google.com>
On Wed, 2019-04-03 at 14:02 -0700, Brian Norris wrote:
> + Johannes
>
> On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> > Hi,
> >
> > I'm wondering if there is a flag for detecting firmware/driver support
> > for FT. It seems like checking for SME support is a pretty good proxy
> > for this, but there is a non-mac80211 driver that can do FT as well
> > (ath/wil6210). It would be great if anyone knows of a feature flag
> > specifically for FT.
>
> I chatted with Johannes, and he agreed that there was no such flag
> today. It also sounded like he was open to adding one, even if it's
> several years too late.
Yeah, well, hindsight is 20/20. I think I've tried to do better in
reviews wrt. feature flags or some other way of discovering it, but I
guess it's never going to be perfect.
Can you submit a patch?
johannes
^ permalink raw reply
* RE: [PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
From: Tony Chuang @ 2019-08-21 8:16 UTC (permalink / raw)
To: Jian-Hong Pan, Kalle Valo, David S . Miller
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com
In-Reply-To: <20190820045934.24841-1-jian-hong@endlessm.com>
Hi,
> From: Jian-Hong Pan [mailto:jian-hong@endlessm.com]
>
> There is a mass of jobs between spin lock and unlock in the hardware
> IRQ which will occupy much time originally. To make system work more
> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> reduce the time in hardware IRQ.
>
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> ---
> v2:
> Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> rtw_pci_interrupt_handler. Because the interrupts are already disabled
> in the hardware interrupt handler.
>
> v3:
> Extend the spin lock protecting area for the TX path in
> rtw_pci_interrupt_threadfn by Realtek's suggestion
>
> drivers/net/wireless/realtek/rtw88/pci.c | 33 +++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index 00ef229552d5..a8c17a01f318 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> void *dev)
> {
> struct rtw_dev *rtwdev = dev;
> struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> - u32 irq_status[4];
>
> spin_lock(&rtwpci->irq_lock);
> if (!rtwpci->irq_enabled)
> goto out;
>
> + /* disable RTW PCI interrupt to avoid more interrupts before the end of
> + * thread function
> + */
> + rtw_pci_disable_interrupt(rtwdev, rtwpci);
> +out:
> + spin_unlock(&rtwpci->irq_lock);
> +
> + return IRQ_WAKE_THREAD;
> +}
> +
> +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> +{
> + struct rtw_dev *rtwdev = dev;
> + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> + unsigned long flags;
> + u32 irq_status[4];
> +
> + spin_lock_irqsave(&rtwpci->irq_lock, flags);
> rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
>
> if (irq_status[0] & IMR_MGNTDOK)
> @@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> void *dev)
> if (irq_status[0] & IMR_ROK)
> rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
>
> -out:
> - spin_unlock(&rtwpci->irq_lock);
> + /* all of the jobs for this interrupt have been done */
> + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> + rtw_pci_enable_interrupt(rtwdev, rtwpci);
I've applied this patch and tested it.
But I failed to connect to AP, it seems that the
scan_result is empty. And when I failed to connect
to the AP, I found that the IMR is not enabled.
I guess the check bypass the interrupt enable function.
And I also found that *without MSI*, the driver is
able to connect to the AP. Could you please verify
this patch again with MSI interrupt enabled and
send a v4?
You can find my MSI patch on
https://patchwork.kernel.org/patch/11081539/
> + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
>
> return IRQ_HANDLED;
> }
> @@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
> goto err_destroy_pci;
> }
>
> - ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
> - IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> + ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
> + rtw_pci_interrupt_handler,
> + rtw_pci_interrupt_threadfn,
> + IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> if (ret) {
> ieee80211_unregister_hw(hw);
> goto err_destroy_pci;
> @@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
> rtw_pci_disable_interrupt(rtwdev, rtwpci);
> rtw_pci_destroy(rtwdev, pdev);
> rtw_pci_declaim(rtwdev, pdev);
> - free_irq(rtwpci->pdev->irq, rtwdev);
> + devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
> rtw_core_deinit(rtwdev);
> ieee80211_free_hw(hw);
> }
> --
NACK
Need to verify it with MSI https://patchwork.kernel.org/patch/11081539/
And hope v4 could fix it.
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 1/1] rt2x00: Queue flush fix
From: Stanislaw Gruszka @ 2019-08-21 8:34 UTC (permalink / raw)
To: Balakrishna Bandi; +Cc: kvalo, linux-wireless
In-Reply-To: <1566339185-11875-1-git-send-email-b.balakrishna@globaledgesoft.com>
On Wed, Aug 21, 2019 at 03:43:05AM +0530, Balakrishna Bandi wrote:
> Added rt2x00 queue flush fix and beacon frames checks.
Please post separate patch for each issue and provide
more descriptive information about the changes, especially
what problems are intended to solve.
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
> index 110bb39..9964371 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
> @@ -566,7 +566,7 @@ void rt2800mmio_queue_init(struct data_queue *queue)
>
> switch (queue->qid) {
> case QID_RX:
> - queue->limit = 128;
> + queue->limit = 512;
How this is related with flush or beaconing ?
At this point of rt2x00 driver development I'm pretty reluctant to
increase queue size. But maybe we can do this for some particular
chip if things were tested on this chip and improve or fix something.
> if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
> goto exit_free_skb;
> + /* Dirty hack for queue overrun protection,
> + * if AC_VO/AC_VI/AC_BE is full, use next queue.
> + * if AC_BK is full use previous queue.
> + */
No dirty hacks please.
> void rt2x00queue_flush_queue(struct data_queue *queue, bool drop)
> {
> + unsigned int i;
> + bool started;
> bool tx_queue =
> (queue->qid == QID_AC_VO) ||
> (queue->qid == QID_AC_VI) ||
> (queue->qid == QID_AC_BE) ||
> (queue->qid == QID_AC_BK);
> + mutex_lock(&queue->status_lock);
> + /* If the queue has been started, we must stop it temporarily
> + * to prevent any new frames to be queued on the device. If
> + * we are not dropping the pending frames, the queue must
> + * only be stopped in the software and not the hardware,
> + * otherwise the queue will never become empty on its own.
> + */
Since linux 5.2 there is rework done on related area. So maybe flush
issue you are trying to fix by this patch is already fixed. If not let
me know and provide description what is the problem.
> Disclaimer:- The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. The views expressed in this E-mail message (including the enclosure/(s) or attachment/(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of GlobalEdge. Before opening any mail and attachments please check them for viruses .GlobalEdge does not accept any liability for virus infected mails.
>
You should not sent this disclaimer to open mailing list.
Fix this or use different email service to post patches.
Stanislaw
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Stanislaw Gruszka @ 2019-08-21 8:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Lorenzo Bianconi, linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <20190820112438.GA2227@redhat.com>
On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
> > Can you test if disabling hw encryption only for shared or only for
> > pairwise keys makes any difference?
>
> Disabling only pairwise keys helps. Disabling only shared keys does
> not help.
>
> Not sure if this will be helpful information or make things more
> confusing, but seems the difference between mt76_txq_schedule()
> and tasklet_schedule() in mt76_wake_tx_queue() is that on
> mt76_txq_schedule() some tx packets are serialized by dev->rx_lock
> (because some ARP and TCP packets are sent via network stack as response
> of incoming packet within ieee80211_rx_napi() call). Removing
> spin_lock(&dev->rx_lock) in mt76_rx_complete() make the problem
> reproducible again with mt76_txq_schedule() & HW encryption.
So, I think this is FW/HW issue related with encryption and ordering
and we should apply patch originally posted in this thread that
disable HW encryption for MT7630E.
I do not think we should disable HW encryption only for pairwise keys,
because FW/HW can have the same bug for shared keys, but is not
triggered in my test, as we do not sent lot of group frames.
Stanislaw
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Felix Fietkau @ 2019-08-21 9:03 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <20190821084724.GB20223@redhat.com>
On 2019-08-21 10:47, Stanislaw Gruszka wrote:
> On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
>> > Can you test if disabling hw encryption only for shared or only for
>> > pairwise keys makes any difference?
>>
>> Disabling only pairwise keys helps. Disabling only shared keys does
>> not help.
>>
>> Not sure if this will be helpful information or make things more
>> confusing, but seems the difference between mt76_txq_schedule()
>> and tasklet_schedule() in mt76_wake_tx_queue() is that on
>> mt76_txq_schedule() some tx packets are serialized by dev->rx_lock
>> (because some ARP and TCP packets are sent via network stack as response
>> of incoming packet within ieee80211_rx_napi() call). Removing
>> spin_lock(&dev->rx_lock) in mt76_rx_complete() make the problem
>> reproducible again with mt76_txq_schedule() & HW encryption.
>
> So, I think this is FW/HW issue related with encryption and ordering
> and we should apply patch originally posted in this thread that
> disable HW encryption for MT7630E.
>
> I do not think we should disable HW encryption only for pairwise keys,
> because FW/HW can have the same bug for shared keys, but is not
> triggered in my test, as we do not sent lot of group frames.
I'm still not convinced that this is just the hardware implementation of
hw crypto being faulty. I think it's more likely that there's a bug in
the tx path somewhere, which causes hangs on MT7630E but remains hidden
(or at least recoverable) on other devices.
I'm currently reviewing key handling in the mac80211 fast-xmit codepath
and get the feeling that something might be racy there.
I will let you know when I make some progress with that review.
If we can't find the bug soon, then I'm fine with merging this patch.
Right now, I would like to see first if we can fix it properly.
- Felix
^ permalink raw reply
* Re: [PATCH 04/49] ath11k: add ahb.c
From: Vasanthakumar Thiagarajan @ 2019-08-21 9:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, linux-wireless, ath11k, devicetree,
linux-wireless-owner
In-Reply-To: <8c791df54a831f32fddd634e71e5e91342532535.camel@sipsolutions.net>
On 2019-08-21 01:35, Johannes Berg wrote:
Thanks for the comments!
> On Tue, 2019-08-20 at 18:47 +0300, Kalle Valo wrote:
>>
>> +static const struct service_to_pipe target_service_to_ce_map_wlan[] =
>> {
>> + {
>> + __cpu_to_le32(ATH11K_HTC_SVC_ID_WMI_DATA_VO),
>> + __cpu_to_le32(PIPEDIR_OUT), /* out = UL = host -> target */
>> + __cpu_to_le32(3),
>> + },
>
> this might be nicer as C99 initializers as well? It's a struct of some
> sort, after all.
Sure.
>
>> + { /* must be last */
>> + __cpu_to_le32(0),
>> + __cpu_to_le32(0),
>> + __cpu_to_le32(0),
>> + },
>
> You don't need endian conversion for 0, even sparse will not complain,
> but I'd argue it should anyway be something like
>
> { /* terminator entry */ }
>
> since that's why it's there I guess?
Ok.
>
>> +#define ATH11K_TX_RING_MASK_3 0x0
>
> You have a LOT of masks here that are 0, that seems odd?
We'll remove them.
>
>> +/* enum ext_irq_num - irq nubers that can be used by external modules
>
> typo ("numbers")
>
>> +inline u32 ath11k_ahb_read32(struct ath11k_base *ab, u32 offset)
>> +{
>> + return ioread32(ab->mem + offset);
>> +}
>> +
>> +inline void ath11k_ahb_write32(struct ath11k_base *ab, u32 offset,
>> u32 value)
>> +{
>> + iowrite32(value, ab->mem + offset);
>> +}
>
> Just "inline" doesn't seem to make that much sense? If it's only used
> here then I guess it should be static, otherwise not inline? Or maybe
> you want it to be inlined *in this file* but available out-of-line
> otherwise? I'm not sure that actually is guaranteed to work right in C?
Yes, these read/write functions are used from other files as well. May
be define
them as static inline in ahb.c will be fine.
>
>> + val = ath11k_ahb_read32(ab, CE_HOST_IE_ADDRESS);
>> + val |= BIT(ce_id);
>> + ath11k_ahb_write32(ab, CE_HOST_IE_ADDRESS, val);
>
> You could perhaps benefit from ath11k_ahb_setbit32() or something like
> that, this repeats a few times?
>
>> + if (__le32_to_cpu(ce_config->pipedir) & PIPEDIR_OUT) {
>> + val = ath11k_ahb_read32(ab, CE_HOST_IE_ADDRESS);
>> + val &= ~BIT(ce_id);
>> + ath11k_ahb_write32(ab, CE_HOST_IE_ADDRESS, val);
>
> and clearbit32() maybe. Dunno, I saw only 3 instances of each here I
> guess, but still, feels repetitive.
Sure.
>
>> +int ath11k_ahb_start(struct ath11k_base *ab)
>> +{
>> + ath11k_ahb_ce_irqs_enable(ab);
>> + ath11k_ce_rx_post_buf(ab);
>> +
>> + /* Bring up other components as appropriate */
>
> Hmm. What would be appropriate? It's not really doing anything else?
These comments added during development not to miss anything during
bring up. Now it is not really needed, we'll remove them.
>
>> +void ath11k_ahb_stop(struct ath11k_base *ab)
>> +{
>> + if (!test_bit(ATH11K_FLAG_CRASH_FLUSH, &ab->dev_flags))
>> + ath11k_ahb_ce_irqs_disable(ab);
>> + ath11k_ahb_sync_ce_irqs(ab);
>> + ath11k_ahb_kill_tasklets(ab);
>> + del_timer_sync(&ab->rx_replenish_retry);
>> + ath11k_ce_cleanup_pipes(ab);
>> + /* Shutdown other components as appropriate */
>
> likewise, it's not doing anything else?
>
Sure. Thanks.
Vasanth
^ permalink raw reply
* Re: [PATCH 04/49] ath11k: add ahb.c
From: Johannes Berg @ 2019-08-21 9:40 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Kalle Valo, linux-wireless, ath11k, devicetree,
linux-wireless-owner
In-Reply-To: <e53ddcaa11d069fbe9d083b9b0105d19@codeaurora.org>
On Wed, 2019-08-21 at 14:59 +0530, Vasanthakumar Thiagarajan wrote:
> > > +#define ATH11K_TX_RING_MASK_3 0x0
> >
> > You have a LOT of masks here that are 0, that seems odd?
>
> We'll remove them.
I'm not sure you should just *remove* them, that might very well be
valid and what you need here, I'm just saying it looks odd since you
usually expect masks to, well, not really mask *everything*?
> > > +inline u32 ath11k_ahb_read32(struct ath11k_base *ab, u32 offset)
> > > +{
> > > + return ioread32(ab->mem + offset);
> > > +}
> > > +
> > > +inline void ath11k_ahb_write32(struct ath11k_base *ab, u32 offset,
> > > u32 value)
> > > +{
> > > + iowrite32(value, ab->mem + offset);
> > > +}
> >
> > Just "inline" doesn't seem to make that much sense? If it's only used
> > here then I guess it should be static, otherwise not inline? Or maybe
> > you want it to be inlined *in this file* but available out-of-line
> > otherwise? I'm not sure that actually is guaranteed to work right in C?
>
> Yes, these read/write functions are used from other files as well. May
> be define them as static inline in ahb.c will be fine.
No, if they're static they cannot be used from other files, but if
they're declared and used elsewhere they can't really be inline ...
You could declare them static inline in ahb.h I guess, instead.
johannes
^ permalink raw reply
* Re: [PATCH 06/49] ath11k: add ce.c
From: Vasanthakumar Thiagarajan @ 2019-08-21 9:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: Kalle Valo, linux-wireless, devicetree, ath11k
In-Reply-To: <54d8d4600d53bac855b19a26fa744ed16be09bf0.camel@sipsolutions.net>
On 2019-08-21 01:53, Johannes Berg wrote:
> On Tue, 2019-08-20 at 18:47 +0300, Kalle Valo wrote:
>> +static const struct ce_attr host_ce_config_wlan[] = {
>> + /* CE0: host->target HTC control and raw streams */
>> + {
>> + .flags = CE_ATTR_FLAGS,
>> + .src_nentries = 16,
>> + .src_sz_max = 2048,
>> + .dest_nentries = 0,
>> + },
>>
> Curious - this looks a lot like a similar thing in AHB, but there you
> did it all in little endian? Totally different really, just looks
> similar, or what's the reason?
This particular table is for the driver use only. This has Copy Engine
configurations
and any Copy Engine specific send/receive callbacks. The other in ahb.c
is the configuration
sent to firmware.
>
>> + ring->skb[write_index] = skb;
>> + write_index = CE_RING_IDX_INCR(nentries_mask, write_index);
>> + ring->write_index = write_index;
>> +
>> + ath11k_hal_srng_access_end(ab, srng);
>> +
>> + spin_unlock_bh(&srng->lock);
>> +
>> + pipe->rx_buf_needed--;
>> +
>> + return 0;
>> +
>> +err:
>> + ath11k_hal_srng_access_end(ab, srng);
>> +
>> + spin_unlock_bh(&srng->lock);
>
> Seems like you could unify those unlock paths, the rx_buf_needed-- can
> almost certainly be before the access_end/unlock, and then just set
> ret=0?
Sure.
>
>> +static int ath11k_ce_completed_send_next(struct ath11k_ce_pipe *pipe,
>> + struct sk_buff **skb)
>
> Personally, I'd have preferred to have the *skb as the return value,
> and
> use ERR_PTR()/IS_ERR() etc. to encode the error values, rather than the
> double pointer.
Ok.
>
>> +{
>> + struct ath11k_base *ab = pipe->ab;
>> + struct hal_srng *srng;
>> + unsigned int sw_index;
>> + unsigned int nentries_mask;
>> + u32 *desc;
>> + int ret = 0;
>
> Maybe don't initialize that to a success value, just for robustness?
> You
> don't actually need to initialize it at all though if you set ret=0
> when
> you actually succeed, which might be even nicer given that the function
> is simple enough for the compiler to figure out if you used 'ret'
> uninitialized or not.
Ok.
>
>> +static struct ath11k_ce_ring *
>> +ath11k_ce_alloc_ring(struct ath11k_base *ab, int nentries, int
>> desc_sz)
>> +{
>> + struct ath11k_ce_ring *ce_ring;
>> + dma_addr_t base_addr;
>> +
>> + ce_ring = kzalloc(sizeof(*ce_ring) + (nentries *
>> sizeof(*ce_ring->skb)),
>> + GFP_KERNEL);
>
> You should probably use struct_size().
Sure.
Thanks.
Vasanth
^ permalink raw reply
* pull-request: mac80211 2019-08-21
From: Johannes Berg @ 2019-08-21 10:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
I have here for you a few fixes; three, to be specific. Nothing that
warrants real discussion or urgency though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit a1c4cd67840ef80f6ca5f73326fa9a6719303a95:
net: fix __ip_mc_inc_group usage (2019-08-20 12:48:06 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-08-21
for you to fetch changes up to 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb:
Revert "cfg80211: fix processing world regdomain when non modular" (2019-08-21 10:43:03 +0200)
----------------------------------------------------------------
Just three fixes:
* extended key ID key installation
* regulatory processing
* possible memory leak in an error path
----------------------------------------------------------------
Alexander Wetzel (1):
cfg80211: Fix Extended Key ID key install checks
Hodaszi, Robert (1):
Revert "cfg80211: fix processing world regdomain when non modular"
Johannes Berg (1):
mac80211: fix possible sta leak
net/mac80211/cfg.c | 9 +++++----
net/wireless/reg.c | 2 +-
net/wireless/util.c | 23 ++++++++++++++---------
3 files changed, 20 insertions(+), 14 deletions(-)
^ permalink raw reply
* RE: [PATCH 2/7] ath10k: change max RX bundle size from 8 to 32 for sdio
From: Toke Høiland-Jørgensen @ 2019-08-21 10:02 UTC (permalink / raw)
To: Wen Gong, Wen Gong, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <59f668bda688419e9b6f44587d391135@aptaiexm02f.ap.qualcomm.com>
Wen Gong <wgong@qti.qualcomm.com> writes:
>> -----Original Message-----
>> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Toke
>> Høiland-Jørgensen
>> Sent: Tuesday, August 20, 2019 8:23 PM
>> To: Wen Gong <wgong@codeaurora.org>; ath10k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [EXT] Re: [PATCH 2/7] ath10k: change max RX bundle size from 8 to
>> 32 for sdio
>>
>> Wen Gong <wgong@codeaurora.org> writes:
>>
>> > The max bundle size support by firmware is 32, change it from 8 to 32
>> > will help performance. This results in significant performance
>> > improvement on RX path.
>>
>> What happens when the hardware doesn't have enough data to fill a
>> bundle? Does it send a smaller one, or does it wait until it can fill
>> it?
>>
>
> The bundle is filled by firmware.
> It will not wait until it can fill it.
> For example, if you do ping per second, it will have only 1 ping packet
> In the bundle.
Right, cool.
-Toke
^ permalink raw reply
* pull-request: mac80211-next 2019-08-21
From: Johannes Berg @ 2019-08-21 10:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
For -next, we have more changes, but as described in the tag
they really just fall into a few groups of changes :-)
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8c40f3b212a373be843a29db608b462af5c3ed5d:
Merge tag 'mlx5-updates-2019-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2019-08-20 22:59:45 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-08-21
for you to fetch changes up to 48cb39522a9d4d4680865e40a88f975a1cee6abc:
mac80211: minstrel_ht: improve rate probing for devices with static fallback (2019-08-21 11:10:13 +0200)
----------------------------------------------------------------
Here are a few groups of changes:
* EDMG channel support (60 GHz, just a single patch)
* initial 6/7 GHz band support (Arend)
* association timestamp recording (Ben)
* rate control improvements for better performance with
the mt76 driver (Felix)
* various fixes for previous HE support changes (John)
----------------------------------------------------------------
Alexei Avshalom Lazar (1):
nl80211: Add support for EDMG channels
Arend van Spriel (8):
nl80211: add 6GHz band definition to enum nl80211_band
cfg80211: add 6GHz UNII band definitions
cfg80211: util: add 6GHz channel to freq conversion and vice versa
cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries
cfg80211: use same IR permissive rules for 6GHz band
cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
cfg80211: apply same mandatory rate flags for 5GHz and 6GHz
Ben Greear (2):
cfg80211: Support assoc-at timer in sta-info
mac80211: add assoc-at support
Felix Fietkau (4):
mac80211: minstrel_ht: fix per-group max throughput rate initialization
mac80211: minstrel_ht: reduce unnecessary rate probing attempts
mac80211: minstrel_ht: fix default max throughput rate indexes
mac80211: minstrel_ht: improve rate probing for devices with static fallback
John Crispin (5):
mac80211: fix TX legacy rate reporting when tx_status_ext is used
mac80211: fix bad guard when reporting legacy rates
mac80211: 80Mhz was not reported properly when using tx_status_ext
mac80211: add missing length field increment when generating Radiotap header
mac80211: fix possible NULL pointerderef in obss pd code
drivers/net/wireless/ath/wil6210/cfg80211.c | 2 +-
include/net/cfg80211.h | 88 ++++++++-
include/uapi/linux/nl80211.h | 29 +++
net/mac80211/he.c | 3 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/rc80211_minstrel.h | 1 +
net/mac80211/rc80211_minstrel_ht.c | 277 ++++++++++++++++++++++++----
net/mac80211/rc80211_minstrel_ht.h | 12 ++
net/mac80211/sta_info.c | 3 +
net/mac80211/sta_info.h | 2 +
net/mac80211/status.c | 31 ++--
net/mac80211/tx.c | 1 +
net/wireless/chan.c | 162 +++++++++++++++-
net/wireless/ibss.c | 16 +-
net/wireless/nl80211.c | 39 ++++
net/wireless/reg.c | 21 ++-
net/wireless/trace.h | 3 +-
net/wireless/util.c | 56 +++++-
18 files changed, 684 insertions(+), 64 deletions(-)
^ permalink raw reply
* Re: [PATCH 31/49] ath11k: add mac.c
From: Toke Høiland-Jørgensen @ 2019-08-21 10:08 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Kalle Valo, linux-wireless, ath11k, devicetree,
linux-wireless-owner
In-Reply-To: <ac6e7dbbd53e7ba9e82e49baca22b73c@codeaurora.org>
Vasanthakumar Thiagarajan <vthiagar@codeaurora.org> writes:
> On 2019-08-20 22:21, Toke Høiland-Jørgensen wrote:
>> [... snip ... ]
>>
>>> +static const struct ieee80211_ops ath11k_ops = {
>>> + .tx = ath11k_mac_op_tx,
>>
>> No wake_tx_queue? :(
>
> Yes, packet queueing is handled in firmware. This makes sense
> especially when we enable 802.11 encap offload support where most of
> the data path processing in mac80211 will be skipped and packet is
> given to driver/firmware in 802.3 format itself. Then firmware would
> take care of all the classification, queueing and encapsulation
> operations.
Well, so does ath10k, and yet we still saw a significant improvement by
moving queueing back into the host where it can be handled by the
FQ-CoDel-enabled queueing structure.
So, *how* does the firmware handle the queueing? Does it have
per-stations queues? Per-flow queues? What's the latency under load
figures for the firmware queues?
-Toke
^ permalink raw reply
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Toke Høiland-Jørgensen @ 2019-08-21 10:10 UTC (permalink / raw)
To: Wen Gong, Wen Gong, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <00992d0991704b0fae73a500bb2eb504@aptaiexm02f.ap.qualcomm.com>
Wen Gong <wgong@qti.qualcomm.com> writes:
>> -----Original Message-----
>> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Toke
>> Høiland-Jørgensen
>> Sent: Tuesday, August 20, 2019 8:24 PM
>> To: Wen Gong <wgong@codeaurora.org>; ath10k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of htt
>> for sdio
>>
>> Wen Gong <wgong@codeaurora.org> writes:
>>
>> > Tx complete message from firmware cost bus bandwidth of sdio, and bus
>> > bandwidth is the bollteneck of throughput, it will effect the bandwidth
>> > occupancy of data packet of TX and RX.
>> >
>> > This patch disable TX complete indication from firmware for htt data
>> > packet, it results in significant performance improvement on TX path.
>>
>> Wait, how does that work? Am I understanding it correctly that this
>> replaces a per-packet TX completion with a periodic one sent out of
>> band?
> When this patch applied, firmware will not indicate tx complete for tx
> Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
> This htt msg will tell how many data tx complete without status(status maybe success/fail).
Ah, so this is basically a counter of how much data is currently queued
in the firmware?
>> And could you explain what the credits thing is for, please? :)
> For high latency bus chip, all the tx data's content(include ip/udp/tcp header
> and payload) will be transfer to firmware's memory via bus.
> And firmware has limited memory for tx data, the tx data's content must
> Saved in firmware memory before it tx complete, if ath10k transfer tx
> data more than the limit, firmware will occur error. The credit is used
> to avoid ath10k exceed the limit.
What's a typical limit in the firmware?
-Toke
^ permalink raw reply
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Wen Gong @ 2019-08-21 10:20 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Wen Gong,
ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <8736husub0.fsf@toke.dk>
> -----Original Message-----
> From: Toke Høiland-Jørgensen <toke@redhat.com>
> Sent: Wednesday, August 21, 2019 6:10 PM
> To: Wen Gong <wgong@qti.qualcomm.com>; Wen Gong
> <wgong@codeaurora.org>; ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
> for sdio
>
> Wen Gong <wgong@qti.qualcomm.com> writes:
>
> >> -----Original Message-----
> >> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Toke
> >> Høiland-Jørgensen
> >> Sent: Tuesday, August 20, 2019 8:24 PM
> >> To: Wen Gong <wgong@codeaurora.org>; ath10k@lists.infradead.org
> >> Cc: linux-wireless@vger.kernel.org
> >> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of
> htt
> > When this patch applied, firmware will not indicate tx complete for tx
> > Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
> > This htt msg will tell how many data tx complete without status(status
> maybe success/fail).
>
> Ah, so this is basically a counter of how much data is currently queued
> in the firmware?
Yes.
>
> >> And could you explain what the credits thing is for, please? :)
> > For high latency bus chip, all the tx data's content(include ip/udp/tcp
> header
> > and payload) will be transfer to firmware's memory via bus.
> > And firmware has limited memory for tx data, the tx data's content must
> > Saved in firmware memory before it tx complete, if ath10k transfer tx
> > data more than the limit, firmware will occur error. The credit is used
> > to avoid ath10k exceed the limit.
>
> What's a typical limit in the firmware?
It is 96 data packet in my test. It can changed in firmware code.
>
> -Toke
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Felix Fietkau @ 2019-08-21 10:40 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <433c1d1f-3590-375f-ed8d-c9de2af873d5@nbd.name>
On 2019-08-21 11:03, Felix Fietkau wrote:
> On 2019-08-21 10:47, Stanislaw Gruszka wrote:
>> On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
>>> > Can you test if disabling hw encryption only for shared or only for
>>> > pairwise keys makes any difference?
>>>
>>> Disabling only pairwise keys helps. Disabling only shared keys does
>>> not help.
>>>
>>> Not sure if this will be helpful information or make things more
>>> confusing, but seems the difference between mt76_txq_schedule()
>>> and tasklet_schedule() in mt76_wake_tx_queue() is that on
>>> mt76_txq_schedule() some tx packets are serialized by dev->rx_lock
>>> (because some ARP and TCP packets are sent via network stack as response
>>> of incoming packet within ieee80211_rx_napi() call). Removing
>>> spin_lock(&dev->rx_lock) in mt76_rx_complete() make the problem
>>> reproducible again with mt76_txq_schedule() & HW encryption.
>>
>> So, I think this is FW/HW issue related with encryption and ordering
>> and we should apply patch originally posted in this thread that
>> disable HW encryption for MT7630E.
>>
>> I do not think we should disable HW encryption only for pairwise keys,
>> because FW/HW can have the same bug for shared keys, but is not
>> triggered in my test, as we do not sent lot of group frames.
> I'm still not convinced that this is just the hardware implementation of
> hw crypto being faulty. I think it's more likely that there's a bug in
> the tx path somewhere, which causes hangs on MT7630E but remains hidden
> (or at least recoverable) on other devices.
> I'm currently reviewing key handling in the mac80211 fast-xmit codepath
> and get the feeling that something might be racy there.
> I will let you know when I make some progress with that review.
> If we can't find the bug soon, then I'm fine with merging this patch.
> Right now, I would like to see first if we can fix it properly.
Another question: Does a watchdog restart happen before tx fails?
- Felix
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Stanislaw Gruszka @ 2019-08-21 11:22 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Lorenzo Bianconi, linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <876a4137-ecd5-2e6c-0c75-87eae895e672@nbd.name>
On Wed, Aug 21, 2019 at 12:40:14PM +0200, Felix Fietkau wrote:
> On 2019-08-21 11:03, Felix Fietkau wrote:
> > On 2019-08-21 10:47, Stanislaw Gruszka wrote:
> >> On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
> >>> > Can you test if disabling hw encryption only for shared or only for
> >>> > pairwise keys makes any difference?
> >>>
> >>> Disabling only pairwise keys helps. Disabling only shared keys does
> >>> not help.
> >>>
> >>> Not sure if this will be helpful information or make things more
> >>> confusing, but seems the difference between mt76_txq_schedule()
> >>> and tasklet_schedule() in mt76_wake_tx_queue() is that on
> >>> mt76_txq_schedule() some tx packets are serialized by dev->rx_lock
> >>> (because some ARP and TCP packets are sent via network stack as response
> >>> of incoming packet within ieee80211_rx_napi() call). Removing
> >>> spin_lock(&dev->rx_lock) in mt76_rx_complete() make the problem
> >>> reproducible again with mt76_txq_schedule() & HW encryption.
> >>
> >> So, I think this is FW/HW issue related with encryption and ordering
> >> and we should apply patch originally posted in this thread that
> >> disable HW encryption for MT7630E.
> >>
> >> I do not think we should disable HW encryption only for pairwise keys,
> >> because FW/HW can have the same bug for shared keys, but is not
> >> triggered in my test, as we do not sent lot of group frames.
> > I'm still not convinced that this is just the hardware implementation of
> > hw crypto being faulty. I think it's more likely that there's a bug in
> > the tx path somewhere, which causes hangs on MT7630E but remains hidden
> > (or at least recoverable) on other devices.
> > I'm currently reviewing key handling in the mac80211 fast-xmit codepath
> > and get the feeling that something might be racy there.
> > I will let you know when I make some progress with that review.
> > If we can't find the bug soon, then I'm fine with merging this patch.
> > Right now, I would like to see first if we can fix it properly.
> Another question: Does a watchdog restart happen before tx fails?
No, we do not run wdt_work for mt76x0e.
Stanislaw
^ permalink raw reply
* Re: [PATCH v2] mt76: fix some checkpatch warnings
From: Joe Perches @ 2019-08-21 11:59 UTC (permalink / raw)
To: Ryder Lee, Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, linux-wireless,
linux-mediatek, linux-kernel
In-Reply-To: <4ff1174b111ab61e147510ffbcde706d1a00600d.1566356513.git.ryder.lee@mediatek.com>
On Wed, 2019-08-21 at 11:11 +0800, Ryder Lee wrote:
> This fixes the following checkpatch warnings:
> CHECK: Alignment should match open parenthesis
> CHECK: No space is necessary after a cast
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> Changes since v2: remove false positive checkpatch warnings.
What were those?
> diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
[]
> @@ -587,8 +589,8 @@ mt76_check_sta(struct mt76_dev *dev, struct sk_buff *skb)
> }
>
> if (ieee80211_has_morefrags(hdr->frame_control) ||
> - !(ieee80211_is_mgmt(hdr->frame_control) ||
> - ieee80211_is_data(hdr->frame_control)))
> + !(ieee80211_is_mgmt(hdr->frame_control) ||
> + ieee80211_is_data(hdr->frame_control)))
Poor alignment here.
This should be:
if (ieee80211_has_morefrags(hdr->frame_control) ||
!(ieee80211_is_mgmt(hdr->frame_control) ||
ieee80211_is_data(hdr->frame_control)))
^ permalink raw reply
* [PATCH v5.3] iwlwifi: pcie: handle switching killer Qu B0 NICs to C0
From: Luca Coelho @ 2019-08-21 12:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
From: Luca Coelho <luciano.coelho@intel.com>
We need to use a different firmware for C0 versions of killer Qu NICs.
Add structures for them and handle them in the if block that detects
C0 revisions.
Additionally, instead of having an inclusive check for QnJ devices,
make the selection exclusive, so that switching to QnJ is the
exception, not the default. This prevents us from having to add all
the non-QnJ cards to an exclusion list. To do so, only go into the
QnJ block if the device has an RF ID type HR and HW revision QnJ.
Cc: stable@vger.kernel.org # 5.2
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../net/wireless/intel/iwlwifi/cfg/22000.c | 24 ++++++++++++++++
.../net/wireless/intel/iwlwifi/iwl-config.h | 2 ++
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 28 +++++++++++--------
.../net/wireless/intel/iwlwifi/pcie/trans.c | 7 +----
4 files changed, 43 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/22000.c b/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
index 1f500cddb3a7..55b713255b8e 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
@@ -556,6 +556,30 @@ const struct iwl_cfg killer1650i_2ax_cfg_qu_b0_hr_b0 = {
.max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
};
+const struct iwl_cfg killer1650s_2ax_cfg_qu_c0_hr_b0 = {
+ .name = "Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)",
+ .fw_name_pre = IWL_QU_C_HR_B_FW_PRE,
+ IWL_DEVICE_22500,
+ /*
+ * This device doesn't support receiving BlockAck with a large bitmap
+ * so we need to restrict the size of transmitted aggregation to the
+ * HT size; mac80211 would otherwise pick the HE max (256) by default.
+ */
+ .max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
+};
+
+const struct iwl_cfg killer1650i_2ax_cfg_qu_c0_hr_b0 = {
+ .name = "Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201D2W)",
+ .fw_name_pre = IWL_QU_C_HR_B_FW_PRE,
+ IWL_DEVICE_22500,
+ /*
+ * This device doesn't support receiving BlockAck with a large bitmap
+ * so we need to restrict the size of transmitted aggregation to the
+ * HT size; mac80211 would otherwise pick the HE max (256) by default.
+ */
+ .max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
+};
+
const struct iwl_cfg iwl22000_2ax_cfg_jf = {
.name = "Intel(R) Dual Band Wireless AX 22000",
.fw_name_pre = IWL_QU_B_JF_B_FW_PRE,
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-config.h b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
index 1c1bf1b281cd..6c04f8223aff 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
@@ -577,6 +577,8 @@ extern const struct iwl_cfg iwl_ax1650i_cfg_quz_hr;
extern const struct iwl_cfg iwl_ax1650s_cfg_quz_hr;
extern const struct iwl_cfg killer1650s_2ax_cfg_qu_b0_hr_b0;
extern const struct iwl_cfg killer1650i_2ax_cfg_qu_b0_hr_b0;
+extern const struct iwl_cfg killer1650s_2ax_cfg_qu_c0_hr_b0;
+extern const struct iwl_cfg killer1650i_2ax_cfg_qu_c0_hr_b0;
extern const struct iwl_cfg killer1650x_2ax_cfg;
extern const struct iwl_cfg killer1650w_2ax_cfg;
extern const struct iwl_cfg iwl9461_2ac_cfg_qu_b0_jf_b0;
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 7c5aaeaf7fe5..65d2f6b996dd 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1050,18 +1050,22 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
* thing to do to support Qu C-step.
*/
if (iwl_trans->hw_rev == CSR_HW_REV_TYPE_QU_C0) {
- if (iwl_trans->cfg == &iwl_ax101_cfg_qu_hr)
- iwl_trans->cfg = &iwl_ax101_cfg_qu_c0_hr_b0;
- else if (iwl_trans->cfg == &iwl_ax201_cfg_qu_hr)
- iwl_trans->cfg = &iwl_ax201_cfg_qu_c0_hr_b0;
- else if (iwl_trans->cfg == &iwl9461_2ac_cfg_qu_b0_jf_b0)
- iwl_trans->cfg = &iwl9461_2ac_cfg_qu_c0_jf_b0;
- else if (iwl_trans->cfg == &iwl9462_2ac_cfg_qu_b0_jf_b0)
- iwl_trans->cfg = &iwl9462_2ac_cfg_qu_c0_jf_b0;
- else if (iwl_trans->cfg == &iwl9560_2ac_cfg_qu_b0_jf_b0)
- iwl_trans->cfg = &iwl9560_2ac_cfg_qu_c0_jf_b0;
- else if (iwl_trans->cfg == &iwl9560_2ac_160_cfg_qu_b0_jf_b0)
- iwl_trans->cfg = &iwl9560_2ac_160_cfg_qu_c0_jf_b0;
+ if (iwl_trans->cfg= &iwl_ax101_cfg_qu_hr)
+ iwl_trans->cfg &iwl_ax101_cfg_qu_c0_hr_b0;
+ else if (iwl_trans->cfg= &iwl_ax201_cfg_qu_hr)
+ iwl_trans->cfg &iwl_ax201_cfg_qu_c0_hr_b0;
+ else if (iwl_trans->cfg= &iwl9461_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg &iwl9461_2ac_cfg_qu_c0_jf_b0;
+ else if (iwl_trans->cfg= &iwl9462_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg &iwl9462_2ac_cfg_qu_c0_jf_b0;
+ else if (iwl_trans->cfg= &iwl9560_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg &iwl9560_2ac_cfg_qu_c0_jf_b0;
+ else if (iwl_trans->cfg= &iwl9560_2ac_160_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg &iwl9560_2ac_160_cfg_qu_c0_jf_b0;
+ else if (iwl_trans->cfg= &killer1650s_2ax_cfg_qu_b0_hr_b0)
+ iwl_trans->cfg &killer1650s_2ax_cfg_qu_c0_hr_b0;
+ else if (iwl_trans->cfg= &killer1650i_2ax_cfg_qu_b0_hr_b0)
+ iwl_trans->cfg &killer1650i_2ax_cfg_qu_c0_hr_b0;
}
/* same thing for QuZ... */
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 935e35dafce5..db62c8314603 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3602,12 +3602,7 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
}
} else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
- ((trans->cfg != &iwl_ax200_cfg_cc &&
- trans->cfg != &iwl_ax201_cfg_qu_hr &&
- trans->cfg != &killer1650x_2ax_cfg &&
- trans->cfg != &killer1650w_2ax_cfg &&
- trans->cfg != &iwl_ax201_cfg_quz_hr) ||
- trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0)) {
+ trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
u32 hw_status;
hw_status = iwl_read_prph(trans, UMAG_GEN_HW_STATUS);
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH 00/18] iwlwifi: updates intended for v5.4 2019-08-21
From: Luca Coelho @ 2019-08-21 13:37 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
From: Luca Coelho <luciano.coelho@intel.com>
Hi,
Here's the second set of patches intended for v5.4. It's the usual
development, new features, cleanups and bugfixes.
The changes are:
* Removal of (broken) d0i3 continues;
* Debug infrastructure work continues;
* Fix for the SN value in certain suspend/resume situations;
* Some work on new FW scan APIs;
* A few clean-ups;
* Other small fixes and improvements;
As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.
Please review.
Cheers,
Luca.
Alex Malamud (2):
iwlwifi: mvm: ftm: make common calib signed
iwlwifi: Set w-pointer upon resume according to SN
Ayala Beker (2):
iwlwifi: scan: add support for new scan request command version
iwlwifi: scan: don't pass large argument by value
Emmanuel Grumbach (6):
iwlwifi: remove runtime_pm_mode
iwlwifi: remove the opmode's d0i3 handlers
iwlwifi: pcie: remove the refs / unrefs from the transport
iwlwifi: pcie: remove some more d0i3 code from the transport
iwlwifi: remove the d0i3 related module parameters
iwlwifi: remove pm_runtime completely
Haim Dreyfuss (1):
iwlwifi: remove unused regdb_ptrs allocation
Johannes Berg (1):
iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL
Mordechay Goodstein (1):
iwlwifi: mvm: name magic numbers with enum
Shahar S Matityahu (5):
iwlwifi: dbg_ini: align dbg tlv functions names to a single format
iwlwifi: dbg: add debug periphery registers to 9000 device family
iwlwifi: dbg_ini: maintain buffer allocations from trans instead of
TLVs buffer
iwlwifi: dbg_ini: use linked list to store debug TLVs
iwlwifi: dbg_ini: remove periphery phy and aux regions handling
.../wireless/intel/iwlwifi/fw/api/dbg-tlv.h | 2 +
.../net/wireless/intel/iwlwifi/fw/api/rs.h | 18 ++-
.../net/wireless/intel/iwlwifi/fw/api/scan.h | 55 ++++++-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 53 +++---
drivers/net/wireless/intel/iwlwifi/fw/file.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/img.h | 9 --
.../net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 153 +++++-------------
.../net/wireless/intel/iwlwifi/iwl-dbg-tlv.h | 24 ++-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 19 +--
.../wireless/intel/iwlwifi/iwl-modparams.h | 9 +-
.../wireless/intel/iwlwifi/iwl-nvm-parse.c | 14 --
.../net/wireless/intel/iwlwifi/iwl-op-mode.h | 23 ---
.../net/wireless/intel/iwlwifi/iwl-trans.c | 14 --
.../net/wireless/intel/iwlwifi/iwl-trans.h | 106 ++++--------
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 9 ++
.../net/wireless/intel/iwlwifi/mvm/debugfs.c | 37 +++++
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 17 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 11 +-
.../net/wireless/intel/iwlwifi/mvm/rs-fw.c | 19 ++-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 87 +++++++---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 99 ------------
.../wireless/intel/iwlwifi/pcie/internal.h | 11 +-
.../wireless/intel/iwlwifi/pcie/trans-gen2.c | 6 +-
.../net/wireless/intel/iwlwifi/pcie/trans.c | 67 ++------
.../net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 42 +----
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 92 ++++-------
26 files changed, 363 insertions(+), 637 deletions(-)
--
2.23.0.rc1
^ permalink raw reply
* [PATCH 01/18] iwlwifi: mvm: ftm: make common calib signed
From: Luca Coelho @ 2019-08-21 13:37 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190821133800.23636-1-luca@coelho.fi>
From: Alex Malamud <alex.malamud@intel.com>
The common calib value should be signed, so use int instead of u16.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/fw/file.h | 3 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs.c | 37 +++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 3 +-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index ea2b3d77f848..418064ced337 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -441,9 +441,10 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_DYNAMIC_QUOTA = (__force iwl_ucode_tlv_capa_t)44,
IWL_UCODE_TLV_CAPA_COEX_SCHEMA_2 = (__force iwl_ucode_tlv_capa_t)45,
IWL_UCODE_TLV_CAPA_CHANNEL_SWITCH_CMD = (__force iwl_ucode_tlv_capa_t)46,
- IWL_UCODE_TLV_CAPA_ULTRA_HB_CHANNELS = (__force iwl_ucode_tlv_capa_t)48,
IWL_UCODE_TLV_CAPA_FTM_CALIBRATED = (__force iwl_ucode_tlv_capa_t)47,
+ IWL_UCODE_TLV_CAPA_ULTRA_HB_CHANNELS = (__force iwl_ucode_tlv_capa_t)48,
IWL_UCODE_TLV_CAPA_CS_MODIFY = (__force iwl_ucode_tlv_capa_t)49,
+ IWL_UCODE_TLV_CAPA_SET_LTR_GEN2 = (__force iwl_ucode_tlv_capa_t)50,
/* set 2 */
IWL_UCODE_TLV_CAPA_EXTENDED_DTS_MEASURE = (__force iwl_ucode_tlv_capa_t)64,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
index 6d67d3da31e0..994a4ba07204 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
@@ -1758,6 +1758,38 @@ iwl_dbgfs_uapsd_noagg_bssids_read(struct file *file, char __user *user_buf,
return simple_read_from_buffer(user_buf, count, ppos, buf, pos);
}
+static ssize_t
+iwl_dbgfs_ltr_config_write(struct iwl_mvm *mvm,
+ char *buf, size_t count, loff_t *ppos)
+{
+ int ret;
+ struct iwl_ltr_config_cmd ltr_config = {0};
+
+ if (!iwl_mvm_firmware_running(mvm))
+ return -EIO;
+
+ if (sscanf(buf, "%x,%x,%x,%x,%x,%x,%x",
+ <r_config.flags,
+ <r_config.static_long,
+ <r_config.static_short,
+ <r_config.ltr_cfg_values[0],
+ <r_config.ltr_cfg_values[1],
+ <r_config.ltr_cfg_values[2],
+ <r_config.ltr_cfg_values[3]) != 7) {
+ return -EINVAL;
+ }
+
+ mutex_lock(&mvm->mutex);
+ ret = iwl_mvm_send_cmd_pdu(mvm, LTR_CONFIG, 0, sizeof(ltr_config),
+ <r_config);
+ mutex_unlock(&mvm->mutex);
+
+ if (ret)
+ IWL_ERR(mvm, "failed to send ltr configuration cmd\n");
+
+ return ret ?: count;
+}
+
MVM_DEBUGFS_READ_WRITE_FILE_OPS(prph_reg, 64);
/* Device wide debugfs entries */
@@ -1806,6 +1838,8 @@ MVM_DEBUGFS_READ_WRITE_STA_FILE_OPS(amsdu_len, 16);
MVM_DEBUGFS_READ_WRITE_FILE_OPS(he_sniffer_params, 32);
+MVM_DEBUGFS_WRITE_FILE_OPS(ltr_config, 512);
+
static ssize_t iwl_dbgfs_mem_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -1993,6 +2027,9 @@ void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
#endif
MVM_DEBUGFS_ADD_FILE(he_sniffer_params, mvm->debugfs_dir, 0600);
+ if (fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_SET_LTR_GEN2))
+ MVM_DEBUGFS_ADD_FILE(ltr_config, mvm->debugfs_dir, 0200);
+
debugfs_create_bool("enable_scan_iteration_notif", 0600,
mvm->debugfs_dir, &mvm->scan_iter_notif_enabled);
debugfs_create_bool("drop_bcn_ap_mode", 0600, mvm->debugfs_dir,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 251e7c235aaa..bb2aec9c6738 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1302,7 +1302,8 @@ int iwl_mvm_up(struct iwl_mvm *mvm)
iwl_mvm_tt_tx_backoff(mvm, 0);
#endif
- WARN_ON(iwl_mvm_config_ltr(mvm));
+ if (!fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_SET_LTR_GEN2))
+ WARN_ON(iwl_mvm_config_ltr(mvm));
ret = iwl_mvm_power_update_device(mvm);
if (ret)
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH 02/18] iwlwifi: scan: add support for new scan request command version
From: Luca Coelho @ 2019-08-21 13:37 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190821133800.23636-1-luca@coelho.fi>
From: Ayala Beker <ayala.beker@intel.com>
Scan API was changed to support 6Ghz channels as well.
Support the new version.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../net/wireless/intel/iwlwifi/fw/api/scan.h | 55 ++++++++++--
drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 ++
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 +++++++++++++------
4 files changed, 116 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h b/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h
index c4960f045415..39c64850cb6f 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h
@@ -93,6 +93,8 @@ struct iwl_ssid_ie {
#define IWL_SCAN_SHORT_BLACKLIST_LEN 16
#define IWL_SCAN_MAX_PROFILES 11
#define SCAN_OFFLOAD_PROBE_REQ_SIZE 512
+#define SCAN_NUM_BAND_PROBE_DATA_V_1 2
+#define SCAN_NUM_BAND_PROBE_DATA_V_2 3
/* Default watchdog (in MS) for scheduled scan iteration */
#define IWL_SCHED_SCAN_WATCHDOG cpu_to_le16(15000)
@@ -251,9 +253,22 @@ struct iwl_scan_probe_segment {
* @common_data: last (and common) part of the probe
* @buf: raw data block
*/
+struct iwl_scan_probe_req_v1 {
+ struct iwl_scan_probe_segment mac_header;
+ struct iwl_scan_probe_segment band_data[SCAN_NUM_BAND_PROBE_DATA_V_1];
+ struct iwl_scan_probe_segment common_data;
+ u8 buf[SCAN_OFFLOAD_PROBE_REQ_SIZE];
+} __packed;
+
+/* iwl_scan_probe_req - PROBE_REQUEST_FRAME_API_S_VER_v2
+ * @mac_header: first (and common) part of the probe
+ * @band_data: band specific data
+ * @common_data: last (and common) part of the probe
+ * @buf: raw data block
+ */
struct iwl_scan_probe_req {
struct iwl_scan_probe_segment mac_header;
- struct iwl_scan_probe_segment band_data[2];
+ struct iwl_scan_probe_segment band_data[SCAN_NUM_BAND_PROBE_DATA_V_2];
struct iwl_scan_probe_segment common_data;
u8 buf[SCAN_OFFLOAD_PROBE_REQ_SIZE];
} __packed;
@@ -608,15 +623,29 @@ enum iwl_umac_scan_general_flags2 {
* struct iwl_scan_channel_cfg_umac
* @flags: bitmap - 0-19: directed scan to i'th ssid.
* @channel_num: channel number 1-13 etc.
+ * @band: band of channel: 0 for 2GHz, 1 for 5GHz
* @iter_count: repetition count for the channel.
* @iter_interval: interval between two scan iterations on one channel.
*/
-struct iwl_scan_channel_cfg_umac {
+struct iwl_scan_channel_cfg_umac {
__le32 flags;
- u8 channel_num;
- u8 iter_count;
- __le16 iter_interval;
-} __packed; /* SCAN_CHANNEL_CFG_S_VER2 */
+ /* Both versions are of the same size, so use a union without adjusting
+ * the command size later
+ */
+ union {
+ struct {
+ u8 channel_num;
+ u8 iter_count;
+ __le16 iter_interval;
+ } v1; /* SCAN_CHANNEL_CFG_S_VER1 */
+ struct {
+ u8 channel_num;
+ u8 band;
+ u8 iter_count;
+ u8 iter_interval;
+ } v2; /* SCAN_CHANNEL_CFG_S_VER2 */
+ };
+} __packed;
/**
* struct iwl_scan_umac_schedule
@@ -630,6 +659,16 @@ struct iwl_scan_umac_schedule {
u8 reserved;
} __packed; /* SCAN_SCHED_PARAM_API_S_VER_1 */
+struct iwl_scan_req_umac_tail_v1 {
+ /* SCAN_PERIODIC_PARAMS_API_S_VER_1 */
+ struct iwl_scan_umac_schedule schedule[IWL_MAX_SCHED_SCAN_PLANS];
+ __le16 delay;
+ __le16 reserved;
+ /* SCAN_PROBE_PARAMS_API_S_VER_1 */
+ struct iwl_scan_probe_req_v1 preq;
+ struct iwl_ssid_ie direct_scan[PROBE_OPTION_MAX];
+} __packed;
+
/**
* struct iwl_scan_req_umac_tail - the rest of the UMAC scan request command
* parameters following channels configuration array.
@@ -639,12 +678,12 @@ struct iwl_scan_umac_schedule {
* @preq: probe request with IEs blocks
* @direct_scan: list of SSIDs for directed active scan
*/
-struct iwl_scan_req_umac_tail {
+struct iwl_scan_req_umac_tail_v2 {
/* SCAN_PERIODIC_PARAMS_API_S_VER_1 */
struct iwl_scan_umac_schedule schedule[IWL_MAX_SCHED_SCAN_PLANS];
__le16 delay;
__le16 reserved;
- /* SCAN_PROBE_PARAMS_API_S_VER_1 */
+ /* SCAN_PROBE_PARAMS_API_S_VER_2 */
struct iwl_scan_probe_req preq;
struct iwl_ssid_ie direct_scan[PROBE_OPTION_MAX];
} __packed;
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 418064ced337..3d567240ef11 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -323,6 +323,7 @@ enum iwl_ucode_tlv_api {
IWL_UCODE_TLV_API_FTM_RTT_ACCURACY = (__force iwl_ucode_tlv_api_t)54,
IWL_UCODE_TLV_API_SAR_TABLE_VER = (__force iwl_ucode_tlv_api_t)55,
IWL_UCODE_TLV_API_ADWELL_HB_DEF_N_AP = (__force iwl_ucode_tlv_api_t)57,
+ IWL_UCODE_TLV_API_SCAN_EXT_CHAN_VER = (__force iwl_ucode_tlv_api_t)58,
NUM_IWL_UCODE_TLV_API
#ifdef __CHECKER__
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index ed52e2ea97d9..2aa9bfc5e113 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1387,6 +1387,12 @@ static inline bool iwl_mvm_cdb_scan_api(struct iwl_mvm *mvm)
return mvm->trans->cfg->device_family >= IWL_DEVICE_FAMILY_22000;
}
+static inline bool iwl_mvm_is_scan_ext_chan_supported(struct iwl_mvm *mvm)
+{
+ return fw_has_api(&mvm->fw->ucode_capa,
+ IWL_UCODE_TLV_API_SCAN_EXT_CHAN_VER);
+}
+
static inline bool iwl_mvm_has_new_rx_stats_api(struct iwl_mvm *mvm)
{
return fw_has_api(&mvm->fw->ucode_capa,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index 2652e6ce4089..85e33310804e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@ -77,7 +77,10 @@
#define IWL_SCAN_DWELL_FRAGMENTED 44
#define IWL_SCAN_DWELL_EXTENDED 90
#define IWL_SCAN_NUM_OF_FRAGS 3
+#define IWL_SCAN_LAST_2_4_CHN 14
+#define IWL_SCAN_BAND_5_2 0
+#define IWL_SCAN_BAND_2_4 1
/* adaptive dwell max budget time [TU] for full scan */
#define IWL_SCAN_ADWELL_MAX_BUDGET_FULL_SCAN 300
@@ -956,11 +959,24 @@ static int iwl_mvm_scan_lmac_flags(struct iwl_mvm *mvm,
return flags;
}
+static void
+iwl_mvm_scan_set_legacy_probe_req(struct iwl_scan_probe_req_v1 *p_req,
+ struct iwl_scan_probe_req src_p_req)
+{
+ int i;
+
+ p_req->mac_header = src_p_req.mac_header;
+ for (i = 0; i < SCAN_NUM_BAND_PROBE_DATA_V_1; i++)
+ p_req->band_data[i] = src_p_req.band_data[i];
+ p_req->common_data = src_p_req.common_data;
+ memcpy(p_req->buf, src_p_req.buf, SCAN_OFFLOAD_PROBE_REQ_SIZE);
+}
+
static int iwl_mvm_scan_lmac(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
struct iwl_mvm_scan_params *params)
{
struct iwl_scan_req_lmac *cmd = mvm->scan_cmd;
- struct iwl_scan_probe_req *preq =
+ struct iwl_scan_probe_req_v1 *preq =
(void *)(cmd->data + sizeof(struct iwl_scan_channel_cfg_lmac) *
mvm->fw->ucode_capa.n_scan_channels);
u32 ssid_bitmap = 0;
@@ -1030,7 +1046,7 @@ static int iwl_mvm_scan_lmac(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
iwl_mvm_lmac_scan_cfg_channels(mvm, params->channels,
params->n_channels, ssid_bitmap, cmd);
- *preq = params->preq;
+ iwl_mvm_scan_set_legacy_probe_req(preq, params->preq);
return 0;
}
@@ -1384,9 +1400,17 @@ iwl_mvm_umac_scan_cfg_channels(struct iwl_mvm *mvm,
for (i = 0; i < n_channels; i++) {
channel_cfg[i].flags = cpu_to_le32(ssid_bitmap);
- channel_cfg[i].channel_num = channels[i]->hw_value;
- channel_cfg[i].iter_count = 1;
- channel_cfg[i].iter_interval = 0;
+ channel_cfg[i].v1.channel_num = channels[i]->hw_value;
+ if (iwl_mvm_is_scan_ext_chan_supported(mvm)) {
+ channel_cfg[i].v2.band =
+ channels[i]->hw_value <= IWL_SCAN_LAST_2_4_CHN ?
+ IWL_SCAN_BAND_2_4 : IWL_SCAN_BAND_5_2;
+ channel_cfg[i].v2.iter_count = 1;
+ channel_cfg[i].v2.iter_interval = 0;
+ } else {
+ channel_cfg[i].v1.iter_count = 1;
+ channel_cfg[i].v1.iter_interval = 0;
+ }
}
}
@@ -1476,9 +1500,12 @@ static int iwl_mvm_scan_umac(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
struct iwl_scan_req_umac *cmd = mvm->scan_cmd;
struct iwl_scan_umac_chan_param *chan_param;
void *cmd_data = iwl_mvm_get_scan_req_umac_data(mvm);
- struct iwl_scan_req_umac_tail *sec_part = cmd_data +
- sizeof(struct iwl_scan_channel_cfg_umac) *
- mvm->fw->ucode_capa.n_scan_channels;
+ void *sec_part = cmd_data + sizeof(struct iwl_scan_channel_cfg_umac) *
+ mvm->fw->ucode_capa.n_scan_channels;
+ struct iwl_scan_req_umac_tail_v2 *tail_v2 =
+ (struct iwl_scan_req_umac_tail_v2 *)sec_part;
+ struct iwl_scan_req_umac_tail_v1 *tail_v1;
+ struct iwl_ssid_ie *direct_scan;
int uid, i;
u32 ssid_bitmap = 0;
u8 channel_flags = 0;
@@ -1540,18 +1567,12 @@ static int iwl_mvm_scan_umac(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
chan_param->flags = channel_flags;
chan_param->count = params->n_channels;
- iwl_scan_build_ssids(params, sec_part->direct_scan, &ssid_bitmap);
-
- iwl_mvm_umac_scan_cfg_channels(mvm, params->channels,
- params->n_channels, ssid_bitmap,
- cmd_data);
-
for (i = 0; i < params->n_scan_plans; i++) {
struct cfg80211_sched_scan_plan *scan_plan =
¶ms->scan_plans[i];
- sec_part->schedule[i].iter_count = scan_plan->iterations;
- sec_part->schedule[i].interval =
+ tail_v2->schedule[i].iter_count = scan_plan->iterations;
+ tail_v2->schedule[i].interval =
cpu_to_le16(scan_plan->interval);
}
@@ -1561,12 +1582,23 @@ static int iwl_mvm_scan_umac(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
* For example, when regular scan is requested the driver sets one scan
* plan with one iteration.
*/
- if (!sec_part->schedule[i - 1].iter_count)
- sec_part->schedule[i - 1].iter_count = 0xff;
+ if (!tail_v2->schedule[i - 1].iter_count)
+ tail_v2->schedule[i - 1].iter_count = 0xff;
- sec_part->delay = cpu_to_le16(params->delay);
- sec_part->preq = params->preq;
+ tail_v2->delay = cpu_to_le16(params->delay);
+ if (iwl_mvm_is_scan_ext_chan_supported(mvm)) {
+ tail_v2->preq = params->preq;
+ direct_scan = tail_v2->direct_scan;
+ } else {
+ tail_v1 = (struct iwl_scan_req_umac_tail_v1 *)sec_part;
+ iwl_mvm_scan_set_legacy_probe_req(&tail_v1->preq, params->preq);
+ direct_scan = tail_v1->direct_scan;
+ }
+ iwl_scan_build_ssids(params, direct_scan, &ssid_bitmap);
+ iwl_mvm_umac_scan_cfg_channels(mvm, params->channels,
+ params->n_channels, ssid_bitmap,
+ cmd_data);
return 0;
}
@@ -1996,6 +2028,7 @@ static int iwl_mvm_scan_stop_wait(struct iwl_mvm *mvm, int type)
int iwl_mvm_scan_size(struct iwl_mvm *mvm)
{
int base_size = IWL_SCAN_REQ_UMAC_SIZE_V1;
+ int tail_size;
if (iwl_mvm_is_adaptive_dwell_v2_supported(mvm))
base_size = IWL_SCAN_REQ_UMAC_SIZE_V8;
@@ -2004,16 +2037,21 @@ int iwl_mvm_scan_size(struct iwl_mvm *mvm)
else if (iwl_mvm_cdb_scan_api(mvm))
base_size = IWL_SCAN_REQ_UMAC_SIZE_V6;
- if (fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_UMAC_SCAN))
+ if (fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_UMAC_SCAN)) {
+ if (iwl_mvm_is_scan_ext_chan_supported(mvm))
+ tail_size = sizeof(struct iwl_scan_req_umac_tail_v2);
+ else
+ tail_size = sizeof(struct iwl_scan_req_umac_tail_v1);
+
return base_size +
sizeof(struct iwl_scan_channel_cfg_umac) *
mvm->fw->ucode_capa.n_scan_channels +
- sizeof(struct iwl_scan_req_umac_tail);
-
+ tail_size;
+ }
return sizeof(struct iwl_scan_req_lmac) +
sizeof(struct iwl_scan_channel_cfg_lmac) *
mvm->fw->ucode_capa.n_scan_channels +
- sizeof(struct iwl_scan_probe_req);
+ sizeof(struct iwl_scan_probe_req_v1);
}
/*
--
2.23.0.rc1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox