* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Johannes Berg @ 2019-04-16 19:13 UTC (permalink / raw)
To: Herbert Xu
Cc: Toke Høiland-Jørgensen, Arend Van Spriel, Felix Fietkau,
linux-wireless, Eric Dumazet, netdev
In-Reply-To: <20190416131346.u2uolljlrd5t2jro@gondor.apana.org.au>
On Tue, 2019-04-16 at 21:13 +0800, Herbert Xu wrote:
> On Tue, Apr 16, 2019 at 11:39:56AM +0200, Johannes Berg wrote:
> >
> > > not to mention
> > > breaking certain applications that rely on congestion feedback?
> >
> > This I don't understand. The congestion feedback happens through socket
> > buffer space etc. which is still there (as long as nobody sneaks in an
> > skb_orphan() call)
>
> The congestion control happens at two levels. You are right that
> the socket buffer acts as one limit. However, other applications
> may also rely on the TX queue being full as the throttle (by setting
> a sufficiently large socket buffer size).
I'm not sure how they'd even realize this, other than packets getting
dropped? Which of course we do here as well, we didn't invent something
that let's us expand memory arbitrarily ;-)
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Johannes Berg @ 2019-04-16 19:11 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <7338263c-9e01-1559-888f-adcb4b7c8ca1@wetzel-home.de>
On Tue, 2019-04-16 at 20:28 +0200, Alexander Wetzel wrote:
> They can enable the mode when a key with IEEE80211_KEY_FLAG_NO_AUTO_TX
> set
This I agree with.
> and quiet it again as soon as they get a MPDU using the new KeyID.
This isn't true, afaict. You need to be sure that no MPDUs remain using
the old key ID, not just that the new key ID showed up.
> Since switching back to normal doesn't have to be done immediately a
> asyc call from Tx path or even a worker should do the job just fine.
Sure.
> Btw:
> This also means we'll have to update the merged mac80211 Extended Key ID
> support: We can only enable it for cards without HW crypto when they do
> not set AMPDU_AGGREGATION. With the updated userspace these cards will
> start using Extended Key ID with the already merged patches.
I was going to say this is fine, but no, of course not ... we shouldn't
use different key id in the same A-MPDU.
That said, I'd be very surprised if there are any such drivers, except
in corner cases (like loading some drivers like ath9k or iwlwifi with
swcrypto=1 or so)
> Of those only hwsim and brcmsmac seems to support AMPDU and only
> brcmsmac relly needs the fix to not lose some packets when rekeying.
I can't believe that brcmsmac has no HW crypto support?
Anyway, a patch - even if it serves mostly as documentation - would be
most welcome.
> I assume we still have to wait till the API is in mainline (probably
> 5.2) to ask hostapd/wpa_supplicant to merge the patches?
No, mac80211-next is (usually?) good enough.
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: remove iteration in wake_tx_queue
From: Toke Høiland-Jørgensen @ 2019-04-16 19:07 UTC (permalink / raw)
To: Erik Stromdahl, kvalo, linux-wireless, ath10k; +Cc: yiboz
In-Reply-To: <8772dfe6-3f52-05ca-f55a-b7eae14fa7ac@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> On 4/1/19 1:05 PM, Toke Høiland-Jørgensen wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>
>>> Iterating the TX queue and thereby dequeuing all available packets in the
>>> queue could result in performance penalties on some SMP systems.
>>>
>>> The reason for this is most likely that the per-ac lock (active_txq_lock)
>>> in mac80211 will be held by the CPU iterating the current queue.
>>>
>>> This will lock up other CPUs trying to push new messages on the TX
>>> queue.
>>>
>>> Instead of iterating the queue we fetch just one packet at the time,
>>> resulting in minimal starvation of the other CPUs.
>>
>> Did you test this with Felix' patches reducing the time the lock is held
>> in mac80211?
>>
>> -Toke
>>
> Hi Toke,
>
> I am not aware of these patches. Can you please point them out for me?
They've already been merged. Commits dcec1d9bc8a7 and 7ef769459f14 in
mac80211-next :)
-Toke
^ permalink raw reply
* Re: [PATCH] ath10k: remove iteration in wake_tx_queue
From: Erik Stromdahl @ 2019-04-16 18:54 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, kvalo, linux-wireless, ath10k; +Cc: yiboz
In-Reply-To: <87bm1qq92j.fsf@toke.dk>
On 4/1/19 1:05 PM, Toke Høiland-Jørgensen wrote:
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>
>> Iterating the TX queue and thereby dequeuing all available packets in the
>> queue could result in performance penalties on some SMP systems.
>>
>> The reason for this is most likely that the per-ac lock (active_txq_lock)
>> in mac80211 will be held by the CPU iterating the current queue.
>>
>> This will lock up other CPUs trying to push new messages on the TX
>> queue.
>>
>> Instead of iterating the queue we fetch just one packet at the time,
>> resulting in minimal starvation of the other CPUs.
>
> Did you test this with Felix' patches reducing the time the lock is held
> in mac80211?
>
> -Toke
>
Hi Toke,
I am not aware of these patches. Can you please point them out for me?
--
Erik
^ permalink raw reply
* Re: iwlwifi: BUG: unable to handle kernel paging request at ffffc90000e1c808
From: Michal Hocko @ 2019-04-16 18:36 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, linux-wireless
Cc: LKML
In-Reply-To: <20190412094908.GA5223@dhcp22.suse.cz>
On Fri 12-04-19 11:49:08, Michal Hocko wrote:
> On Thu 11-04-19 23:07:20, Michal Hocko wrote:
> > Hi,
> > I have just encountered the following splat with 5.1-rc4. Is this a
> > known problem? Greping throug older logs show that "Error sending SCAN_CFG_CMD"
> > is not new. In older kernels it was followed by "Start IWL Error Log Dump:"
> > but it oopsed now. I was running 5.0 previously. Let me know if you need
> > more information.
>
> FTR It happened again with 5.1.0-rc2-00001-ga3ac7917b730
Is there anything more I can provide to help with this issue. I had to
go back to 5.0 because the system is not really usable after the oops.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Alexander Wetzel @ 2019-04-16 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <91d60fa7ba614c96fe2814375a28802e9165218b.camel@sipsolutions.net>
>> Could we not simply ask (at least) the drivers supporting Extended Key
>> IDs to implement a special for the remote STA invisible A-MPDU "stop" mode?
>> In this new mode each A-MPDU would simply be build out of a single MPDU.
>> We then could keep Block-Ack active and we don't have to tell the remote
>> STA anything about that decision. After all a A-MPDU with only one MPDU
>> is allowed...
>> We then could tell the driver to switch to this mode when installing the
>> new key and out of it again when we have activated the new key for Tx.
>> That should be perfectly fine to run only in the control path and
>> comparable simple to set up, too.
>
> Sounds doable, but I'm still debating if we even should give them a
> signal - they have all the information in a sense, and do we have a good
> idea of when we can go out of this mode again?
Handling that on the Tx path would be tricky, but I you are right:
Drivers should be able to handle that as it is on the control path, too.
They can enable the mode when a key with IEEE80211_KEY_FLAG_NO_AUTO_TX
set and quiet it again as soon as they get a MPDU using the new KeyID.
Since switching back to normal doesn't have to be done immediately a
asyc call from Tx path or even a worker should do the job just fine.
Btw:
This also means we'll have to update the merged mac80211 Extended Key ID
support: We can only enable it for cards without HW crypto when they do
not set AMPDU_AGGREGATION. With the updated userspace these cards will
start using Extended Key ID with the already merged patches.
Drivers which should be able to use Extended Key ID with the two merged
patches seem to be:
admtek/adm8211.c
ath/ar5523/ar5523.c
broadcom/b43legacy/main.c
broadcom/brcm80211/brcmsmac/mac80211_if.c
mac80211_hwsim.c
marvell/libertas_tf/main.c
ralink/rt2x00/rt2400pci.c
ralink/rt2x00/rt2500pci.c
realtek/rtl818x/rtl8180/dev.c
realtek/rtl818x/rtl8187/dev.c
zydas/zd1211rw/zd_mac.c
Of those only hwsim and brcmsmac seems to support AMPDU and only
brcmsmac relly needs the fix to not lose some packets when rekeying.
>> That also sounds like something all drivers supporting A-MPDU should be
>> able to pull off somehow. (But then I've never even looked at more than
>> ath9k and iwlwifi so far for A-MPDU, and at those not close, yet.)
>> Do you see any problems with that solution and/or a better idea?
>
> It ought to be possible, or if not then the device just can't support
> extended key ID?
Agree. Or drivers can decide to deny A-MPDU setup when the key has been
installed with IEEE80211_KEY_FLAG_NO_AUTO_TX when they want.
>> Also would you prefer we first sort out the A-MPDU issue prior I adding
>> test cases to the hostapd/wpa_supplicant or the other way round?
>
> I think adding the code to hostapd/wpa_s is fine - right now we're
> obviously OK since we have no drivers using extended key ID that use
> hardware crypto, and if we have software crypto there's no problem
> either way, even if A-MPDUs are built (which is probably not the case
> for any such drivers anyway.)
>
> In a sense I'd prefer getting the necessary bits and pieces elsewhere in
> the stack upstream first since that's a prerequisite for anyone
> else being able to easily work on this, and that's something we need for
> drivers to pick it up.
Ok:-)
I assume we still have to wait till the API is in mainline (probably
5.2) to ask hostapd/wpa_supplicant to merge the patches?
At the moment I'm planning to get the patches merge ready and posted as
RFC till 5.2 is out. I'm also planing to keep Extended Key ID for Mesh
networks till later, so we can focus on AP/STA.
Alexander
^ permalink raw reply
* Re: [PATCH wireless-drivers] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Gustavo A. R. Silva @ 2019-04-16 16:03 UTC (permalink / raw)
To: Kalle Valo
Cc: Ping-Ke Shih, David S. Miller, linux-wireless, netdev,
linux-kernel, Kees Cook
In-Reply-To: <87ftqi54cx.fsf@kamboji.qca.qualcomm.com>
On 4/16/19 10:58 AM, Kalle Valo wrote:
>>> You have marked this for wireless-drivers but the commit is 2.5 years
>>> old, so I think wireless-drivers-next is more approriate.
>>>
>>
>> Yeah. This can actually be applied to both of them. What I'd like is
>> to have this applied to stable, so I thought wireless-drivers was a
>> more straightforward way.
>
> Sure, makes sense. But I just want to keep the number of patches going
> to wireless-drivers to the minimum, I really want to avoid conflicts as
> much as possible. That's why I'm keeping the bar high for w-d.
>
Yep. I've got it.
I just sent v2:
https://lore.kernel.org/patchwork/patch/1062748/
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH wireless-drivers] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Kalle Valo @ 2019-04-16 15:58 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Ping-Ke Shih, David S. Miller, linux-wireless, netdev,
linux-kernel, Kees Cook
In-Reply-To: <90c56883-6ef3-9f9e-5231-6c2fc65d747d@embeddedor.com>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
> On 4/15/19 10:36 PM, Kalle Valo wrote:
>> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
>>
>>> Add missing break statement in order to prevent the code from falling
>>> through to case 0x1025, and erroneously setting rtlhal->oem_id to
>>> RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
>>> none of the cases in switch (rtlefuse->eeprom_smid) match.
>>>
>>> This bug was found thanks to the ongoing efforts to enable
>>> -Wimplicit-fallthrough.
>>>
>>> Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>
>> You have marked this for wireless-drivers but the commit is 2.5 years
>> old, so I think wireless-drivers-next is more approriate.
>>
>
> Yeah. This can actually be applied to both of them. What I'd like is
> to have this applied to stable, so I thought wireless-drivers was a
> more straightforward way.
Sure, makes sense. But I just want to keep the number of patches going
to wireless-drivers to the minimum, I really want to avoid conflicts as
much as possible. That's why I'm keeping the bar high for w-d.
> Anyway, I'll update the tag and respin.
Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH wireless-drivers] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Gustavo A. R. Silva @ 2019-04-16 15:08 UTC (permalink / raw)
To: Kalle Valo
Cc: Ping-Ke Shih, David S. Miller, linux-wireless, netdev,
linux-kernel, Kees Cook
In-Reply-To: <87h8ay8vu9.fsf@kamboji.qca.qualcomm.com>
On 4/15/19 10:36 PM, Kalle Valo wrote:
> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
>
>> Add missing break statement in order to prevent the code from falling
>> through to case 0x1025, and erroneously setting rtlhal->oem_id to
>> RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
>> none of the cases in switch (rtlefuse->eeprom_smid) match.
>>
>> This bug was found thanks to the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> You have marked this for wireless-drivers but the commit is 2.5 years
> old, so I think wireless-drivers-next is more approriate.
>
Yeah. This can actually be applied to both of them. What I'd like is
to have this applied to stable, so I thought wireless-drivers was a
more straightforward way.
Anyway, I'll update the tag and respin.
Thanks
--
Gustavo
^ permalink raw reply
* [PATCH v2 wireless-drivers-next] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Gustavo A. R. Silva @ 2019-04-16 15:17 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S. Miller, Larry Finger
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva,
Kees Cook
Add missing break statement in order to prevent the code from falling
through to case 0x1025, and erroneously setting rtlhal->oem_id to
RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
none of the cases in switch (rtlefuse->eeprom_smid) match.
This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.
Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
Changes in v2:
- Update tag from wireless-drivers to wireless-drivers-next
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index 6bab162e1bb8..655460f61bbc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -1675,6 +1675,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
rtlhal->oem_id = RT_CID_819X_LENOVO;
break;
}
+ break;
case 0x1025:
rtlhal->oem_id = RT_CID_819X_ACER;
break;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-16 13:18 UTC (permalink / raw)
To: Herbert Xu, Johannes Berg
Cc: Arend Van Spriel, Felix Fietkau, linux-wireless, Eric Dumazet,
netdev
In-Reply-To: <20190416131346.u2uolljlrd5t2jro@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Apr 16, 2019 at 11:39:56AM +0200, Johannes Berg wrote:
>>
>> > not to mention
>> > breaking certain applications that rely on congestion feedback?
>>
>> This I don't understand. The congestion feedback happens through socket
>> buffer space etc. which is still there (as long as nobody sneaks in an
>> skb_orphan() call)
>
> The congestion control happens at two levels. You are right that the
> socket buffer acts as one limit. However, other applications may also
> rely on the TX queue being full as the throttle (by setting a
> sufficiently large socket buffer size).
Do you happen to have an example of an application that does this that
could be used for testing? :)
-Toke
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-16 13:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Toke Høiland-Jørgensen, Arend Van Spriel, Felix Fietkau,
linux-wireless, Eric Dumazet, netdev
In-Reply-To: <e4c1a3ca0c0c160b7c271ab83deebcf096f38497.camel@sipsolutions.net>
On Tue, Apr 16, 2019 at 11:39:56AM +0200, Johannes Berg wrote:
>
> > not to mention
> > breaking certain applications that rely on congestion feedback?
>
> This I don't understand. The congestion feedback happens through socket
> buffer space etc. which is still there (as long as nobody sneaks in an
> skb_orphan() call)
The congestion control happens at two levels. You are right that
the socket buffer acts as one limit. However, other applications
may also rely on the TX queue being full as the throttle (by setting
a sufficiently large socket buffer size).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context.
From: Greg Kroah-Hartman @ 2019-04-16 11:15 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: Adham Abozaeid, Ajay Singh, linux-wireless
In-Reply-To: <1554641923-11503-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Sun, Apr 07, 2019 at 09:58:43PM +0900, Tetsuo Handa wrote:
> Since wilc_set_multicast_list() is called with dev->addr_list_lock
> spinlock held, we can't use GFP_KERNEL memory allocation.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Fixes: e624c58cf8eb5116 ("staging: wilc1000: refactor code to avoid use of wilc_set_multicast_list global")
No need for so many sha1 characters, this is the canonical length to
use:
e624c58cf8eb
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-16 10:02 UTC (permalink / raw)
To: Johannes Berg, Herbert Xu
Cc: Arend Van Spriel, Felix Fietkau, linux-wireless, Eric Dumazet,
netdev
In-Reply-To: <e4c1a3ca0c0c160b7c271ab83deebcf096f38497.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2019-04-16 at 17:37 +0800, Herbert Xu wrote:
>> On Tue, Apr 16, 2019 at 11:33:50AM +0200, Johannes Berg wrote:
>> > On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
>> > >
>> > > > It is true because we have an entire buffering layer in mac80211 (in
>> > > > this case at least) and never push back to the stack.
>> > >
>> > > I'm wondering if we should be?
>> >
>> > I don't think so? We'd just buffer packets in yet another place.
>>
>> But you do realise that you're giving up on the rich queueing
>> functionality that Linux provides (net/sched),
>
> Yes, that was a trade-off we always knew about. The model that Linux
> provides is just not suited for wifi.
As explained at great length here:
https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen
(you already know that of course, Johannes)
>> not to mention
>> breaking certain applications that rely on congestion feedback?
>
> This I don't understand. The congestion feedback happens through socket
> buffer space etc. which is still there (as long as nobody sneaks in an
> skb_orphan() call)
Sure, for TCP, the TSQ mechanism should keep the upper-level queue low
as long as the SKBs are alive. But is this also the case for UDP?
-Toke
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Johannes Berg @ 2019-04-16 9:39 UTC (permalink / raw)
To: Herbert Xu
Cc: Toke Høiland-Jørgensen, Arend Van Spriel, Felix Fietkau,
linux-wireless, Eric Dumazet, netdev
In-Reply-To: <20190416093707.dtlwcmitzqopaeaw@gondor.apana.org.au>
On Tue, 2019-04-16 at 17:37 +0800, Herbert Xu wrote:
> On Tue, Apr 16, 2019 at 11:33:50AM +0200, Johannes Berg wrote:
> > On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
> > >
> > > > It is true because we have an entire buffering layer in mac80211 (in
> > > > this case at least) and never push back to the stack.
> > >
> > > I'm wondering if we should be?
> >
> > I don't think so? We'd just buffer packets in yet another place.
>
> But you do realise that you're giving up on the rich queueing
> functionality that Linux provides (net/sched),
Yes, that was a trade-off we always knew about. The model that Linux
provides is just not suited for wifi.
> not to mention
> breaking certain applications that rely on congestion feedback?
This I don't understand. The congestion feedback happens through socket
buffer space etc. which is still there (as long as nobody sneaks in an
skb_orphan() call)
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-16 9:38 UTC (permalink / raw)
To: Johannes Berg, Herbert Xu, Arend Van Spriel
Cc: Felix Fietkau, linux-wireless, Eric Dumazet
In-Reply-To: <95f86cf69dee05a176625925657cf0df0e97b5c9.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
>>
>> > It is true because we have an entire buffering layer in mac80211 (in
>> > this case at least) and never push back to the stack.
>>
>> I'm wondering if we should be?
>
> I don't think so? We'd just buffer packets in yet another place.
Wouldn't we get pushback all the way to the application socket? I.e.,
an UDP application would get sendto() failures?
-Toke
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-16 9:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Toke Høiland-Jørgensen, Arend Van Spriel, Felix Fietkau,
linux-wireless, Eric Dumazet, netdev
In-Reply-To: <95f86cf69dee05a176625925657cf0df0e97b5c9.camel@sipsolutions.net>
On Tue, Apr 16, 2019 at 11:33:50AM +0200, Johannes Berg wrote:
> On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
> >
> > > It is true because we have an entire buffering layer in mac80211 (in
> > > this case at least) and never push back to the stack.
> >
> > I'm wondering if we should be?
>
> I don't think so? We'd just buffer packets in yet another place.
But you do realise that you're giving up on the rich queueing
functionality that Linux provides (net/sched), not to mention
breaking certain applications that rely on congestion feedback?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Johannes Berg @ 2019-04-16 9:33 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Herbert Xu, Arend Van Spriel
Cc: Felix Fietkau, linux-wireless, Eric Dumazet
In-Reply-To: <87ef62uwfm.fsf@toke.dk>
On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
>
> > It is true because we have an entire buffering layer in mac80211 (in
> > this case at least) and never push back to the stack.
>
> I'm wondering if we should be?
I don't think so? We'd just buffer packets in yet another place.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-16 9:33 UTC (permalink / raw)
To: Johannes Berg, Herbert Xu, Arend Van Spriel
Cc: Felix Fietkau, linux-wireless, Eric Dumazet
In-Reply-To: <eab39dd804405854997e50102f3d0ff925feb8d2.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2019-04-16 at 16:36 +0800, Herbert Xu wrote:
>> On Tue, Apr 16, 2019 at 10:04:24AM +0200, Arend Van Spriel wrote:
>> >
>> > I was just writing up an email clarifying my question. But let me summarize
>> > this email thread. The patch from Felix adds this flag in mac80211 for
>> > drivers that indicate to support pulling packets from the internal TXQ in
>> > mac80211. I found it is deprecated, but as Felix mentioned it is used in
>> > various parts of the network subsystem, ie. batman-adv, bridge, vlan, tunnel
>> > implementations. So its use seems to be restricted rather than deprecated.
>> > Given your response above I guess my question would be to get details about
>> > what you call "proper design" as I think you are saying with that it is not
>> > needed, right?
>>
>> Essentially the only time it would be OK to use LLTX in its current
>> form is if you have no TX queue/congestion feedback which is clearly
>> not the case with wireless drivers.
>
> It is true because we have an entire buffering layer in mac80211 (in
> this case at least) and never push back to the stack.
I'm wondering if we should be? For instance, fq_codel returns
NET_XMIT_CN if it drops a packet from the same flow that it enqueued to.
We could conceivably do the same in mac80211, although we'd have to
carry the return value out through quite a few layers. Not sure if this
is worth it?
Eric, do you have any insight into what impact the _CN return has from
fq_codel?
-Toke
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Johannes Berg @ 2019-04-16 9:31 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <577d4307-27ca-c5f5-8814-bbef515559e3@wetzel-home.de>
On Mon, 2019-04-15 at 22:09 +0200, Alexander Wetzel wrote:
> Honestly I don't like my own patch for the KeyId border signal, too
> complex and not intuitive at all. But I wanted to have some code for
> discussion and then got carried away a bit in what may have been not the
> right direction.
:-)
> Could we not simply ask (at least) the drivers supporting Extended Key
> IDs to implement a special for the remote STA invisible A-MPDU "stop" mode?
> In this new mode each A-MPDU would simply be build out of a single MPDU.
> We then could keep Block-Ack active and we don't have to tell the remote
> STA anything about that decision. After all a A-MPDU with only one MPDU
> is allowed...
> We then could tell the driver to switch to this mode when installing the
> new key and out of it again when we have activated the new key for Tx.
> That should be perfectly fine to run only in the control path and
> comparable simple to set up, too.
Sounds doable, but I'm still debating if we even should give them a
signal - they have all the information in a sense, and do we have a good
idea of when we can go out of this mode again?
(FWIW, I'd probably call it "suspend" and "resume" or so)
> That also sounds like something all drivers supporting A-MPDU should be
> able to pull off somehow. (But then I've never even looked at more than
> ath9k and iwlwifi so far for A-MPDU, and at those not close, yet.)
> Do you see any problems with that solution and/or a better idea?
It ought to be possible, or if not then the device just can't support
extended key ID?
> Also would you prefer we first sort out the A-MPDU issue prior I adding
> test cases to the hostapd/wpa_supplicant or the other way round?
I think adding the code to hostapd/wpa_s is fine - right now we're
obviously OK since we have no drivers using extended key ID that use
hardware crypto, and if we have software crypto there's no problem
either way, even if A-MPDUs are built (which is probably not the case
for any such drivers anyway.)
In a sense I'd prefer getting the necessary bits and pieces elsewhere in
the stack upstream first since that's a prerequisite for anyone
else being able to easily work on this, and that's something we need for
drivers to pick it up.
johannes
^ permalink raw reply
* Re: [RFC 3/3] mt76x02: remove bogus mutex usage
From: Lorenzo Bianconi @ 2019-04-16 9:29 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <20190416091305.4218-4-sgruszka@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4053 bytes --]
> mac .start(), .stop() callbacks are never called concurrently with other
> mac callbacks. The only concurencly is with mt76 works which we cancel
> on stop() and schedule on start().
>
> This fixes possible deadlock on cancel_delayed_work_sync(&dev->mac_work)
> as mac_work also take mutex.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> .../net/wireless/mediatek/mt76/mt76x0/pci.c | 6 -----
> .../net/wireless/mediatek/mt76/mt76x0/usb.c | 22 +++++--------------
> .../wireless/mediatek/mt76/mt76x2/pci_main.c | 5 -----
> .../wireless/mediatek/mt76/mt76x2/usb_main.c | 10 ++-------
> 4 files changed, 7 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> index 156d3d064ba0..ac979128386a 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> @@ -25,8 +25,6 @@ static int mt76x0e_start(struct ieee80211_hw *hw)
> {
> struct mt76x02_dev *dev = hw->priv;
>
> - mutex_lock(&dev->mt76.mutex);
> -
> mt76x02_mac_start(dev);
> mt76x0_phy_calibrate(dev, true);
> ieee80211_queue_delayed_work(dev->mt76.hw, &dev->mac_work,
> @@ -35,8 +33,6 @@ static int mt76x0e_start(struct ieee80211_hw *hw)
> MT_CALIBRATE_INTERVAL);
> set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
>
> - mutex_unlock(&dev->mt76.mutex);
> -
> return 0;
> }
>
> @@ -62,10 +58,8 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
> {
> struct mt76x02_dev *dev = hw->priv;
>
> - mutex_lock(&dev->mt76.mutex);
> clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
> mt76x0e_stop_hw(dev);
> - mutex_unlock(&dev->mt76.mutex);
> }
>
> static void
[..]
> static const struct ieee80211_ops mt76x0u_ops = {
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> index 16dc8e2451b5..1b5caabebff5 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> @@ -22,8 +22,6 @@ mt76x2_start(struct ieee80211_hw *hw)
> struct mt76x02_dev *dev = hw->priv;
> int ret;
>
> - mutex_lock(&dev->mt76.mutex);
> -
> ret = mt76x2_mac_start(dev);
> if (ret)
> goto out;
You can remove goto here and just return ret (same below)
> @@ -40,7 +38,6 @@ mt76x2_start(struct ieee80211_hw *hw)
> set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
>
> out:
> - mutex_unlock(&dev->mt76.mutex);
> return ret;
> }
>
> @@ -49,10 +46,8 @@ mt76x2_stop(struct ieee80211_hw *hw)
> {
> struct mt76x02_dev *dev = hw->priv;
>
> - mutex_lock(&dev->mt76.mutex);
> clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
> mt76x2_stop_hardware(dev);
> - mutex_unlock(&dev->mt76.mutex);
> }
>
> static int
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
> index 0771de210c6a..32726b4906ea 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
> @@ -21,30 +21,24 @@ static int mt76x2u_start(struct ieee80211_hw *hw)
> struct mt76x02_dev *dev = hw->priv;
> int ret;
>
> - mutex_lock(&dev->mt76.mutex);
> -
> ret = mt76x2u_mac_start(dev);
> if (ret)
> - goto out;
> + return ret;
>
> ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mac_work,
> MT_MAC_WORK_INTERVAL);
> set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
>
> -out:
> - mutex_unlock(&dev->mt76.mutex);
> - return ret;
> + return 0;
> }
>
> static void mt76x2u_stop(struct ieee80211_hw *hw)
> {
> struct mt76x02_dev *dev = hw->priv;
>
> - mutex_lock(&dev->mt76.mutex);
> clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
> mt76u_stop_tx(&dev->mt76);
> mt76x2u_stop_hw(dev);
> - mutex_unlock(&dev->mt76.mutex);
> }
>
> static int
> --
> 2.20.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-16 9:29 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, Toke Høiland-Jørgensen, Felix Fietkau,
linux-wireless, netdev
In-Reply-To: <cd0715bb-b75c-63b0-0ae4-858d14afd500@broadcom.com>
On Tue, Apr 16, 2019 at 11:17:53AM +0200, Arend Van Spriel wrote:
> On 4/16/2019 10:37 AM, Johannes Berg wrote:
> > It is true because we have an entire buffering layer in mac80211 (in
> > this case at least) and never push back to the stack.
>
> Ok, so the crux is the "never push back to the stack" part? Well, the
> internal TXQ and how that is used is obviously enabling that ;-)
So assuming that these drivers all have a TX queue length of zero
and therefore do not make use of Linux queueing disciplines then
yes techincally LLTX is fine.
However, I must say that it is much better to provide real
congestion feedback to the stack when you can because otherwise
things like UDP may fall apart.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ath10k: add support for simulate crash on SDIO chip
From: Wen Gong @ 2019-04-16 9:27 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The command to simulate firmware crash:
echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
CPU interrupt status register for SDIO chip, ath10k driver need to
configure it while enable SDIO interrupt, otherwise ath10k driver will
not get the assert error info.
After this change, it will success for simulate firmware crash.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..60521ed 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -1095,6 +1095,7 @@ struct ath10k_hw_ops {
#define MBOX_CPU_INT_STATUS_ENABLE_ADDRESS 0x00000819
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_LSB 0
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_MASK 0x000000ff
+#define MBOX_CPU_STATUS_ENABLE_ASSERT_MASK 0x00000001
#define MBOX_ERROR_STATUS_ENABLE_ADDRESS 0x0000081a
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_LSB 1
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_MASK 0x00000002
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index fae56c6..78a2f3b 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -850,6 +850,8 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
out:
mutex_unlock(&irq_data->mtx);
+ ath10k_err(ar, "firmware crashed!\n");
+ queue_work(ar->workqueue, &ar->restart_work);
return ret;
}
@@ -1495,8 +1497,10 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k *ar)
regs->int_status_en |=
FIELD_PREP(MBOX_INT_STATUS_ENABLE_MBOX_DATA_MASK, 1);
- /* Set up the CPU Interrupt status Register */
- regs->cpu_int_status_en = 0;
+ /* Set up the CPU Interrupt Status Register, enable CPU sourced interrupt #0
+ * #0 is used for report assertion from target
+ */
+ regs->cpu_int_status_en = FIELD_PREP(MBOX_CPU_STATUS_ENABLE_ASSERT_MASK, 1);
/* Set up the Error Interrupt status Register */
regs->err_int_status_en =
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Arend Van Spriel @ 2019-04-16 9:17 UTC (permalink / raw)
To: Johannes Berg, Herbert Xu
Cc: Toke Høiland-Jørgensen, Felix Fietkau, linux-wireless
In-Reply-To: <eab39dd804405854997e50102f3d0ff925feb8d2.camel@sipsolutions.net>
On 4/16/2019 10:37 AM, Johannes Berg wrote:
> On Tue, 2019-04-16 at 16:36 +0800, Herbert Xu wrote:
>> On Tue, Apr 16, 2019 at 10:04:24AM +0200, Arend Van Spriel wrote:
>>>
>>> I was just writing up an email clarifying my question. But let me summarize
>>> this email thread. The patch from Felix adds this flag in mac80211 for
>>> drivers that indicate to support pulling packets from the internal TXQ in
>>> mac80211. I found it is deprecated, but as Felix mentioned it is used in
>>> various parts of the network subsystem, ie. batman-adv, bridge, vlan, tunnel
>>> implementations. So its use seems to be restricted rather than deprecated.
>>> Given your response above I guess my question would be to get details about
>>> what you call "proper design" as I think you are saying with that it is not
>>> needed, right?
>>
>> Essentially the only time it would be OK to use LLTX in its current
>> form is if you have no TX queue/congestion feedback which is clearly
>> not the case with wireless drivers.
>
> It is true because we have an entire buffering layer in mac80211 (in
> this case at least) and never push back to the stack.
Ok, so the crux is the "never push back to the stack" part? Well, the
internal TXQ and how that is used is obviously enabling that ;-)
Regards,
Arend
^ permalink raw reply
* [RFC 3/3] mt76x02: remove bogus mutex usage
From: Stanislaw Gruszka @ 2019-04-16 9:13 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi
In-Reply-To: <20190416091305.4218-1-sgruszka@redhat.com>
mac .start(), .stop() callbacks are never called concurrently with other
mac callbacks. The only concurencly is with mt76 works which we cancel
on stop() and schedule on start().
This fixes possible deadlock on cancel_delayed_work_sync(&dev->mac_work)
as mac_work also take mutex.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
.../net/wireless/mediatek/mt76/mt76x0/pci.c | 6 -----
.../net/wireless/mediatek/mt76/mt76x0/usb.c | 22 +++++--------------
.../wireless/mediatek/mt76/mt76x2/pci_main.c | 5 -----
.../wireless/mediatek/mt76/mt76x2/usb_main.c | 10 ++-------
4 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index 156d3d064ba0..ac979128386a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -25,8 +25,6 @@ static int mt76x0e_start(struct ieee80211_hw *hw)
{
struct mt76x02_dev *dev = hw->priv;
- mutex_lock(&dev->mt76.mutex);
-
mt76x02_mac_start(dev);
mt76x0_phy_calibrate(dev, true);
ieee80211_queue_delayed_work(dev->mt76.hw, &dev->mac_work,
@@ -35,8 +33,6 @@ static int mt76x0e_start(struct ieee80211_hw *hw)
MT_CALIBRATE_INTERVAL);
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
- mutex_unlock(&dev->mt76.mutex);
-
return 0;
}
@@ -62,10 +58,8 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
{
struct mt76x02_dev *dev = hw->priv;
- mutex_lock(&dev->mt76.mutex);
clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
mt76x0e_stop_hw(dev);
- mutex_unlock(&dev->mt76.mutex);
}
static void
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 22c10722019d..494b9f35f80d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -81,8 +81,10 @@ static void mt76x0u_cleanup(struct mt76x02_dev *dev)
mt76u_queues_deinit(&dev->mt76);
}
-static void mt76x0u_mac_stop(struct mt76x02_dev *dev)
+static void mt76x0u_stop(struct ieee80211_hw *hw)
{
+ struct mt76x02_dev *dev = hw->priv;
+
clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
cancel_delayed_work_sync(&dev->cal_work);
cancel_delayed_work_sync(&dev->mac_work);
@@ -106,11 +108,9 @@ static int mt76x0u_start(struct ieee80211_hw *hw)
struct mt76x02_dev *dev = hw->priv;
int ret;
- mutex_lock(&dev->mt76.mutex);
-
ret = mt76x0_mac_start(dev);
if (ret)
- goto out;
+ return ret;
mt76x0_phy_calibrate(dev, true);
ieee80211_queue_delayed_work(dev->mt76.hw, &dev->mac_work,
@@ -118,19 +118,7 @@ static int mt76x0u_start(struct ieee80211_hw *hw)
ieee80211_queue_delayed_work(dev->mt76.hw, &dev->cal_work,
MT_CALIBRATE_INTERVAL);
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
-
-out:
- mutex_unlock(&dev->mt76.mutex);
- return ret;
-}
-
-static void mt76x0u_stop(struct ieee80211_hw *hw)
-{
- struct mt76x02_dev *dev = hw->priv;
-
- mutex_lock(&dev->mt76.mutex);
- mt76x0u_mac_stop(dev);
- mutex_unlock(&dev->mt76.mutex);
+ return 0;
}
static const struct ieee80211_ops mt76x0u_ops = {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
index 16dc8e2451b5..1b5caabebff5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
@@ -22,8 +22,6 @@ mt76x2_start(struct ieee80211_hw *hw)
struct mt76x02_dev *dev = hw->priv;
int ret;
- mutex_lock(&dev->mt76.mutex);
-
ret = mt76x2_mac_start(dev);
if (ret)
goto out;
@@ -40,7 +38,6 @@ mt76x2_start(struct ieee80211_hw *hw)
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
out:
- mutex_unlock(&dev->mt76.mutex);
return ret;
}
@@ -49,10 +46,8 @@ mt76x2_stop(struct ieee80211_hw *hw)
{
struct mt76x02_dev *dev = hw->priv;
- mutex_lock(&dev->mt76.mutex);
clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
mt76x2_stop_hardware(dev);
- mutex_unlock(&dev->mt76.mutex);
}
static int
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index 0771de210c6a..32726b4906ea 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -21,30 +21,24 @@ static int mt76x2u_start(struct ieee80211_hw *hw)
struct mt76x02_dev *dev = hw->priv;
int ret;
- mutex_lock(&dev->mt76.mutex);
-
ret = mt76x2u_mac_start(dev);
if (ret)
- goto out;
+ return ret;
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mac_work,
MT_MAC_WORK_INTERVAL);
set_bit(MT76_STATE_RUNNING, &dev->mt76.state);
-out:
- mutex_unlock(&dev->mt76.mutex);
- return ret;
+ return 0;
}
static void mt76x2u_stop(struct ieee80211_hw *hw)
{
struct mt76x02_dev *dev = hw->priv;
- mutex_lock(&dev->mt76.mutex);
clear_bit(MT76_STATE_RUNNING, &dev->mt76.state);
mt76u_stop_tx(&dev->mt76);
mt76x2u_stop_hw(dev);
- mutex_unlock(&dev->mt76.mutex);
}
static int
--
2.20.1
^ 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