* [PATCH] mt76: mt76x02u: enable multi-vif support
From: Lorenzo Bianconi @ 2019-08-02 14:36 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Enable multi-interface support for mt76x02u driver. For the moment
allow max two concurrent interfaces in order to preserve enough room
for ps traffic since we are using beacon slots for it.
I have successfully tested the following configuration:
- AP + STA
- AP0 + AP1
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt76x02_util.c | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index fa45ed280ab1..476f0157a370 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -61,6 +61,20 @@ static const struct ieee80211_iface_limit mt76x02_if_limits[] = {
},
};
+static const struct ieee80211_iface_limit mt76x02u_if_limits[] = {
+ {
+ .max = 1,
+ .types = BIT(NL80211_IFTYPE_ADHOC)
+ }, {
+ .max = 2,
+ .types = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
+ BIT(NL80211_IFTYPE_AP)
+ },
+};
+
static const struct ieee80211_iface_combination mt76x02_if_comb[] = {
{
.limits = mt76x02_if_limits,
@@ -75,6 +89,16 @@ static const struct ieee80211_iface_combination mt76x02_if_comb[] = {
}
};
+static const struct ieee80211_iface_combination mt76x02u_if_comb[] = {
+ {
+ .limits = mt76x02u_if_limits,
+ .n_limits = ARRAY_SIZE(mt76x02u_if_limits),
+ .max_interfaces = 2,
+ .num_different_channels = 1,
+ .beacon_int_infra_match = true,
+ }
+};
+
static void
mt76x02_led_set_config(struct mt76_dev *mdev, u8 delay_on,
u8 delay_off)
@@ -151,6 +175,8 @@ void mt76x02_init_device(struct mt76x02_dev *dev)
if (mt76_is_usb(dev)) {
hw->extra_tx_headroom += sizeof(struct mt76x02_txwi) +
MT_DMA_HDR_LEN;
+ wiphy->iface_combinations = mt76x02u_if_comb;
+ wiphy->n_iface_combinations = ARRAY_SIZE(mt76x02u_if_comb);
} else {
INIT_DELAYED_WORK(&dev->wdt_work, mt76x02_wdt_work);
--
2.21.0
^ permalink raw reply related
* Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Brian Norris @ 2019-08-03 1:06 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo
Cc: Kalle Valo, linux-wireless, linux-kernel, Dmitry Torokhov,
Jeffy Chen, Doug Anderson, Matthias Kaehlcke
In-Reply-To: <20170331202136.100342-1-briannorris@chromium.org>
+ Doug, Matthias, who are seeing problems (or, failure to try to
recover, as predicted below)
+ Amit's new email
+ new maintainers
Perhaps it's my fault for marking this RFC. But I changed the status
back to "New" in Patchwork, in case that helps:
On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote:
> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>
> This above-mentioned "fix" does not actually do anything to prevent a
> race condition. It simply papers over it so that the issue doesn't
> appear.
>
> If this is a real problem, it should be explained better than the above
> commit does, and an alternative, non-racy solution should be found.
>
> For further reason to revert this: there's ot reason we can't try
s/ot/no/
...oops.
> resetting the card when it's *actually* stuck in host-sleep mode. So
> instead, this is unnecessarily creating scenarios where we can't recover
> Wifi.
>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you
> still think it's needed, can you please propose an alternative? Or at least
> explain more why this is needed? Thanks.
FWIW, I got an Acked-by from Amit when he was still at Marvell. And
another Reviewed-by from Dmitry. This still applies. Should I resend?
(I'll do that if I don't hear a response within a few days.)
Thanks,
Brian
> drivers/net/wireless/marvell/mwifiex/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
> index 756948385b60..0dab77b526de 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -60,7 +60,7 @@ static void wakeup_timer_fn(unsigned long data)
> adapter->hw_status = MWIFIEX_HW_STATUS_RESET;
> mwifiex_cancel_all_pending_cmd(adapter);
>
> - if (adapter->if_ops.card_reset && !adapter->hs_activated)
> + if (adapter->if_ops.card_reset)
> adapter->if_ops.card_reset(adapter);
> }
>
> --
> 2.12.2.564.g063fe858b8-goog
>
^ permalink raw reply
* Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Kalle Valo @ 2019-08-03 1:55 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, linux-kernel, Dmitry Torokhov, Jeffy Chen,
Doug Anderson, Matthias Kaehlcke
In-Reply-To: <20190803010641.GA22848@google.com>
Brian Norris <briannorris@chromium.org> writes:
> + Doug, Matthias, who are seeing problems (or, failure to try to
> recover, as predicted below)
> + Amit's new email
> + new maintainers
>
> Perhaps it's my fault for marking this RFC. But I changed the status
> back to "New" in Patchwork, in case that helps:
But I still see it marked as RFC. So the patch in question is:
https://patchwork.kernel.org/patch/9657277/
Changing the patchwork state to RFC means that it's dropped and out of
my radar. Also, if I see "RFC" in the subject I assume that's a patch
which I should not apply by default.
> On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote:
>> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>>
>> This above-mentioned "fix" does not actually do anything to prevent a
>> race condition. It simply papers over it so that the issue doesn't
>> appear.
>>
>> If this is a real problem, it should be explained better than the above
>> commit does, and an alternative, non-racy solution should be found.
>>
>> For further reason to revert this: there's ot reason we can't try
>
> s/ot/no/
>
> ...oops.
>
>> resetting the card when it's *actually* stuck in host-sleep mode. So
>> instead, this is unnecessarily creating scenarios where we can't recover
>> Wifi.
>>
>> Cc: Amitkumar Karwar <akarwar@marvell.com>
>> Signed-off-by: Brian Norris <briannorris@chromium.org>
>> ---
>> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you
>> still think it's needed, can you please propose an alternative? Or at least
>> explain more why this is needed? Thanks.
>
> FWIW, I got an Acked-by from Amit when he was still at Marvell. And
> another Reviewed-by from Dmitry. This still applies. Should I resend?
> (I'll do that if I don't hear a response within a few days.)
This patch is from 2017 so better to resend, and without RFC markings.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Brian Norris @ 2019-08-03 2:02 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, Linux Kernel, Dmitry Torokhov, Jeffy Chen,
Doug Anderson, Matthias Kaehlcke
In-Reply-To: <875znfhv2b.fsf@kamboji.qca.qualcomm.com>
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Brian Norris <briannorris@chromium.org> writes:
>
> > + Doug, Matthias, who are seeing problems (or, failure to try to
> > recover, as predicted below)
> > + Amit's new email
> > + new maintainers
> >
> > Perhaps it's my fault for marking this RFC. But I changed the status
> > back to "New" in Patchwork, in case that helps:
>
> But I still see it marked as RFC. So the patch in question is:
>
> https://patchwork.kernel.org/patch/9657277/
Oops, I didn't hit the "Update" button :(
I changed it now, but I'll change it back again.
> Changing the patchwork state to RFC means that it's dropped and out of
> my radar. Also, if I see "RFC" in the subject I assume that's a patch
> which I should not apply by default.
Ack. Well, there were some "RFCs" I sent recently that you *did*
apply, so I didn't really know what happens normally.
> > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote:
...
> > FWIW, I got an Acked-by from Amit when he was still at Marvell. And
> > another Reviewed-by from Dmitry. This still applies. Should I resend?
> > (I'll do that if I don't hear a response within a few days.)
>
> This patch is from 2017 so better to resend, and without RFC markings.
Yep, will do.
Brian
^ permalink raw reply
* Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Kalle Valo @ 2019-08-03 2:08 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, Linux Kernel, Dmitry Torokhov, Jeffy Chen,
Doug Anderson, Matthias Kaehlcke
In-Reply-To: <CA+ASDXPCxDQAFPcPu5N6aY9mRDRF2FmsSTWAdgvSNDa2uPsRtQ@mail.gmail.com>
Brian Norris <briannorris@chromium.org> writes:
>> Changing the patchwork state to RFC means that it's dropped and out of
>> my radar. Also, if I see "RFC" in the subject I assume that's a patch
>> which I should not apply by default.
>
> Ack. Well, there were some "RFCs" I sent recently that you *did*
> apply, so I didn't really know what happens normally.
True, I have sometimes applied RFC patches in case they look good enough
and I do not want them to get lost (and this is a good example of RFC
patches getting lost). But by default I drop RFC patches after a quick
glance.
>> > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote:
> ...
>> > FWIW, I got an Acked-by from Amit when he was still at Marvell. And
>> > another Reviewed-by from Dmitry. This still applies. Should I resend?
>> > (I'll do that if I don't hear a response within a few days.)
>>
>> This patch is from 2017 so better to resend, and without RFC markings.
>
> Yep, will do.
Thanks.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] cfg80211: Fix Extended Key ID key install checks
From: Alexander Wetzel @ 2019-08-03 15:23 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Alexander Wetzel
Fix two shortcomings of the Extended Key ID API:
1) Allow the userspace to install pairwise keys using keyid 1 without
NL80211_KEY_NO_TX set. This allows the userspace to install and
activate pairwise keys with keyid 1 in the same way as for keyid 0,
simplifying the API usage for e.g. FILS and FT key installs.
2) IEEE 802.11 - 2016 restricts Extended Key ID usage to CCMP/GCMP
ciphers in IEEE 802.11 - 2016 "9.4.2.25.4 RSN capabilities".
Enforce that when installing a key.
Fixes: 6cdd3979a2bd ("nl80211/cfg80211: Extended Key ID support")
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---
This patch ended up redesigning the Extended Key ID key install checks
from scratch...
While working on wpa_supplicant/hostapd Extended Key ID support it
turned out that it's still useful to be able to install and activate a
pairwise key for Tx in one step. So instead of forcing the userspace to
always install and then activate a key I would prefer to fix the API and
relax the checks with this patch.
Down side of that is, that we have to get the fix also into 5.2 and 5.3.
All kernels without the fix will potentially not work correctly with the
upcoming userspace when using FT (fast roaming) or FILS with an Extended
Key ID capable AP. (Anyone using the existing API will not notice the
difference, but I'm next to sure it's only used by my experimental hostapd
patches so far.)
So ideally we get this patch back ported to all kernels which also have
6cdd3979a2bd ("nl80211/cfg80211: Extended Key ID support")
Another issue I tripped over while getting the hostapd patches into
shape is, that our mac80211 TKIP SW crypto implementation drops unicast
packets on receive when they are using keyid 1.
Since a standard compliant implementation of Extended Key ID must not
use TKIP enforcing that rule at key install seems to be preferable
to handle that within mac80211.
net/wireless/util.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index d0e35b7b9e35..962ca7fc1ab7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -233,25 +233,29 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
switch (params->cipher) {
case WLAN_CIPHER_SUITE_TKIP:
+ /* Extended Key ID can only be used with CCMP/GCMP ciphers */
+ if (pairwise && key_idx)
+ return -EINVAL;
+ /* fall through */
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
case WLAN_CIPHER_SUITE_GCMP:
case WLAN_CIPHER_SUITE_GCMP_256:
- /* IEEE802.11-2016 allows only 0 and - when using Extended Key
- * ID - 1 as index for pairwise keys.
+ /* IEEE802.11-2016 allows only 0 and - when supporting
+ * Extended Key ID - 1 as index for pairwise keys.
* @NL80211_KEY_NO_TX is only allowed for pairwise keys when
* the driver supports Extended Key ID.
* @NL80211_KEY_SET_TX can't be set when installing and
* validating a key.
*/
- if (params->mode == NL80211_KEY_NO_TX) {
- if (!wiphy_ext_feature_isset(&rdev->wiphy,
- NL80211_EXT_FEATURE_EXT_KEY_ID))
- return -EINVAL;
- else if (!pairwise || key_idx < 0 || key_idx > 1)
+ if ((params->mode == NL80211_KEY_NO_TX && !pairwise) ||
+ params->mode == NL80211_KEY_SET_TX)
+ return -EINVAL;
+ if (wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_EXT_KEY_ID)) {
+ if (pairwise && (key_idx < 0 || key_idx > 1))
return -EINVAL;
- } else if ((pairwise && key_idx) ||
- params->mode == NL80211_KEY_SET_TX) {
+ } else if (pairwise && key_idx) {
return -EINVAL;
}
break;
--
2.22.0
^ permalink raw reply related
* [PATCH 1/2] Fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe
From: Hui Peng @ 2019-08-04 0:29 UTC (permalink / raw)
To: kvalo, davem
Cc: Hui Peng, Mathias Payer, linux-wireless, netdev, linux-kernel
The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects
are initialized to point to the containing `ath6kl_usb` object
according to endpoint descriptors read from the device side, as shown
below in `ath6kl_usb_setup_pipe_resources`:
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = &iface_desc->endpoint[i].desc;
// get the address from endpoint descriptor
pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb,
endpoint->bEndpointAddress,
&urbcount);
......
// select the pipe object
pipe = &ar_usb->pipes[pipe_num];
// initialize the ar_usb field
pipe->ar_usb = ar_usb;
}
The driver assumes that the addresses reported in endpoint
descriptors from device side to be complete. If a device is
malicious and does not report complete addresses, it may trigger
NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and
`ath6kl_usb_free_urb_to_pipe`.
This patch fixes the bug by preventing potential NULL-ptr-deref.
Signed-off-by: Hui Peng <benquike@gmail.com>
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
---
drivers/net/wireless/ath/ath6kl/usb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 4defb7a0330f..53b66e9434c9 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -132,6 +132,10 @@ ath6kl_usb_alloc_urb_from_pipe(struct ath6kl_usb_pipe *pipe)
struct ath6kl_urb_context *urb_context = NULL;
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return NULL;
+
spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
if (!list_empty(&pipe->urb_list_head)) {
urb_context =
@@ -150,6 +154,10 @@ static void ath6kl_usb_free_urb_to_pipe(struct ath6kl_usb_pipe *pipe,
{
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return;
+
spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
pipe->urb_cnt++;
--
2.22.0
^ permalink raw reply related
* [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
From: Hui Peng @ 2019-08-04 0:31 UTC (permalink / raw)
To: kvalo, davem
Cc: Hui Peng, Mathias Payer, ath10k, linux-wireless, netdev,
linux-kernel
The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
are initialized to point to the containing `ath10k_usb` object
according to endpoint descriptors read from the device side, as shown
below in `ath10k_usb_setup_pipe_resources`:
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = &iface_desc->endpoint[i].desc;
// get the address from endpoint descriptor
pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
endpoint->bEndpointAddress,
&urbcount);
......
// select the pipe object
pipe = &ar_usb->pipes[pipe_num];
// initialize the ar_usb field
pipe->ar_usb = ar_usb;
}
The driver assumes that the addresses reported in endpoint
descriptors from device side to be complete. If a device is
malicious and does not report complete addresses, it may trigger
NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
`ath10k_usb_free_urb_to_pipe`.
This patch fixes the bug by preventing potential NULL-ptr-deref.
Signed-off-by: Hui Peng <benquike@gmail.com>
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
---
drivers/net/wireless/ath/ath10k/usb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/usb.c b/drivers/net/wireless/ath/ath10k/usb.c
index e1420f67f776..14d86627b47f 100644
--- a/drivers/net/wireless/ath/ath10k/usb.c
+++ b/drivers/net/wireless/ath/ath10k/usb.c
@@ -38,6 +38,10 @@ ath10k_usb_alloc_urb_from_pipe(struct ath10k_usb_pipe *pipe)
struct ath10k_urb_context *urb_context = NULL;
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return NULL;
+
spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
if (!list_empty(&pipe->urb_list_head)) {
urb_context = list_first_entry(&pipe->urb_list_head,
@@ -55,6 +59,10 @@ static void ath10k_usb_free_urb_to_pipe(struct ath10k_usb_pipe *pipe,
{
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return NULL;
+
spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
pipe->urb_cnt++;
--
2.22.0
^ permalink raw reply related
* Re: iw release cadence?
From: Kirtika Ruchandani @ 2019-08-04 22:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: Brian Norris, linux-wireless, npoojary
In-Reply-To: <7179602b12fbcdad6e3c8d71150e647b32b9425b.camel@sipsolutions.net>
On Fri, Feb 1, 2019 at 2:23 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2019-02-01 at 23:18 +0100, Johannes Berg wrote:
> > On Fri, 2019-02-01 at 14:17 -0800, Brian Norris wrote:
> > > On Fri, Feb 1, 2019 at 2:09 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> > > > On Fri, 2019-02-01 at 22:54 +0100, Johannes Berg wrote:
> > > > >
> > > > > I'll just tag one now :-)
> > > >
> > > > Done. I updated a few things and pulled in our FTM support code too, now
> > > > that all the nl80211.h api is upstream.
> > >
> > > Awesome, thanks! Presumably a tarball is on its way?
> >
> > Need to figure out how to use kup again ...
>
> Ok I think I figured it out, but it takes a little while to sync and be
> visible on the public frontend.
>
One more 'I can haz release plz' nag.
Support for 11ax MCS rates and HE stuff came after 5.0.1, and
preferably we should take that with an upstream uprev not local
patches applied on top of 5.0.1?
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/log/
Thanks in advance!
> johannes
>
^ permalink raw reply
* [PATCH 0/3] enable channel survey for mt76u and mt7615
From: Lorenzo Bianconi @ 2019-08-05 6:55 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka, ryder.lee, royluo
Introduce channel survey support for mt76x02u and mt7615 drivers
in order to enable ACS for all of them
Lorenzo Bianconi (3):
mt76: mt76x02u: enable survey support
mt76: mt7603: move survey_time in mt76_dev
mt76: mt7615: enable survey support
drivers/net/wireless/mediatek/mt76/mt76.h | 2 ++
.../net/wireless/mediatek/mt76/mt7603/mac.c | 5 ++--
.../net/wireless/mediatek/mt76/mt7603/main.c | 4 ++--
.../wireless/mediatek/mt76/mt7603/mt7603.h | 1 -
.../net/wireless/mediatek/mt76/mt7615/mac.c | 24 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/main.c | 5 ++++
.../wireless/mediatek/mt76/mt7615/mt7615.h | 1 +
.../net/wireless/mediatek/mt76/mt7615/pci.c | 1 +
.../net/wireless/mediatek/mt76/mt7615/regs.h | 3 +++
.../net/wireless/mediatek/mt76/mt76x0/usb.c | 9 +++++++
.../net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
.../wireless/mediatek/mt76/mt76x2/usb_init.c | 7 ++++++
.../wireless/mediatek/mt76/mt76x2/usb_main.c | 5 ++++
13 files changed, 63 insertions(+), 5 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH 1/3] mt76: mt76x02u: enable survey support
From: Lorenzo Bianconi @ 2019-08-05 6:55 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka, ryder.lee, royluo
In-Reply-To: <cover.1564987866.git.lorenzo@kernel.org>
Introduce channel survey support for mt76x2u and mt76x0u drivers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 9 +++++++++
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c | 7 +++++++
drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c | 5 +++++
4 files changed, 22 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 627ed1fc7b15..927b8bd31f5e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -132,6 +132,7 @@ static const struct ieee80211_ops mt76x0u_ops = {
.set_rts_threshold = mt76x02_set_rts_threshold,
.wake_tx_queue = mt76_wake_tx_queue,
.get_txpower = mt76_get_txpower,
+ .get_survey = mt76_get_survey,
.set_tim = mt76_set_tim,
.release_buffered_frames = mt76_release_buffered_frames,
};
@@ -161,6 +162,13 @@ static int mt76x0u_init_hardware(struct mt76x02_dev *dev)
FIELD_PREP(MT_TXOP_TRUN_EN, 0x3f) |
FIELD_PREP(MT_TXOP_EXT_CCA_DLY, 0x58));
+ mt76_wr(dev, MT_CH_TIME_CFG,
+ MT_CH_TIME_CFG_TIMER_EN |
+ MT_CH_TIME_CFG_TX_AS_BUSY |
+ MT_CH_TIME_CFG_RX_AS_BUSY |
+ MT_CH_TIME_CFG_NAV_AS_BUSY |
+ MT_CH_TIME_CFG_EIFS_AS_BUSY);
+
return 0;
}
@@ -200,6 +208,7 @@ static int mt76x0u_probe(struct usb_interface *usb_intf,
const struct usb_device_id *id)
{
static const struct mt76_driver_ops drv_ops = {
+ .update_survey = mt76x02_update_channel,
.tx_prepare_skb = mt76x02u_tx_prepare_skb,
.tx_complete_skb = mt76x02u_tx_complete_skb,
.tx_status_data = mt76x02_tx_status_data,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index 7a994a783510..2c1e508b4609 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -36,6 +36,7 @@ static int mt76x2u_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
static const struct mt76_driver_ops drv_ops = {
+ .update_survey = mt76x02_update_channel,
.tx_prepare_skb = mt76x02u_tx_prepare_skb,
.tx_complete_skb = mt76x02u_tx_complete_skb,
.tx_status_data = mt76x02_tx_status_data,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
index 94f52f98019b..098f225dac72 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
@@ -195,6 +195,13 @@ int mt76x2u_init_hardware(struct mt76x02_dev *dev)
mt76x02_phy_set_rxpath(dev);
mt76x02_phy_set_txdac(dev);
+ mt76_wr(dev, MT_CH_TIME_CFG,
+ MT_CH_TIME_CFG_TIMER_EN |
+ MT_CH_TIME_CFG_TX_AS_BUSY |
+ MT_CH_TIME_CFG_RX_AS_BUSY |
+ MT_CH_TIME_CFG_NAV_AS_BUSY |
+ MT_CH_TIME_CFG_EIFS_AS_BUSY);
+
return mt76x2u_mac_stop(dev);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index 7e9e44b96671..9933b78c1308 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -59,6 +59,10 @@ mt76x2u_set_channel(struct mt76x02_dev *dev,
err = mt76x2u_phy_set_channel(dev, chandef);
+ /* channel cycle counters read-and-clear */
+ mt76_rr(dev, MT_CH_IDLE);
+ mt76_rr(dev, MT_CH_BUSY);
+
mt76x2_mac_resume(dev);
clear_bit(MT76_RESET, &dev->mt76.state);
@@ -125,6 +129,7 @@ const struct ieee80211_ops mt76x2u_ops = {
.sw_scan_complete = mt76x02_sw_scan_complete,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
.get_txpower = mt76_get_txpower,
+ .get_survey = mt76_get_survey,
.set_tim = mt76_set_tim,
.release_buffered_frames = mt76_release_buffered_frames,
};
--
2.21.0
^ permalink raw reply related
* [PATCH 2/3] mt76: mt7603: move survey_time in mt76_dev
From: Lorenzo Bianconi @ 2019-08-05 6:55 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka, ryder.lee, royluo
In-Reply-To: <cover.1564987866.git.lorenzo@kernel.org>
Move survey_time field in mt76_dev in order to be reused adding survey
support to mt7615 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 2 ++
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 5 +++--
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h | 1 -
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 20f83e5b9337..c755b5ad5e2a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -504,6 +504,8 @@ struct mt76_dev {
u8 csa_complete;
+ ktime_t survey_time;
+
u32 rxfilter;
union {
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
index 81fb4276e742..92dddb765283 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
@@ -1473,8 +1473,9 @@ void mt7603_update_channel(struct mt76_dev *mdev)
spin_lock_bh(&dev->mt76.cc_lock);
cur_time = ktime_get_boottime();
state->cc_busy += busy;
- state->cc_active += ktime_to_us(ktime_sub(cur_time, dev->survey_time));
- dev->survey_time = cur_time;
+ state->cc_active += ktime_to_us(ktime_sub(cur_time,
+ dev->mt76.survey_time));
+ dev->mt76.survey_time = cur_time;
spin_unlock_bh(&dev->mt76.cc_lock);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 88c869002311..750855467f06 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -14,7 +14,7 @@ mt7603_start(struct ieee80211_hw *hw)
struct mt7603_dev *dev = hw->priv;
mt7603_mac_start(dev);
- dev->survey_time = ktime_get_boottime();
+ dev->mt76.survey_time = ktime_get_boottime();
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
mt7603_mac_work(&dev->mt76.mac_work.work);
@@ -182,7 +182,7 @@ mt7603_set_channel(struct mt7603_dev *dev, struct cfg80211_chan_def *def)
mt76_rr(dev, MT_MIB_STAT_PSCCA);
mt7603_cca_stats_reset(dev);
- dev->survey_time = ktime_get_boottime();
+ dev->mt76.survey_time = ktime_get_boottime();
mt7603_init_edcca(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
index 2c6f7b4cf0e9..257300fec4f8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
@@ -116,7 +116,6 @@ struct mt7603_dev {
s8 tx_power_limit;
- ktime_t survey_time;
ktime_t ed_time;
struct mt76_queue q_rx;
--
2.21.0
^ permalink raw reply related
* [PATCH 3/3] mt76: mt7615: enable survey support
From: Lorenzo Bianconi @ 2019-08-05 6:55 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka, ryder.lee, royluo
In-Reply-To: <cover.1564987866.git.lorenzo@kernel.org>
Introduce channel survey support for mt7615 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mac.c | 24 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/main.c | 5 ++++
.../wireless/mediatek/mt76/mt7615/mt7615.h | 1 +
.../net/wireless/mediatek/mt76/mt7615/pci.c | 1 +
.../net/wireless/mediatek/mt76/mt7615/regs.h | 3 +++
5 files changed, 34 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 1ab4a189e5eb..5c7c371840d9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -1237,6 +1237,29 @@ mt7615_mac_scs_check(struct mt7615_dev *dev)
mt7615_mac_set_default_sensitivity(dev);
}
+void mt7615_update_channel(struct mt76_dev *mdev)
+{
+ struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
+ struct mt76_channel_state *state;
+ ktime_t cur_time;
+ u32 busy;
+
+ if (!test_bit(MT76_STATE_RUNNING, &mdev->state))
+ return;
+
+ state = mt76_channel_state(mdev, mdev->chandef.chan);
+ /* TODO: add DBDC support */
+ busy = mt76_get_field(dev, MT_MIB_SDR16(0), MT_MIB_BUSY_MASK);
+
+ spin_lock_bh(&mdev->cc_lock);
+ cur_time = ktime_get_boottime();
+ state->cc_busy += busy;
+ state->cc_active += ktime_to_us(ktime_sub(cur_time,
+ mdev->survey_time));
+ mdev->survey_time = cur_time;
+ spin_unlock_bh(&mdev->cc_lock);
+}
+
void mt7615_mac_work(struct work_struct *work)
{
struct mt7615_dev *dev;
@@ -1245,6 +1268,7 @@ void mt7615_mac_work(struct work_struct *work)
mac_work.work);
mutex_lock(&dev->mt76.mutex);
+ mt7615_update_channel(&dev->mt76);
if (++dev->mac_work_count == 5) {
mt7615_mac_scs_check(dev);
dev->mac_work_count = 0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 6b881e862595..7e263cf1d97d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -16,6 +16,7 @@ static int mt7615_start(struct ieee80211_hw *hw)
{
struct mt7615_dev *dev = hw->priv;
+ dev->mt76.survey_time = ktime_get_boottime();
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mt76.mac_work,
MT7615_WATCHDOG_TIME);
@@ -149,6 +150,9 @@ static int mt7615_set_channel(struct mt7615_dev *dev)
ret = mt7615_dfs_init_radar_detector(dev);
mt7615_mac_cca_stats_reset(dev);
+ dev->mt76.survey_time = ktime_get_boottime();
+ /* TODO: add DBDC support */
+ mt76_rr(dev, MT_MIB_SDR16(0));
out:
clear_bit(MT76_RESET, &dev->mt76.state);
@@ -528,4 +532,5 @@ const struct ieee80211_ops mt7615_ops = {
.release_buffered_frames = mt76_release_buffered_frames,
.get_txpower = mt76_get_txpower,
.channel_switch_beacon = mt7615_channel_switch_beacon,
+ .get_survey = mt76_get_survey,
};
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index c83d1d212ac9..03a8de27d368 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -224,6 +224,7 @@ static inline void mt7615_irq_disable(struct mt7615_dev *dev, u32 mask)
mt76_set_irq_mask(&dev->mt76, MT_INT_MASK_CSR, mask, 0);
}
+void mt7615_update_channel(struct mt76_dev *mdev);
void mt7615_mac_cca_stats_reset(struct mt7615_dev *dev);
void mt7615_mac_set_scs(struct mt7615_dev *dev, bool enable);
int mt7615_mac_write_txwi(struct mt7615_dev *dev, __le32 *txwi,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/pci.c b/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
index 9e82cb53fd60..e250607e0a80 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
@@ -81,6 +81,7 @@ static int mt7615_pci_probe(struct pci_dev *pdev,
.sta_add = mt7615_sta_add,
.sta_assoc = mt7615_sta_assoc,
.sta_remove = mt7615_sta_remove,
+ .update_survey = mt7615_update_channel,
};
struct mt7615_dev *dev;
struct mt76_dev *mdev;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/regs.h b/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
index 12fc12edf78c..b193814d5cf8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
@@ -255,6 +255,9 @@
#define MT_MIB_RTS_RETRIES_COUNT_MASK GENMASK(31, 16)
#define MT_MIB_RTS_COUNT_MASK GENMASK(15, 0)
+#define MT_MIB_SDR16(n) MT_WF_MIB(0x48 + ((n) << 9))
+#define MT_MIB_BUSY_MASK GENMASK(23, 0)
+
#define MT_EFUSE_BASE 0x81070000
#define MT_EFUSE_BASE_CTRL 0x000
#define MT_EFUSE_BASE_CTRL_EMPTY BIT(30)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 01/16] iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41
From: Luca Coelho @ 2019-08-05 9:45 UTC (permalink / raw)
To: Sasha Levin, kvalo; +Cc: linux-wireless, stable
In-Reply-To: <20190720122332.E229E2186A@mail.kernel.org>
On Sat, 2019-07-20 at 12:23 +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.1, v5.1.18, v4.19.59, v4.14.133, v4.9.185, v4.4.185.
>
> v5.2.1: Build OK!
> v5.1.18: Build OK!
> v4.19.59: Build OK!
> v4.14.133: Build OK!
> v4.9.185: Failed to apply! Possible dependencies:
> 1f3706508395 ("iwlwifi: mvm: support unification of INIT and RT images")
> 42ce76d615e7 ("iwlwifi: mvm: spin off SAR profile selection function")
> 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
> 7fe90e0e3d60 ("iwlwifi: mvm: refactor geo init")
> a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
> c386dacb4ed6 ("iwlwifi: mvm: refactor SAR init to prepare for dynamic SAR")
>
> v4.4.185: Failed to apply! Possible dependencies:
> 13555e8ba2f4 ("iwlwifi: mvm: add 9000-series RX API")
> 1a616dd2f171 ("iwlwifi: dump prph registers in a common place for all transports")
> 2f89a5d7d377 ("iwlwifi: mvm: move fw-dbg code to separate file")
> 321c2104f2f1 ("iwlwifi: mvm: Support setting continuous recording debug mode")
> 39bdb17ebb5b ("iwlwifi: update host command messages to new format")
> 42ce76d615e7 ("iwlwifi: mvm: spin off SAR profile selection function")
> 43413a975d06 ("iwlwifi: mvm: support rss queues configuration command")
> 4707fde5cdef ("iwlwifi: mvm: use build-time assertion for fw trigger ID")
> 6c4fbcbc1c95 ("iwlwifi: add support for 12K Receive Buffers")
> 854d773e4ab5 ("iwlwifi: mvm: improve RSS configuration")
> 92fe83430b89 ("iwlwifi: uninline iwl_trans_send_cmd")
> 9e7dce286595 ("iwlwifi: mvm: allow to limit the A-MSDU from debugfs")
> da2830acf15a ("iwlwifi: mvm: read SAR BIOS table from ACPI")
> dcbb4746286a ("iwlwifi: trans: support a callback for ASYNC commands")
> dd4d3161d0f2 ("iwlwifi: mvm: fix RSS key sizing")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
Hi Sasha,
In this specific case, the patch does not have to be applied on 4.9 and
4.4. What is the right way to handle these cases? Should I simply
ignore them, so they won't go into those kernels by default or do you
want me to follow up somehow and let you know that those kernels can be
ignore?
--
Cheers,
Luca.
^ permalink raw reply
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Luca Coelho @ 2019-08-05 9:48 UTC (permalink / raw)
To: Takashi Iwai
Cc: dor.shaish, Josh Boyer, Johannes Berg, Emmanuel Grumbach,
linux-wireless, linux-kernel
In-Reply-To: <s5hmuh7xrqy.wl-tiwai@suse.de>
On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> On Sat, 20 Jul 2019 22:49:33 +0200,
> Luca Coelho wrote:
> > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > Takashi Iwai wrote:
> > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > Luciano Coelho wrote:
> > > > > Adding Dor.
> > > > >
> > > > > Hi Takashi,
> > > > >
> > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > snippet pasted in the bug report.
> > > >
> > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > feel free to join there.
> > >
> > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > >
> >
> > Thanks!
> >
> > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > today. This is the patch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> >
> > It would be great if you can try it out and let us know whether the problem is gone or not.
>
> I created a test package and asked for testing.
> The test result seems negative, showing the same error,
> unfortunately.
>
> The dmesg was uploaded on the bugzilla entry.
Thanks Takashi! We will look into them as soon as possible (sorry for
the late reply, I just came back from vacations).
--
Cheers,
Luca.
^ permalink raw reply
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Luca Coelho @ 2019-08-05 9:53 UTC (permalink / raw)
To: Takashi Iwai
Cc: dor.shaish, Josh Boyer, Johannes Berg, Emmanuel Grumbach,
linux-wireless, linux-kernel
In-Reply-To: <38635c1b10018859457787ecff4f92a3ceec34a4.camel@coelho.fi>
On Mon, 2019-08-05 at 12:48 +0300, Luca Coelho wrote:
> On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> > On Sat, 20 Jul 2019 22:49:33 +0200,
> > Luca Coelho wrote:
> > > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > > Takashi Iwai wrote:
> > > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > > Luciano Coelho wrote:
> > > > > > Adding Dor.
> > > > > >
> > > > > > Hi Takashi,
> > > > > >
> > > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > > snippet pasted in the bug report.
> > > > >
> > > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > > feel free to join there.
> > > >
> > > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > > >
> > >
> > > Thanks!
> > >
> > > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > > today. This is the patch:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> > >
> > > It would be great if you can try it out and let us know whether the problem is gone or not.
> >
> > I created a test package and asked for testing.
> > The test result seems negative, showing the same error,
> > unfortunately.
> >
> > The dmesg was uploaded on the bugzilla entry.
>
> Thanks Takashi! We will look into them as soon as possible (sorry for
> the late reply, I just came back from vacations).
Actually, I just noticed that your bugzilla is closed as "RESOLVED
FIXED". Is this still an issue?
This seems like a mismatch between the WiFi and BT firmwares... And
most likely the same issue as this:
https://bugzilla.kernel.org/show_bug.cgi?id=202163
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-08-05 10:01 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <20190731090927.GA3665@localhost.localdomain>
On Wed, Jul 31, 2019 at 11:09:27AM +0200, Lorenzo Bianconi wrote:
> > On Wed, Jul 31, 2019 at 10:19:58AM +0200, Stanislaw Gruszka wrote:
> > > On Tue, Jul 30, 2019 at 04:55:31PM +0200, Lorenzo Bianconi wrote:
> > > > > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > index 467b28379870..622251faa415 100644
> > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > @@ -170,7 +170,7 @@ static int mt76x02_poll_tx(struct napi_struct *napi, int budget)
> > > > > > > mt76.tx_napi);
> > > > > > > int i;
> > > > > > >
> > > > > > > - mt76x02_mac_poll_tx_status(dev, false);
> > > > > > > + mt76x02_mac_poll_tx_status(dev, true);
> > > > > >
> > > > > > I am not sure if we really need mt76x02_mac_poll_tx_status() here since we run
> > > > > > it in mt76x02_tx_complete_skb() and in mt76x02_tx_tasklet(). Anyway the only
> > > > > > difference doing so is we do not run mt76x02_send_tx_status().
> > > > >
> > > > > I thought this is the problem, but it was my mistake during testing.
> > > > > I tested the above change together with mt76_txq_schedule(dev, txq->ac)
> > > > > change and get wrong impression it fixes the issue. But above change
> > > > > alone does not help.
> > > > >
> > > > > I tried to add some locking to avoid parallel execution of mt76x02_poll_tx()
> > > > > and mt76x02_tx_tasklet(), but it didn't help either. So far only patch
> > > > > originally posted here make the problem gone.
> > > >
> > > > so, in order to be on the same page, if you comment out mt76x02_mac_poll_tx_status()
> > > > in mt76x02_poll_tx() the issue will still occur. The only to 'fix' it is to run
> > > > mt76_txq_schedule_all() in mt76x02_poll_tx(), right?
> > >
> > > Yes.
> >
> > Err, no, I should read more cerfully. It is partiall revert of
> > 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet") :
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> > index 5397827668b9..fefe0ee52584 100644
> > --- a/drivers/net/wireless/mediatek/mt76/tx.c
> > +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> > @@ -598,7 +598,7 @@ void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
> > if (!test_bit(MT76_STATE_RUNNING, &dev->state))
> > return;
> >
> > - tasklet_schedule(&dev->tx_tasklet);
> > + mt76_txq_schedule(dev, txq->ac);
> > }
> > EXPORT_SYMBOL_GPL(mt76_wake_tx_queue);
>
> reviewing the code I think:
>
> - we should not run mt76u_tx_tasklet() from mt76_wake_tx_queue() since we do
> not have tx_napi for usb and it will unnecessary go through tx queue checks.
> We should probably do in mt76_wake_tx_queue() something like:
>
> if (is_mmio())
Adding '&& !is_mt7630()' will solve the problem for MT7630E as well ...
> tasklet_schedule(&dev->tx_tasklet);
> else
> mt76_txq_schedule(dev, txq->ac);
>
> Another solution would be add a status_tasklet that just goes through the tx
> queues receiving the usb tx completion and it schedules the tx_tasklet
> What do you think?
>
> - I guess it does not fix the 76x0e issue but we should just schedule tx queues in
> mt76x02_tx_tasklet() (like it is done for mt7603 and mt7615) and move status
> processing in mt76x02_poll_tx()
... but I think we have bug when do mt76_txq_schedule_all() in
tx_tasklet, because we can schedule on queues that are stoped.
So reverting 41634aa8d6db and then optimize by removing tx_tasklet
for mmio and remove not needed mt76_txq_schedule_all() calls looks
more reasoneble to me.
Stanislaw
^ permalink raw reply
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Takashi Iwai @ 2019-08-05 10:05 UTC (permalink / raw)
To: Luca Coelho
Cc: Takashi Iwai, dor.shaish, Josh Boyer, Johannes Berg,
Emmanuel Grumbach, linux-wireless, linux-kernel
In-Reply-To: <ef32cea91614b9708a474e223f3fbbb85a95501d.camel@coelho.fi>
On Mon, 05 Aug 2019 11:53:33 +0200,
Luca Coelho wrote:
>
> On Mon, 2019-08-05 at 12:48 +0300, Luca Coelho wrote:
> > On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> > > On Sat, 20 Jul 2019 22:49:33 +0200,
> > > Luca Coelho wrote:
> > > > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > > > Takashi Iwai wrote:
> > > > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > > > Luciano Coelho wrote:
> > > > > > > Adding Dor.
> > > > > > >
> > > > > > > Hi Takashi,
> > > > > > >
> > > > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > > > snippet pasted in the bug report.
> > > > > >
> > > > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > > > feel free to join there.
> > > > >
> > > > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > > > >
> > > >
> > > > Thanks!
> > > >
> > > > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > > > today. This is the patch:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> > > >
> > > > It would be great if you can try it out and let us know whether the problem is gone or not.
> > >
> > > I created a test package and asked for testing.
> > > The test result seems negative, showing the same error,
> > > unfortunately.
> > >
> > > The dmesg was uploaded on the bugzilla entry.
> >
> > Thanks Takashi! We will look into them as soon as possible (sorry for
> > the late reply, I just came back from vacations).
>
> Actually, I just noticed that your bugzilla is closed as "RESOLVED
> FIXED". Is this still an issue?
It's "closed" because our package contains the revert.
> This seems like a mismatch between the WiFi and BT firmwares... And
> most likely the same issue as this:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202163
OK, so we need the update of the whole linux-firmware.
I'll refresh the package and ask for testing.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH] mt76: mt76x02u: enable multi-vif support
From: Stanislaw Gruszka @ 2019-08-05 10:09 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <3edec94719a37a58576d530bba05dc629dfef2e0.1564750297.git.lorenzo@kernel.org>
On Fri, Aug 02, 2019 at 04:36:20PM +0200, Lorenzo Bianconi wrote:
> Enable multi-interface support for mt76x02u driver. For the moment
> allow max two concurrent interfaces in order to preserve enough room
> for ps traffic since we are using beacon slots for it.
> I have successfully tested the following configuration:
> - AP + STA
> - AP0 + AP1
The combination that did not work in my testing was STA + STA .
This should be fixed or disabled.
Stanislaw
^ permalink raw reply
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Luca Coelho @ 2019-08-05 10:10 UTC (permalink / raw)
To: Takashi Iwai
Cc: dor.shaish, Josh Boyer, Johannes Berg, Emmanuel Grumbach,
linux-wireless, linux-kernel
In-Reply-To: <s5hsgqgnczv.wl-tiwai@suse.de>
On Mon, 2019-08-05 at 12:05 +0200, Takashi Iwai wrote:
> On Mon, 05 Aug 2019 11:53:33 +0200,
> Luca Coelho wrote:
> > On Mon, 2019-08-05 at 12:48 +0300, Luca Coelho wrote:
> > > On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> > > > On Sat, 20 Jul 2019 22:49:33 +0200,
> > > > Luca Coelho wrote:
> > > > > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > > > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > > > > Takashi Iwai wrote:
> > > > > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > > > > Luciano Coelho wrote:
> > > > > > > > Adding Dor.
> > > > > > > >
> > > > > > > > Hi Takashi,
> > > > > > > >
> > > > > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > > > > snippet pasted in the bug report.
> > > > > > >
> > > > > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > > > > feel free to join there.
> > > > > >
> > > > > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > > > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > > > > today. This is the patch:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> > > > >
> > > > > It would be great if you can try it out and let us know whether the problem is gone or not.
> > > >
> > > > I created a test package and asked for testing.
> > > > The test result seems negative, showing the same error,
> > > > unfortunately.
> > > >
> > > > The dmesg was uploaded on the bugzilla entry.
> > >
> > > Thanks Takashi! We will look into them as soon as possible (sorry for
> > > the late reply, I just came back from vacations).
> >
> > Actually, I just noticed that your bugzilla is closed as "RESOLVED
> > FIXED". Is this still an issue?
>
> It's "closed" because our package contains the revert.
>
> > This seems like a mismatch between the WiFi and BT firmwares... And
> > most likely the same issue as this:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=202163
>
> OK, so we need the update of the whole linux-firmware.
> I'll refresh the package and ask for testing.
I'm not sure the new BT firmware is in linux-firmware yet, since I
don't handle BT stuff. I hope it is.
--
Cheers,
Luca.
^ permalink raw reply
* Re: rt2x00usb warning while channel hopping
From: Stanislaw Gruszka @ 2019-08-05 10:21 UTC (permalink / raw)
To: Sid Hayn; +Cc: helmut.schaa, linux-wireless
In-Reply-To: <CAM0KTbCuryuOTV1LdsEF4LkBHV4cPGpLe9nwA68CVCoDQ-6fkA@mail.gmail.com>
On Thu, Aug 01, 2019 at 12:43:26PM -0400, Sid Hayn wrote:
> While testing wireless-testing kernel for some other fixes, I
> encountered this warning. I have a few different chipsets and drivers
> all channel hopping in monitor mode on the test box, but I get this
> warning from rt2x00 over and over again (lots). I am testing two
> patches from johill on top of wireless testing, I don't believe they
> are causing this, but I'll include them for completeness.
>
> https://patchwork.kernel.org/patch/11063915/
> https://patchwork.kernel.org/patch/11069625/
The way to find out is drop those patches and see if the warning
is still there. But it still can be rt2x00 problem that is only
triggered with those patches, so let's try to debug.
> I'm happy to test anything required, although I will be traveling next
> week which may cause delays.
<snip>
> [ 170.055276] ------------[ cut here ]------------
> [ 170.055305] WARNING: CPU: 3 PID: 5777 at
> rt2x00lib_config.cold.0+0xc/0x2a [rt2x00lib]
This seems to be warning at rt2x00ht_center_channel() in:
for (i = 0; i < spec->num_channels; i++)
if (spec->channels[i].channel == center_channel)
return i;
WARN_ON(1);
return conf->chandef.chan->hw_value;
So looks like we set channel that is not specified in rt2800 channels
table. Not sure at the moment if mac80211 provide wrong channel spec or
rt2x00 do something wrong. Please apply below patch and provide prints.
Stanislaw
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00config.c b/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
index 0ee1813e8453..5f6dadef9f7c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
@@ -185,7 +185,11 @@ static u16 rt2x00ht_center_channel(struct rt2x00_dev *rt2x00dev,
if (spec->channels[i].channel == center_channel)
return i;
- WARN_ON(1);
+ WARN_ONCE(1, "hw_value %d channel %d center_channel %d\n",
+ conf->chandef.chan->hw_value,
+ spec->channels[conf->chandef.chan->hw_value].channel,
+ center_channel);
+
return conf->chandef.chan->hw_value;
}
^ permalink raw reply related
* Re: [PATCH] mt76: mt76x02u: enable multi-vif support
From: Lorenzo Bianconi @ 2019-08-05 11:08 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, Felix Fietkau, linux-wireless
In-Reply-To: <20190805100947.GB17889@redhat.com>
>
> On Fri, Aug 02, 2019 at 04:36:20PM +0200, Lorenzo Bianconi wrote:
> > Enable multi-interface support for mt76x02u driver. For the moment
> > allow max two concurrent interfaces in order to preserve enough room
> > for ps traffic since we are using beacon slots for it.
> > I have successfully tested the following configuration:
> > - AP + STA
> > - AP0 + AP1
>
> The combination that did not work in my testing was STA + STA .
> This should be fixed or disabled.
>
Hi Stanislaw,
I have just tested STA/STA configuration and it works in my setup.
Regards,
Lorenzo
> Stanislaw
>
^ permalink raw reply
* Re: [RFC] mt76: fix tx hung regression on MT7630E
From: Lorenzo Bianconi @ 2019-08-05 11:27 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <20190805100110.GA17889@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5246 bytes --]
> On Wed, Jul 31, 2019 at 11:09:27AM +0200, Lorenzo Bianconi wrote:
> > > On Wed, Jul 31, 2019 at 10:19:58AM +0200, Stanislaw Gruszka wrote:
> > > > On Tue, Jul 30, 2019 at 04:55:31PM +0200, Lorenzo Bianconi wrote:
> > > > > > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > > index 467b28379870..622251faa415 100644
> > > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > > > > @@ -170,7 +170,7 @@ static int mt76x02_poll_tx(struct napi_struct *napi, int budget)
> > > > > > > > mt76.tx_napi);
> > > > > > > > int i;
> > > > > > > >
> > > > > > > > - mt76x02_mac_poll_tx_status(dev, false);
> > > > > > > > + mt76x02_mac_poll_tx_status(dev, true);
> > > > > > >
> > > > > > > I am not sure if we really need mt76x02_mac_poll_tx_status() here since we run
> > > > > > > it in mt76x02_tx_complete_skb() and in mt76x02_tx_tasklet(). Anyway the only
> > > > > > > difference doing so is we do not run mt76x02_send_tx_status().
> > > > > >
> > > > > > I thought this is the problem, but it was my mistake during testing.
> > > > > > I tested the above change together with mt76_txq_schedule(dev, txq->ac)
> > > > > > change and get wrong impression it fixes the issue. But above change
> > > > > > alone does not help.
> > > > > >
> > > > > > I tried to add some locking to avoid parallel execution of mt76x02_poll_tx()
> > > > > > and mt76x02_tx_tasklet(), but it didn't help either. So far only patch
> > > > > > originally posted here make the problem gone.
> > > > >
> > > > > so, in order to be on the same page, if you comment out mt76x02_mac_poll_tx_status()
> > > > > in mt76x02_poll_tx() the issue will still occur. The only to 'fix' it is to run
> > > > > mt76_txq_schedule_all() in mt76x02_poll_tx(), right?
> > > >
> > > > Yes.
> > >
> > > Err, no, I should read more cerfully. It is partiall revert of
> > > 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet") :
> > >
> > > diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> > > index 5397827668b9..fefe0ee52584 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/tx.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> > > @@ -598,7 +598,7 @@ void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
> > > if (!test_bit(MT76_STATE_RUNNING, &dev->state))
> > > return;
> > >
> > > - tasklet_schedule(&dev->tx_tasklet);
> > > + mt76_txq_schedule(dev, txq->ac);
> > > }
> > > EXPORT_SYMBOL_GPL(mt76_wake_tx_queue);
> >
> > reviewing the code I think:
> >
> > - we should not run mt76u_tx_tasklet() from mt76_wake_tx_queue() since we do
> > not have tx_napi for usb and it will unnecessary go through tx queue checks.
> > We should probably do in mt76_wake_tx_queue() something like:
> >
> > if (is_mmio())
>
> Adding '&& !is_mt7630()' will solve the problem for MT7630E as well ...
>
> > tasklet_schedule(&dev->tx_tasklet);
> > else
> > mt76_txq_schedule(dev, txq->ac);
> >
> > Another solution would be add a status_tasklet that just goes through the tx
> > queues receiving the usb tx completion and it schedules the tx_tasklet
> > What do you think?
> >
> > - I guess it does not fix the 76x0e issue but we should just schedule tx queues in
> > mt76x02_tx_tasklet() (like it is done for mt7603 and mt7615) and move status
> > processing in mt76x02_poll_tx()
>
> ... but I think we have bug when do mt76_txq_schedule_all() in
> tx_tasklet, because we can schedule on queues that are stoped.
> So reverting 41634aa8d6db and then optimize by removing tx_tasklet
> for mmio and remove not needed mt76_txq_schedule_all() calls looks
> more reasoneble to me.
schedule a stopped queue seems not harmful at a first glance since we do not
copy pending skbs if we have not enough room in the dma ring. Maybe we can be
more conservative doing something like:
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index d8f61e540bfd..c6482155e5e4 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -346,6 +346,11 @@ mt76_dma_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
goto unmap;
if (q->queued + (tx_info.nbuf + 1) / 2 >= q->ndesc - 1) {
+ if (!q->stopped) {
+ ieee80211_stop_queue(dev->hw,
+ skb_get_queue_mapping(skb));
+ q->stopped = true;
+ }
ret = -ENOMEM;
goto unmap;
}
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 5397827668b9..bd2d34c4f326 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -495,6 +495,9 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
while (1) {
bool empty = false;
+ if (hwq->stopped)
+ break;
+
if (sq->swq_queued >= 4)
break;
Does it fix the issue you are facing?
Regards,
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Luca Coelho @ 2019-08-05 12:03 UTC (permalink / raw)
To: Takashi Iwai
Cc: dor.shaish, Josh Boyer, Johannes Berg, Emmanuel Grumbach,
linux-wireless, linux-kernel
In-Reply-To: <99462e51eda721d5d85d9ea9e2c28da62f8b54f5.camel@coelho.fi>
On Mon, 2019-08-05 at 13:10 +0300, Luca Coelho wrote:
> On Mon, 2019-08-05 at 12:05 +0200, Takashi Iwai wrote:
> > On Mon, 05 Aug 2019 11:53:33 +0200,
> > Luca Coelho wrote:
> > > On Mon, 2019-08-05 at 12:48 +0300, Luca Coelho wrote:
> > > > On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> > > > > On Sat, 20 Jul 2019 22:49:33 +0200,
> > > > > Luca Coelho wrote:
> > > > > > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > > > > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > > > > > Takashi Iwai wrote:
> > > > > > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > > > > > Luciano Coelho wrote:
> > > > > > > > > Adding Dor.
> > > > > > > > >
> > > > > > > > > Hi Takashi,
> > > > > > > > >
> > > > > > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > > > > > snippet pasted in the bug report.
> > > > > > > >
> > > > > > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > > > > > feel free to join there.
> > > > > > >
> > > > > > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > > > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > > > > > >
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > > > > > today. This is the patch:
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> > > > > >
> > > > > > It would be great if you can try it out and let us know whether the problem is gone or not.
> > > > >
> > > > > I created a test package and asked for testing.
> > > > > The test result seems negative, showing the same error,
> > > > > unfortunately.
> > > > >
> > > > > The dmesg was uploaded on the bugzilla entry.
> > > >
> > > > Thanks Takashi! We will look into them as soon as possible (sorry for
> > > > the late reply, I just came back from vacations).
> > >
> > > Actually, I just noticed that your bugzilla is closed as "RESOLVED
> > > FIXED". Is this still an issue?
> >
> > It's "closed" because our package contains the revert.
> >
> > > This seems like a mismatch between the WiFi and BT firmwares... And
> > > most likely the same issue as this:
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=202163
> >
> > OK, so we need the update of the whole linux-firmware.
> > I'll refresh the package and ask for testing.
>
> I'm not sure the new BT firmware is in linux-firmware yet, since I
> don't handle BT stuff. I hope it is.
I just double-checked this and got confirmation that the latest BT
firmware in linux-firmware.git is compatible with the latest WiFi
firmware there as well.
The only caveat is that the machine needs to be cold-booted for it to
work....
But we are taking steps to make sure this will not happen next time
(i.e. for future hardware), by syncing our BT and WiFi firmware
releases.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-08-05 12:39 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <20190805112719.GA12280@localhost.localdomain>
On Mon, Aug 05, 2019 at 01:27:19PM +0200, Lorenzo Bianconi wrote:
> > ... but I think we have bug when do mt76_txq_schedule_all() in
> > tx_tasklet, because we can schedule on queues that are stoped.
> > So reverting 41634aa8d6db and then optimize by removing tx_tasklet
> > for mmio and remove not needed mt76_txq_schedule_all() calls looks
> > more reasoneble to me.
>
> schedule a stopped queue seems not harmful at a first glance since we do not
> copy pending skbs if we have not enough room in the dma ring.
mac80211 stop queues for various other reasons than
IEEE80211_QUEUE_STOP_REASON_DRIVER .
> Maybe we can be
> more conservative doing something like:
>
> diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
> index d8f61e540bfd..c6482155e5e4 100644
> --- a/drivers/net/wireless/mediatek/mt76/dma.c
> +++ b/drivers/net/wireless/mediatek/mt76/dma.c
> @@ -346,6 +346,11 @@ mt76_dma_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
> goto unmap;
>
> if (q->queued + (tx_info.nbuf + 1) / 2 >= q->ndesc - 1) {
> + if (!q->stopped) {
> + ieee80211_stop_queue(dev->hw,
> + skb_get_queue_mapping(skb));
> + q->stopped = true;
> + }
> ret = -ENOMEM;
> goto unmap;
> }
> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> index 5397827668b9..bd2d34c4f326 100644
> --- a/drivers/net/wireless/mediatek/mt76/tx.c
> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> @@ -495,6 +495,9 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
> while (1) {
> bool empty = false;
>
> + if (hwq->stopped)
> + break;
> +
> if (sq->swq_queued >= 4)
> break;
>
> Does it fix the issue you are facing?
I'll not be able to test this patch this week. Will have access to
the hardware next week.
I checeked before, if
'q->queued + (tx_info.nbuf + 1) / 2 >= q->ndesc - 1' is triggered
when MT7630E hangs and it is not. But maybe second part of the patch
will help.
Stanislaw
^ permalink raw reply
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