* Re: [PATCH 00/13] rtlwifi: Replace old-style license info with SPDX form
From: Larry Finger @ 2019-02-09 21:03 UTC (permalink / raw)
To: Joe Perches, kvalo; +Cc: linux-wireless, pkshih
In-Reply-To: <50b60844f3ac435a41ff99a3043ee10133e30870.camel@perches.com>
On 2/8/19 9:00 PM, Joe Perches wrote:
> On Fri, 2019-02-08 at 11:21 -0600, Larry Finger wrote:
>> These patches change all the license information from the old-stype format
>> to the newer SPDX format. There are no code changes.
>
> About some of the removals:
>
>> Copyright(c) 2009-2012 Realtek Corporation.
>
> I believe these copyright markings should _not_ be removed.
I thought I did keep the Copyright information. I have now checked twice to
verify that it was done correctly, and that the original dates were kept. If I
missed any, I have not found that instance. Please let me know which ones you saw.
>
>> - * Contact Information:
>> - * wlanfae <wlanfae@realtek.com
>> - * Realtek Corporation, No. 2, Innovation Road II, Hsinchu Science Park,
>> - * Hsinchu 300, Taiwan.
>
> Why take out the contact information? Is it invalid?
Realtek no longer supplies that info with their latest drivers, thus I removed
it here. That E-mail address is a dummy that people report is never answered - I
have not personally tried it.
Larry
>
>
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-09 20:33 UTC (permalink / raw)
To: Stefan Wahren
Cc: Felix Fietkau, Stanislaw Gruszka, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <165515185.283024.1549744145982@email.ionos.de>
>
> Hi Lorenzo,
>
> > Lorenzo Bianconi <lorenzo.bianconi@redhat.com> hat am 9. Februar 2019 um 19:46 geschrieben:
> >
> >
> > >
> > > Hi,
> > >
> > > as already reported here [1], that there are probing issues of mt76 using TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> > >
> > > I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling mt76 driver) and got the following output after plugin the wifi dongle:
> > >
> > > [ 29.778524] usb 1-1.3: new high-speed USB device number 6 using dwc2
> > > [ 31.794581] usb 1-1.3: reset high-speed USB device number 6 using dwc2
> > > [ 31.919916] mt76x0u 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000
> > > [ 32.304412] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > > [ 32.325724] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > > [ 32.346866] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > > [ 33.410559] mt76x0u 1-1.3:1.0: firmware upload timed out
> > > [ 33.435458] mt76x0u: probe of 1-1.3:1.0 failed with error -110
> > > [ 33.454829] usbcore: registered new interface driver mt76x0u
> > >
> > > I took the firmware files from here [2].
> > >
> > > Btw there is another issue, if i disconnect the wifi dongle during probe i'm getting a endless flood of the following output:
> > >
> > > mt76x0u 1.1.3:1.0: rx urb failed: -71
> > >
> > > Any chance to narrow down these issues?
> >
> > Hi Stefan,
> >
> > could you please test the following series:
> > https://patchwork.kernel.org/cover/10764453/
>
> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
>
Hi Stefan,
is the dongle working properly now? Are you able to connect to your AP?
> > Applying this series I am able to connect to my home AP using an Asus
> > USB-AC51 (mt76x0u) connected to a Raspberry Pi 3 B+.
> > I am running rpi-5.0.y branch of https://github.com/raspberrypi/linux.git
>
> The foundation kernel uses a different USB driver called dwc-otg which make use of FIQ.
>
> Okay, now we only need to find a solution for the "rx urb failed" flood ;-)
Does it happen just if you remove the dongle during probe?
Regards,
Lorenzo
>
> Thank you very much
> Stefan
>
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > [1] - https://marc.info/?l=linux-wireless&m=154875316703367
> > > [2] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-09 20:29 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Stanislaw Gruszka, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <CAJ0CqmXSuNQ_tQOatyKwO9O2KsxqD5NZRQnngOme5PURssiv5Q@mail.gmail.com>
Hi Lorenzo,
> Lorenzo Bianconi <lorenzo.bianconi@redhat.com> hat am 9. Februar 2019 um 19:46 geschrieben:
>
>
> >
> > Hi,
> >
> > as already reported here [1], that there are probing issues of mt76 using TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> >
> > I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling mt76 driver) and got the following output after plugin the wifi dongle:
> >
> > [ 29.778524] usb 1-1.3: new high-speed USB device number 6 using dwc2
> > [ 31.794581] usb 1-1.3: reset high-speed USB device number 6 using dwc2
> > [ 31.919916] mt76x0u 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000
> > [ 32.304412] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > [ 32.325724] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > [ 32.346866] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> > [ 33.410559] mt76x0u 1-1.3:1.0: firmware upload timed out
> > [ 33.435458] mt76x0u: probe of 1-1.3:1.0 failed with error -110
> > [ 33.454829] usbcore: registered new interface driver mt76x0u
> >
> > I took the firmware files from here [2].
> >
> > Btw there is another issue, if i disconnect the wifi dongle during probe i'm getting a endless flood of the following output:
> >
> > mt76x0u 1.1.3:1.0: rx urb failed: -71
> >
> > Any chance to narrow down these issues?
>
> Hi Stefan,
>
> could you please test the following series:
> https://patchwork.kernel.org/cover/10764453/
yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> Applying this series I am able to connect to my home AP using an Asus
> USB-AC51 (mt76x0u) connected to a Raspberry Pi 3 B+.
> I am running rpi-5.0.y branch of https://github.com/raspberrypi/linux.git
The foundation kernel uses a different USB driver called dwc-otg which make use of FIQ.
Okay, now we only need to find a solution for the "rx urb failed" flood ;-)
Thank you very much
Stefan
>
> Regards,
> Lorenzo
>
> >
> > [1] - https://marc.info/?l=linux-wireless&m=154875316703367
> > [2] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-09 18:46 UTC (permalink / raw)
To: Stefan Wahren
Cc: Felix Fietkau, Stanislaw Gruszka, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <2003727085.234456.1549714119945@email.ionos.de>
>
> Hi,
>
> as already reported here [1], that there are probing issues of mt76 using TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
>
> I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling mt76 driver) and got the following output after plugin the wifi dongle:
>
> [ 29.778524] usb 1-1.3: new high-speed USB device number 6 using dwc2
> [ 31.794581] usb 1-1.3: reset high-speed USB device number 6 using dwc2
> [ 31.919916] mt76x0u 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000
> [ 32.304412] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> [ 32.325724] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> [ 32.346866] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
> [ 33.410559] mt76x0u 1-1.3:1.0: firmware upload timed out
> [ 33.435458] mt76x0u: probe of 1-1.3:1.0 failed with error -110
> [ 33.454829] usbcore: registered new interface driver mt76x0u
>
> I took the firmware files from here [2].
>
> Btw there is another issue, if i disconnect the wifi dongle during probe i'm getting a endless flood of the following output:
>
> mt76x0u 1.1.3:1.0: rx urb failed: -71
>
> Any chance to narrow down these issues?
Hi Stefan,
could you please test the following series:
https://patchwork.kernel.org/cover/10764453/
Applying this series I am able to connect to my home AP using an Asus
USB-AC51 (mt76x0u) connected to a Raspberry Pi 3 B+.
I am running rpi-5.0.y branch of https://github.com/raspberrypi/linux.git
Regards,
Lorenzo
>
> [1] - https://marc.info/?l=linux-wireless&m=154875316703367
> [2] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Daniel Golle @ 2019-02-09 17:28 UTC (permalink / raw)
To: Tom Psyborg
Cc: Kalle Valo, Stanislaw Gruszka, linux-wireless, Randy Oostdyk,
Felix Fietkau, Mathias Kresin
In-Reply-To: <CAKR_QVJXaYyy64BBj0qz7-Rua70nKGTypV7uiysCqyR=jG_Adw@mail.gmail.com>
Hi Tom,
On Sat, Feb 09, 2019 at 05:29:33PM +0100, Tom Psyborg wrote:
> On 09/02/2019, Daniel Golle <daniel@makrotopia.org> wrote:
> > Hi Tom,
> >
> > On Sat, Feb 09, 2019 at 01:28:32PM +0100, Tom Psyborg wrote:
> >> On 09/02/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >> > On Sat, Feb 09, 2019 at 12:11:03PM +0100, Tom Psyborg wrote:
> >> >> Can you reproduce interface freeze with this patch if you enable debug
> >> >> options to print all dbg messages?
> >> >
> >> > Haven't tried that, but I expect enabling debug messages will
> >> > cause troubles at hardware where printk make CPU hog.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> Take a look at my comment from 23.01.2019. on this link:
> >> https://bugs.openwrt.org/index.php?do=details&task_id=2018
> >> There might be a chance dbg printks do not cause problems.
> >
> > This is very likely just overheat because of missing TSSI. It happends
> > on boards where MT7620A is used without heatsink (and easy to
> > reproduce, I've tried. We just need TSSI and for bad board design it
> > will mean limiting to one TX-queue soon after serious traffic starts).
> > We should tell those users to glue heatsink on the chip for $0.05 they
> > can fix this in hardware -- and implement TSSI to mitigate at least the
> > very worst effects (such as hardware stuck until reset).
> > So dkg printks can make this worse, of course, because logging overhead
> > also burns CPU cycles and increases system load.
> >
> > I remember in Rt5350 (and other predecessors of Rt6352 aka. MT7620)
> > also had problems like that and it was possible to improve it by all
> > sorts of things like removing power from unused ports of the Ethernet
> > switch -- so for those boards (like Xiaomi MiWiFi mini) even this maybe
> > the trick, because they also only use 3 out of 5 ports, and maybe we
> > need to try harder to disable the power of unused ports (and also those
> > without cable plugged in only periodicly power them up and check for
> > link)....
> >
> > Cheers
> >
> > Daniel
> >
>
> Disagree. MT7620 in Xiaomi MiWiFi mini has thermal pad sticked to
> enough large metal shielding that is sticked with another thermal pad
> to even bigger metal part of case. So thermal dissipation in that case
> is very good.
Good to hear that, and yes it may still be, see below.
> Also with pandorabox firmware 200Mbps of stable throughput is possible
>20MiB/s download rate is very impressive for 2.4GHz WiFi, I never saw
anything even near that (using BitTorrent I get up to 8MiB/s when next
to the router in low-noise environment with proprietry ubiquiti gear).
> without any throttling which I believe would not be the case if the
> cooling system wasn't reliable.
pandorabox uses MediaTek proprietary driver and that limits to single
TX chain operation once temperature limit is hit (read the code, you
know where), same as in Xiaomi proprietary firmware.
>
> Back on subject, this patch is tested and proven to work, so ACK from me.
Thanks for testing. I will push Stanislavs complete series into OpenWrt
tomorrow.
Cheers
Daniel
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Tom Psyborg @ 2019-02-09 16:29 UTC (permalink / raw)
To: Daniel Golle
Cc: Kalle Valo, Stanislaw Gruszka, linux-wireless, Randy Oostdyk,
Felix Fietkau, Mathias Kresin
In-Reply-To: <20190209153850.GA19297@makrotopia.org>
On 09/02/2019, Daniel Golle <daniel@makrotopia.org> wrote:
> Hi Tom,
>
> On Sat, Feb 09, 2019 at 01:28:32PM +0100, Tom Psyborg wrote:
>> On 09/02/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > On Sat, Feb 09, 2019 at 12:11:03PM +0100, Tom Psyborg wrote:
>> >> Can you reproduce interface freeze with this patch if you enable debug
>> >> options to print all dbg messages?
>> >
>> > Haven't tried that, but I expect enabling debug messages will
>> > cause troubles at hardware where printk make CPU hog.
>> >
>> > Stanislaw
>> >
>>
>> Take a look at my comment from 23.01.2019. on this link:
>> https://bugs.openwrt.org/index.php?do=details&task_id=2018
>> There might be a chance dbg printks do not cause problems.
>
> This is very likely just overheat because of missing TSSI. It happends
> on boards where MT7620A is used without heatsink (and easy to
> reproduce, I've tried. We just need TSSI and for bad board design it
> will mean limiting to one TX-queue soon after serious traffic starts).
> We should tell those users to glue heatsink on the chip for $0.05 they
> can fix this in hardware -- and implement TSSI to mitigate at least the
> very worst effects (such as hardware stuck until reset).
> So dkg printks can make this worse, of course, because logging overhead
> also burns CPU cycles and increases system load.
>
> I remember in Rt5350 (and other predecessors of Rt6352 aka. MT7620)
> also had problems like that and it was possible to improve it by all
> sorts of things like removing power from unused ports of the Ethernet
> switch -- so for those boards (like Xiaomi MiWiFi mini) even this maybe
> the trick, because they also only use 3 out of 5 ports, and maybe we
> need to try harder to disable the power of unused ports (and also those
> without cable plugged in only periodicly power them up and check for
> link)....
>
> Cheers
>
> Daniel
>
Disagree. MT7620 in Xiaomi MiWiFi mini has thermal pad sticked to
enough large metal shielding that is sticked with another thermal pad
to even bigger metal part of case. So thermal dissipation in that case
is very good.
Also with pandorabox firmware 200Mbps of stable throughput is possible
without any throttling which I believe would not be the case if the
cooling system wasn't reliable.
Back on subject, this patch is tested and proven to work, so ACK from me.
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Daniel Golle @ 2019-02-09 15:38 UTC (permalink / raw)
To: Tom Psyborg
Cc: Stanislaw Gruszka, linux-wireless, Randy Oostdyk, Felix Fietkau,
Mathias Kresin
In-Reply-To: <CAKR_QVJtQdRcbRMV+WDKw=N2CxLhUSo6hE8mUME2orD6JEMAmQ@mail.gmail.com>
Hi Tom,
On Sat, Feb 09, 2019 at 01:28:32PM +0100, Tom Psyborg wrote:
> On 09/02/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Sat, Feb 09, 2019 at 12:11:03PM +0100, Tom Psyborg wrote:
> >> Can you reproduce interface freeze with this patch if you enable debug
> >> options to print all dbg messages?
> >
> > Haven't tried that, but I expect enabling debug messages will
> > cause troubles at hardware where printk make CPU hog.
> >
> > Stanislaw
> >
>
> Take a look at my comment from 23.01.2019. on this link:
> https://bugs.openwrt.org/index.php?do=details&task_id=2018
> There might be a chance dbg printks do not cause problems.
This is very likely just overheat because of missing TSSI. It happends
on boards where MT7620A is used without heatsink (and easy to
reproduce, I've tried. We just need TSSI and for bad board design it
will mean limiting to one TX-queue soon after serious traffic starts).
We should tell those users to glue heatsink on the chip for $0.05 they
can fix this in hardware -- and implement TSSI to mitigate at least the
very worst effects (such as hardware stuck until reset).
So dkg printks can make this worse, of course, because logging overhead
also burns CPU cycles and increases system load.
I remember in Rt5350 (and other predecessors of Rt6352 aka. MT7620)
also had problems like that and it was possible to improve it by all
sorts of things like removing power from unused ports of the Ethernet
switch -- so for those boards (like Xiaomi MiWiFi mini) even this maybe
the trick, because they also only use 3 out of 5 ports, and maybe we
need to try harder to disable the power of unused ports (and also those
without cable plugged in only periodicly power them up and check for
link)....
Cheers
Daniel
^ permalink raw reply
* [PATCH] mac80211: Honor SW_CRYPTO_CONTROL in AP VLAN mode
From: Alexander Wetzel @ 2019-02-09 14:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, mpubbise, Alexander Wetzel
Restore @SW_CRYPTO_CONTROL when interface is in AP Vlan mode and don't
override driver decision for unicast keys.
Fixes commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
controlled devices"), which should only have allow SW crypto fallback for
group keys.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---
net/mac80211/key.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 4700718e010f..37e372896230 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -167,8 +167,10 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
* The driver doesn't know anything about VLAN interfaces.
* Hence, don't send GTKs for VLAN interfaces to the driver.
*/
- if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
+ if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
+ ret = 1;
goto out_unsupported;
+ }
}
ret = drv_set_key(key->local, SET_KEY, sdata,
@@ -213,11 +215,8 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
/* all of these we can do in software - if driver can */
if (ret == 1)
return 0;
- if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL)) {
- if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
- return 0;
+ if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))
return -EINVAL;
- }
return 0;
default:
return -EINVAL;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Tom Psyborg @ 2019-02-09 12:28 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Randy Oostdyk, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <20190209115628.GA16082@redhat.com>
On 09/02/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Sat, Feb 09, 2019 at 12:11:03PM +0100, Tom Psyborg wrote:
>> Can you reproduce interface freeze with this patch if you enable debug
>> options to print all dbg messages?
>
> Haven't tried that, but I expect enabling debug messages will
> cause troubles at hardware where printk make CPU hog.
>
> Stanislaw
>
Take a look at my comment from 23.01.2019. on this link:
https://bugs.openwrt.org/index.php?do=details&task_id=2018
There might be a chance dbg printks do not cause problems.
^ permalink raw reply
* [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-09 12:08 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka, Doug Anderson,
Minas Harutyunyan
Cc: linux-wireless, linux-usb
Hi,
as already reported here [1], that there are probing issues of mt76 using TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling mt76 driver) and got the following output after plugin the wifi dongle:
[ 29.778524] usb 1-1.3: new high-speed USB device number 6 using dwc2
[ 31.794581] usb 1-1.3: reset high-speed USB device number 6 using dwc2
[ 31.919916] mt76x0u 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 32.304412] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
[ 32.325724] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
[ 32.346866] dwc2 3f980000.usb: dwc2_update_urb_state(): trimming xfer length
[ 33.410559] mt76x0u 1-1.3:1.0: firmware upload timed out
[ 33.435458] mt76x0u: probe of 1-1.3:1.0 failed with error -110
[ 33.454829] usbcore: registered new interface driver mt76x0u
I took the firmware files from here [2].
Btw there is another issue, if i disconnect the wifi dongle during probe i'm getting a endless flood of the following output:
mt76x0u 1.1.3:1.0: rx urb failed: -71
Any chance to narrow down these issues?
[1] - https://marc.info/?l=linux-wireless&m=154875316703367
[2] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Stanislaw Gruszka @ 2019-02-09 11:56 UTC (permalink / raw)
To: Tom Psyborg
Cc: linux-wireless, Randy Oostdyk, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <CAKR_QVK7N_NGFR+_2+6fP5iZ0j3dDbvdxJOQt3Yjwn7DMBUfYA@mail.gmail.com>
On Sat, Feb 09, 2019 at 12:11:03PM +0100, Tom Psyborg wrote:
> Can you reproduce interface freeze with this patch if you enable debug
> options to print all dbg messages?
Haven't tried that, but I expect enabling debug messages will
cause troubles at hardware where printk make CPU hog.
Stanislaw
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Tom Psyborg @ 2019-02-09 11:11 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Randy Oostdyk, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <20190209110259.GA14900@redhat.com>
Can you reproduce interface freeze with this patch if you enable debug
options to print all dbg messages?
^ permalink raw reply
* [RFC/RFT 8/8] rt2x00mmio: remove legacy comment
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Remove comment about fields that ware removed.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h b/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h
index 184a4148b2f8..03e6cdb0b5a4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h
@@ -80,8 +80,6 @@ int rt2x00mmio_regbusy_read(struct rt2x00_dev *rt2x00dev,
*
* @desc: Pointer to device descriptor
* @desc_dma: DMA pointer to &desc.
- * @data: Pointer to device's entry memory.
- * @data_dma: DMA pointer to &data.
*/
struct queue_entry_priv_mmio {
__le32 *desc;
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 7/8] rt2x00: remove not used entry field
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Remove not used any longer queue_entry field and flag.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
index a15bae29917b..20113f861b9e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
@@ -361,7 +361,6 @@ enum queue_entry_flags {
ENTRY_DATA_PENDING,
ENTRY_DATA_IO_FAILED,
ENTRY_DATA_STATUS_PENDING,
- ENTRY_DATA_STATUS_SET,
};
/**
@@ -387,8 +386,6 @@ struct queue_entry {
unsigned int entry_idx;
- u32 status;
-
void *priv_data;
};
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 6/8] rt2x00: remove last_nostatus_check
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
We do not any longer check txstatus timeout from tasklet, so do not need
this optimization.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ---------
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 --
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 1 -
3 files changed, 12 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 745f344521ee..6fdf8b58d25c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1164,15 +1164,6 @@ bool rt2800_txstatus_timeout(struct rt2x00_dev *rt2x00dev)
struct data_queue *queue;
struct queue_entry *entry;
- if (!test_bit(DEVICE_STATE_FLUSHING, &rt2x00dev->flags)) {
- unsigned long tout = msecs_to_jiffies(1000);
-
- if (time_before(jiffies, rt2x00dev->last_nostatus_check + tout))
- return false;
- }
-
- rt2x00dev->last_nostatus_check = jiffies;
-
tx_queue_for_each(rt2x00dev, queue) {
entry = rt2x00queue_get_entry(queue, Q_INDEX_DONE);
if (rt2800_entry_txstatus_timeout(rt2x00dev, entry))
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index 88e0dc803227..247b0248b828 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -986,8 +986,6 @@ struct rt2x00_dev {
*/
DECLARE_KFIFO_PTR(txstatus_fifo, u32);
- unsigned long last_nostatus_check;
-
/*
* Timer to ensure tx status reports are read (rt2800usb).
*/
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 92ddc19e7bf7..6e8beb7ea350 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
@@ -1039,7 +1039,6 @@ void rt2x00queue_start_queues(struct rt2x00_dev *rt2x00dev)
*/
tx_queue_for_each(rt2x00dev, queue)
rt2x00queue_start_queue(queue);
- rt2x00dev->last_nostatus_check = jiffies;
rt2x00queue_start_queue(rt2x00dev->rx);
}
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 5/8] rt2800mmio: use timer and work for handling tx statuses timeouts
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Sometimes we can get into situation when there are pending statuses,
but we do not get INT_SOURCE_CSR_TX_FIFO_STATUS. Handle this situation
by arming timeout timer and read statuses (it will fix case when
we just do not have irq) and queue work to handle case we missed
statues from hardware FIFO.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 81 +++++++++++++++++++++++--
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 4 ++
5 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
index 3d4e37a9854e..ecc4c9332ec7 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
@@ -426,6 +426,9 @@ void rt2800mmio_start_queue(struct data_queue *queue)
}
EXPORT_SYMBOL_GPL(rt2800mmio_start_queue);
+/* 200 ms */
+#define TXSTATUS_TIMEOUT 200000000
+
void rt2800mmio_kick_queue(struct data_queue *queue)
{
struct rt2x00_dev *rt2x00dev = queue->rt2x00dev;
@@ -440,6 +443,8 @@ void rt2800mmio_kick_queue(struct data_queue *queue)
entry = rt2x00queue_get_entry(queue, Q_INDEX);
rt2x00mmio_register_write(rt2x00dev, TX_CTX_IDX(queue->qid),
entry->entry_idx);
+ hrtimer_start(&rt2x00dev->txstatus_timer,
+ TXSTATUS_TIMEOUT, HRTIMER_MODE_REL);
break;
case QID_MGMT:
entry = rt2x00queue_get_entry(queue, Q_INDEX);
@@ -484,12 +489,8 @@ void rt2800mmio_flush_queue(struct data_queue *queue, bool drop)
* For TX queues schedule completion tasklet to catch
* tx status timeouts, othewise just wait.
*/
- if (tx_queue) {
- tasklet_disable(&rt2x00dev->txstatus_tasklet);
- rt2800_txdone(rt2x00dev, UINT_MAX);
- rt2800_txdone_nostatus(rt2x00dev);
- tasklet_enable(&rt2x00dev->txstatus_tasklet);
- }
+ if (tx_queue)
+ queue_work(rt2x00dev->workqueue, &rt2x00dev->txdone_work);
/*
* Wait for a little while to give the driver
@@ -627,6 +628,10 @@ void rt2800mmio_clear_entry(struct queue_entry *entry)
word = rt2x00_desc_read(entry_priv->desc, 1);
rt2x00_set_field32(&word, TXD_W1_DMA_DONE, 1);
rt2x00_desc_write(entry_priv->desc, 1, word);
+
+ /* If last entry stop txstatus timer */
+ if (entry->queue->length == 1)
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
}
}
EXPORT_SYMBOL_GPL(rt2800mmio_clear_entry);
@@ -759,6 +764,70 @@ int rt2800mmio_enable_radio(struct rt2x00_dev *rt2x00dev)
}
EXPORT_SYMBOL_GPL(rt2800mmio_enable_radio);
+static void rt2800mmio_work_txdone(struct work_struct *work)
+{
+ struct rt2x00_dev *rt2x00dev =
+ container_of(work, struct rt2x00_dev, txdone_work);
+
+ if (!test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
+ return;
+
+ while (!kfifo_is_empty(&rt2x00dev->txstatus_fifo) ||
+ rt2800_txstatus_timeout(rt2x00dev)) {
+
+ tasklet_disable(&rt2x00dev->txstatus_tasklet);
+ rt2800_txdone(rt2x00dev, UINT_MAX);
+ rt2800_txdone_nostatus(rt2x00dev);
+ tasklet_enable(&rt2x00dev->txstatus_tasklet);
+ }
+
+ if (rt2800_txstatus_pending(rt2x00dev))
+ hrtimer_start(&rt2x00dev->txstatus_timer,
+ TXSTATUS_TIMEOUT, HRTIMER_MODE_REL);
+}
+
+static enum hrtimer_restart rt2800mmio_tx_sta_fifo_timeout(struct hrtimer *timer)
+{
+ struct rt2x00_dev *rt2x00dev =
+ container_of(timer, struct rt2x00_dev, txstatus_timer);
+
+ if (!test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
+ goto out;
+
+ if (!rt2800_txstatus_pending(rt2x00dev))
+ goto out;
+
+ rt2800mmio_fetch_txstatus(rt2x00dev);
+ if (!kfifo_is_empty(&rt2x00dev->txstatus_fifo))
+ tasklet_schedule(&rt2x00dev->txstatus_tasklet);
+ else
+ queue_work(rt2x00dev->workqueue, &rt2x00dev->txdone_work);
+out:
+ return HRTIMER_NORESTART;
+}
+
+int rt2800mmio_probe_hw(struct rt2x00_dev *rt2x00dev)
+{
+ int retval;
+
+ retval = rt2800_probe_hw(rt2x00dev);
+ if (retval)
+ return retval;
+
+ /*
+ * Set txstatus timer function.
+ */
+ rt2x00dev->txstatus_timer.function = rt2800mmio_tx_sta_fifo_timeout;
+
+ /*
+ * Overwrite TX done handler
+ */
+ INIT_WORK(&rt2x00dev->txdone_work, rt2800mmio_work_txdone);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rt2800mmio_probe_hw);
+
MODULE_AUTHOR(DRV_PROJECT);
MODULE_VERSION(DRV_VERSION);
MODULE_DESCRIPTION("rt2800 MMIO library");
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.h b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.h
index 3a513273f414..ca58e6c3a4e5 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.h
@@ -153,6 +153,7 @@ void rt2800mmio_stop_queue(struct data_queue *queue);
void rt2800mmio_queue_init(struct data_queue *queue);
/* Initialization functions */
+int rt2800mmio_probe_hw(struct rt2x00_dev *rt2x00dev);
bool rt2800mmio_get_entry_state(struct queue_entry *entry);
void rt2800mmio_clear_entry(struct queue_entry *entry);
int rt2800mmio_init_queues(struct rt2x00_dev *rt2x00dev);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800pci.c b/drivers/net/wireless/ralink/rt2x00/rt2800pci.c
index 0291441ac548..43e1b1ee96bf 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800pci.c
@@ -346,7 +346,7 @@ static const struct rt2x00lib_ops rt2800pci_rt2x00_ops = {
.tbtt_tasklet = rt2800mmio_tbtt_tasklet,
.rxdone_tasklet = rt2800mmio_rxdone_tasklet,
.autowake_tasklet = rt2800mmio_autowake_tasklet,
- .probe_hw = rt2800_probe_hw,
+ .probe_hw = rt2800mmio_probe_hw,
.get_firmware_name = rt2800pci_get_firmware_name,
.check_firmware = rt2800_check_firmware,
.load_firmware = rt2800_load_firmware,
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800soc.c b/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
index 05a801774713..cc9c2a1d5916 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
@@ -185,7 +185,7 @@ static const struct rt2x00lib_ops rt2800soc_rt2x00_ops = {
.tbtt_tasklet = rt2800mmio_tbtt_tasklet,
.rxdone_tasklet = rt2800mmio_rxdone_tasklet,
.autowake_tasklet = rt2800mmio_autowake_tasklet,
- .probe_hw = rt2800_probe_hw,
+ .probe_hw = rt2800mmio_probe_hw,
.get_firmware_name = rt2800soc_get_firmware_name,
.check_firmware = rt2800soc_check_firmware,
.load_firmware = rt2800soc_load_firmware,
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 357c0941aaad..bdc55d649a88 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1391,6 +1391,8 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
mutex_init(&rt2x00dev->conf_mutex);
INIT_LIST_HEAD(&rt2x00dev->bar_list);
spin_lock_init(&rt2x00dev->bar_list_lock);
+ hrtimer_init(&rt2x00dev->txstatus_timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
@@ -1515,6 +1517,8 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
+
/*
* Kill the tx status tasklet.
*/
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 4/8] rt2800mmio: fetch tx status changes
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Prepare to use rt2800mmio_fetch_txstatus() in concurrent manner and drop
return value since is not longer needed.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
index f7635a47dbcd..3d4e37a9854e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
@@ -255,12 +255,12 @@ void rt2800mmio_autowake_tasklet(unsigned long data)
}
EXPORT_SYMBOL_GPL(rt2800mmio_autowake_tasklet);
-static bool rt2800mmio_fetch_txstatus(struct rt2x00_dev *rt2x00dev)
+static void rt2800mmio_fetch_txstatus(struct rt2x00_dev *rt2x00dev)
{
u32 status;
- bool more = false;
+ unsigned long flags;
- /* FIXEME: rewrite this comment
+ /*
* The TX_FIFO_STATUS interrupt needs special care. We should
* read TX_STA_FIFO but we should do it immediately as otherwise
* the register can overflow and we would lose status reports.
@@ -271,20 +271,21 @@ static bool rt2800mmio_fetch_txstatus(struct rt2x00_dev *rt2x00dev)
* because we can schedule the tasklet multiple times (when the
* interrupt fires again during tx status processing).
*
- * txstatus tasklet is called with INT_SOURCE_CSR_TX_FIFO_STATUS
- * disabled so have only one producer and one consumer - we don't
- * need to lock the kfifo.
+ * We also read statuses from tx status timeout timer, use
+ * lock to prevent concurent writes to fifo.
*/
+
+ spin_lock_irqsave(&rt2x00dev->irqmask_lock, flags);
+
while (!kfifo_is_full(&rt2x00dev->txstatus_fifo)) {
status = rt2x00mmio_register_read(rt2x00dev, TX_STA_FIFO);
if (!rt2x00_get_field32(status, TX_STA_FIFO_VALID))
break;
kfifo_put(&rt2x00dev->txstatus_fifo, status);
- more = true;
}
- return more;
+ spin_unlock_irqrestore(&rt2x00dev->irqmask_lock, flags);
}
void rt2800mmio_txstatus_tasklet(unsigned long data)
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 3/8] rt2800: move txstatus pending routine
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Move rt2800usb_txstatus_pending routine to rt2800lib. It will be reused
by rt2800mmio code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 17 +++++++++++++++++
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 22 +++-------------------
3 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index fdf7813d9be6..745f344521ee 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1183,6 +1183,23 @@ bool rt2800_txstatus_timeout(struct rt2x00_dev *rt2x00dev)
}
EXPORT_SYMBOL_GPL(rt2800_txstatus_timeout);
+/*
+ * test if there is an entry in any TX queue for which DMA is done
+ * but the TX status has not been returned yet
+ */
+bool rt2800_txstatus_pending(struct rt2x00_dev *rt2x00dev)
+{
+ struct data_queue *queue;
+
+ tx_queue_for_each(rt2x00dev, queue) {
+ if (rt2x00queue_get_entry(queue, Q_INDEX_DMA_DONE) !=
+ rt2x00queue_get_entry(queue, Q_INDEX_DONE))
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(rt2800_txstatus_pending);
+
void rt2800_txdone_nostatus(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue;
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.h b/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
index 506c319070dd..759eab2b70c3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
@@ -198,6 +198,7 @@ void rt2800_txdone_entry(struct queue_entry *entry, u32 status, __le32 *txwi,
void rt2800_txdone(struct rt2x00_dev *rt2x00dev, unsigned int quota);
void rt2800_txdone_nostatus(struct rt2x00_dev *rt2x00dev);
bool rt2800_txstatus_timeout(struct rt2x00_dev *rt2x00dev);
+bool rt2800_txstatus_pending(struct rt2x00_dev *rt2x00dev);
void rt2800_write_beacon(struct queue_entry *entry, struct txentry_desc *txdesc);
void rt2800_clear_beacon(struct queue_entry *entry);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 0bdcab374203..46f2239698a3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -100,22 +100,6 @@ static void rt2800usb_stop_queue(struct data_queue *queue)
}
}
-/*
- * test if there is an entry in any TX queue for which DMA is done
- * but the TX status has not been returned yet
- */
-static bool rt2800usb_txstatus_pending(struct rt2x00_dev *rt2x00dev)
-{
- struct data_queue *queue;
-
- tx_queue_for_each(rt2x00dev, queue) {
- if (rt2x00queue_get_entry(queue, Q_INDEX_DMA_DONE) !=
- rt2x00queue_get_entry(queue, Q_INDEX_DONE))
- return true;
- }
- return false;
-}
-
#define TXSTATUS_READ_INTERVAL 1000000
static bool rt2800usb_tx_sta_fifo_read_completed(struct rt2x00_dev *rt2x00dev,
@@ -145,7 +129,7 @@ static bool rt2800usb_tx_sta_fifo_read_completed(struct rt2x00_dev *rt2x00dev,
if (rt2800_txstatus_timeout(rt2x00dev))
queue_work(rt2x00dev->workqueue, &rt2x00dev->txdone_work);
- if (rt2800usb_txstatus_pending(rt2x00dev)) {
+ if (rt2800_txstatus_pending(rt2x00dev)) {
/* Read register after 1 ms */
hrtimer_start(&rt2x00dev->txstatus_timer,
TXSTATUS_READ_INTERVAL,
@@ -160,7 +144,7 @@ static bool rt2800usb_tx_sta_fifo_read_completed(struct rt2x00_dev *rt2x00dev,
* clear_bit someone could do rt2x00usb_interrupt_txdone, so recheck
* here again if status reading is needed.
*/
- if (rt2800usb_txstatus_pending(rt2x00dev) &&
+ if (rt2800_txstatus_pending(rt2x00dev) &&
!test_and_set_bit(TX_STATUS_READING, &rt2x00dev->flags))
return true;
else
@@ -489,7 +473,7 @@ static void rt2800usb_work_txdone(struct work_struct *work)
* if the medium is busy, thus the TX_STA_FIFO entry is
* also delayed -> use a timer to retrieve it.
*/
- if (rt2800usb_txstatus_pending(rt2x00dev))
+ if (rt2800_txstatus_pending(rt2x00dev))
rt2800usb_async_read_tx_status(rt2x00dev);
}
}
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 2/8] rt2800: new flush implementation for SoC devices
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Use new flush_queue() calback for SoC devices, what was already done for
PCIe devices.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800soc.c b/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
index a502816214ab..05a801774713 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800soc.c
@@ -203,7 +203,7 @@ static const struct rt2x00lib_ops rt2800soc_rt2x00_ops = {
.start_queue = rt2800mmio_start_queue,
.kick_queue = rt2800mmio_kick_queue,
.stop_queue = rt2800mmio_stop_queue,
- .flush_queue = rt2x00mmio_flush_queue,
+ .flush_queue = rt2800mmio_flush_queue,
.write_tx_desc = rt2800mmio_write_tx_desc,
.write_tx_data = rt2800_write_tx_data,
.write_beacon = rt2800_write_beacon,
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 1/8] rt2800: partially restore old mmio txstatus behaviour
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1549710518-15650-1-git-send-email-sgruszka@redhat.com>
Do not disable txstatus interrupt and add quota of processed tx statuses in
one tasklet. Quota is needed to allow to fed device with new frames during
processing of tx statuses.
Patch fixes about 15% performance degradation on some scenarios coused by
0b0d556e0ebb ("rt2800mmio: use txdone/txstatus routines from lib").
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 30 +++++++------------------
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 +-
4 files changed, 12 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 0e95555aec62..fdf7813d9be6 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1100,7 +1100,7 @@ void rt2800_txdone_entry(struct queue_entry *entry, u32 status, __le32 *txwi,
}
EXPORT_SYMBOL_GPL(rt2800_txdone_entry);
-void rt2800_txdone(struct rt2x00_dev *rt2x00dev)
+void rt2800_txdone(struct rt2x00_dev *rt2x00dev, unsigned int quota)
{
struct data_queue *queue;
struct queue_entry *entry;
@@ -1108,7 +1108,7 @@ void rt2800_txdone(struct rt2x00_dev *rt2x00dev)
u8 qid;
bool match;
- while (kfifo_get(&rt2x00dev->txstatus_fifo, ®)) {
+ while (quota-- > 0 && kfifo_get(&rt2x00dev->txstatus_fifo, ®)) {
/*
* TX_STA_FIFO_PID_QUEUE is a 2-bit field, thus qid is
* guaranteed to be one of the TX QIDs .
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.h b/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
index 0dff2c7b3010..506c319070dd 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.h
@@ -195,7 +195,7 @@ void rt2800_process_rxwi(struct queue_entry *entry, struct rxdone_entry_desc *tx
void rt2800_txdone_entry(struct queue_entry *entry, u32 status, __le32 *txwi,
bool match);
-void rt2800_txdone(struct rt2x00_dev *rt2x00dev);
+void rt2800_txdone(struct rt2x00_dev *rt2x00dev, unsigned int quota);
void rt2800_txdone_nostatus(struct rt2x00_dev *rt2x00dev);
bool rt2800_txstatus_timeout(struct rt2x00_dev *rt2x00dev);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
index ddb88cfeace2..f7635a47dbcd 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
@@ -255,20 +255,6 @@ void rt2800mmio_autowake_tasklet(unsigned long data)
}
EXPORT_SYMBOL_GPL(rt2800mmio_autowake_tasklet);
-static void rt2800mmio_txdone(struct rt2x00_dev *rt2x00dev)
-{
- bool timeout = false;
-
- while (!kfifo_is_empty(&rt2x00dev->txstatus_fifo) ||
- (timeout = rt2800_txstatus_timeout(rt2x00dev))) {
-
- rt2800_txdone(rt2x00dev);
-
- if (timeout)
- rt2800_txdone_nostatus(rt2x00dev);
- }
-}
-
static bool rt2800mmio_fetch_txstatus(struct rt2x00_dev *rt2x00dev)
{
u32 status;
@@ -305,14 +291,11 @@ void rt2800mmio_txstatus_tasklet(unsigned long data)
{
struct rt2x00_dev *rt2x00dev = (struct rt2x00_dev *)data;
- do {
- rt2800mmio_txdone(rt2x00dev);
+ rt2800_txdone(rt2x00dev, 16);
- } while (rt2800mmio_fetch_txstatus(rt2x00dev));
+ if (!kfifo_is_empty(&rt2x00dev->txstatus_fifo))
+ tasklet_schedule(&rt2x00dev->txstatus_tasklet);
- if (test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
- rt2800mmio_enable_interrupt(rt2x00dev,
- INT_SOURCE_CSR_TX_FIFO_STATUS);
}
EXPORT_SYMBOL_GPL(rt2800mmio_txstatus_tasklet);
@@ -339,8 +322,10 @@ irqreturn_t rt2800mmio_interrupt(int irq, void *dev_instance)
mask = ~reg;
if (rt2x00_get_field32(reg, INT_SOURCE_CSR_TX_FIFO_STATUS)) {
+ rt2x00_set_field32(&mask, INT_MASK_CSR_TX_FIFO_STATUS, 1);
rt2800mmio_fetch_txstatus(rt2x00dev);
- tasklet_schedule(&rt2x00dev->txstatus_tasklet);
+ if (!kfifo_is_empty(&rt2x00dev->txstatus_fifo))
+ tasklet_schedule(&rt2x00dev->txstatus_tasklet);
}
if (rt2x00_get_field32(reg, INT_SOURCE_CSR_PRE_TBTT))
@@ -500,7 +485,8 @@ void rt2800mmio_flush_queue(struct data_queue *queue, bool drop)
*/
if (tx_queue) {
tasklet_disable(&rt2x00dev->txstatus_tasklet);
- rt2800mmio_txdone(rt2x00dev);
+ rt2800_txdone(rt2x00dev, UINT_MAX);
+ rt2800_txdone_nostatus(rt2x00dev);
tasklet_enable(&rt2x00dev->txstatus_tasklet);
}
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 19eabf16147b..0bdcab374203 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -480,7 +480,7 @@ static void rt2800usb_work_txdone(struct work_struct *work)
while (!kfifo_is_empty(&rt2x00dev->txstatus_fifo) ||
rt2800_txstatus_timeout(rt2x00dev)) {
- rt2800_txdone(rt2x00dev);
+ rt2800_txdone(rt2x00dev, UINT_MAX);
rt2800_txdone_nostatus(rt2x00dev);
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 0/8] rt2x00: performance fixes for mmio
From: Stanislaw Gruszka @ 2019-02-09 11:08 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
Patch series should fix performance regriession and do not reintroduce
tx queue hungs.
Stanislaw Gruszka (8):
rt2800: partially restore old mmio txstatus behaviour
rt2800: new flush implementation for SoC devices
rt2800: move txstatus pending routine
rt2800mmio: fetch tx status changes
rt2800mmio: use timer and work for handling tx statuses timeouts
rt2x00: remove last_nostatus_check
rt2x00: remove not used entry field
rt2x00mmio: remove legacy comment
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 30 ++++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 3 +-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 124 ++++++++++++++++-------
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 4 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 24 +----
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 -
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 4 +
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h | 2 -
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 1 -
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 3 -
12 files changed, 123 insertions(+), 77 deletions(-)
--
2.7.5
^ permalink raw reply
* Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
From: Stanislaw Gruszka @ 2019-02-09 11:03 UTC (permalink / raw)
To: Tom Psyborg
Cc: linux-wireless, Randy Oostdyk, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <20190102081934.GA5300@redhat.com>
On Wed, Jan 02, 2019 at 09:19:34AM +0100, Stanislaw Gruszka wrote:
> On Fri, Dec 28, 2018 at 01:45:27AM +0100, Tom Psyborg wrote:
> > >
> > > I move prints to debug level for for "arrived at non-free entry" from
> > > "Dropping frame due to full tx queue" . For some users those 5 patches
> > > improve things, they fix problem of router connection hung completely.
> > > Printk problem is connection stall due to CPU being busy, but
> > > is possible to reconnect to AP after that. It's different issue.
> > >
> > yes they fix hung. same hung that does this single patch fix by moving
> > to dbg so they're not printed at all. FYI "Dropping frame due to full
> > tx queue" causes "arrived at non-free entry" eventually that freezes
> > interface so only reboot helps, removing "Dropping frame due to full
> > tx queue" from printing to logs prevents this kind of hung and is
> > better solution than 5 patches.
>
> I wonder why are you confident about this ? And also why 5 patches
> fixed the hung if there were still "Dropping frame ..." prints ?
>
> Anyway I'll ask people on the bz for confirmation, if stop printing
> is sufficient to fix the wifi hung.
>
> > oh and don't forget to add note that
> > rt2x00_err/rt2x00_dbg prints can cause serious bug so you don't
> > acidentally enable them again in a year or two!
>
> I think I will remember that, for others git changelog should
> be sufficient.
>
> > > Also 'result in lower throughput' is over-generalized statement. More
> > > precise would be 'it lower throughput on some test cases', but even
> > > in those specific cases, throughput vary randomly with and without
> > > patches.
> > >
> >
> > 100Mbps TX 70Mbps RX without and 80Mbps TX 55 Mbps RX with 5
> > patches--> EA2750 HT40 CH2 4.14.82+4.19-rc5-1-1
>
> Ok, this is different case that you presented before on USB devices.
> And I'm more concerned about it, because changes with MMIO ware
> much bigger (for USB only some code was moved and some flush
> changed were done). Please check attached patch, if it fixes
> throughput regression for you ?
So what is the point complaining that I do not provide patches for
testing and when I do, ignore that ?
Anyway I have now MT7620A device and was capable to reproduce the
performance regression. Will provide patches to fix it and still
prevent tx queues hungs.
Stanislaw
^ permalink raw reply
* [PATCH v2] wireless-regdb: Sync IN with G.S.R. 1048(E), October 2018
From: Felix Fietkau @ 2019-02-09 10:19 UTC (permalink / raw)
To: linux-wireless; +Cc: seth.forshee, Felix Fietkau
From: Felix Fietkau <felix@wiowireless.com>
Add new frequency ranges, increase power, as documented in:
http://wpc.dot.gov.in/WriteReadData/userfiles/License%20Exemption%20in%205%20GHz%20G_S_R_1048(E)%20dated%2022nd%20October,%202018.pdf
Signed-off-by: Felix Fietkau <felix@wiowireless.com>
---
db.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/db.txt b/db.txt
index 66751f0..b8f3faa 100644
--- a/db.txt
+++ b/db.txt
@@ -617,8 +617,10 @@ country IL: DFS-ETSI
country IN:
(2402 - 2482 @ 40), (20)
- (5150 - 5350 @ 160), (23)
- (5725 - 5875 @ 80), (23)
+ (5150 - 5250 @ 80), (30)
+ (5250 - 5350 @ 80), (24)
+ (5470 - 5725 @ 160), (24)
+ (5725 - 5875 @ 80), (30)
country IR: DFS-JP
(2402 - 2482 @ 40), (20)
--
2.17.0
^ permalink raw reply related
* [PATCH] rsi: fix a typo in a debug message
From: Dan Carpenter @ 2019-02-09 9:00 UTC (permalink / raw)
To: Amitkumar Karwar, Prameela Rani Garnepudi
Cc: Siva Rebbagondla, linux-wireless, Kalle Valo, kernel-janitors
There is a \b (backspace) character in the message that wasn't intended.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index aded1ae4fad5..1dbc0fbbef3f 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -285,7 +285,7 @@ static void rsi_mac80211_cancel_hw_scan(struct ieee80211_hw *hw,
common->bgscan_en = false;
info.aborted = false;
ieee80211_scan_completed(adapter->hw, &info);
- rsi_dbg(INFO_ZONE, "Back ground scan cancelled\b\n");
+ rsi_dbg(INFO_ZONE, "Back ground scan cancelled\n");
}
common->hwscan = NULL;
mutex_unlock(&common->mutex);
--
2.17.1
^ permalink raw reply related
* Re: [ath6kl:pending 12/32] drivers/net/wireless/ath/wil6210/txrx.c:341:25: warning: 'rtap' may be used uninitialized in this function
From: Kalle Valo @ 2019-02-09 8:31 UTC (permalink / raw)
To: kbuild test robot; +Cc: Maya Erez, kbuild-all, ath10k, linux-wireless
In-Reply-To: <201902090225.xWQGRZWS%fengguang.wu@intel.com>
+ linux-wireless
kbuild test robot <lkp@intel.com> writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
> head: 6e56895b48f885973e44231cac5f3f39a7068d36
> commit: 18c7c63dcc54feb0e0438ff20b528ea3945d82e0 [12/32] wil6210: remove rtap_include_phy_info module param
> config: xtensa-allyesconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 8.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 18c7c63dcc54feb0e0438ff20b528ea3945d82e0
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=xtensa
>
> Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
>
> All warnings (new ones prefixed by >>):
>
> drivers/net/wireless/ath/wil6210/txrx.c: In function 'wil_vring_reap_rx':
>>> drivers/net/wireless/ath/wil6210/txrx.c:341:25: warning: 'rtap' may be used uninitialized in this function [-Wmaybe-uninitialized]
> rtap->rthdr.it_version = PKTHDR_RADIOTAP_VERSION;
> drivers/net/wireless/ath/wil6210/txrx.c:331:23: note: 'rtap' was declared here
> struct wil6210_rtap *rtap;
> ^~~~
>
> vim +/rtap +341 drivers/net/wireless/ath/wil6210/txrx.c
>
> 304
> 305 /**
> 306 * Adds radiotap header
> 307 *
> 308 * Any error indicated as "Bad FCS"
> 309 *
> 310 * Vendor data for 04:ce:14-1 (Wilocity-1) consists of:
> 311 * - Rx descriptor: 32 bytes
> 312 * - Phy info
> 313 */
> 314 static void wil_rx_add_radiotap_header(struct wil6210_priv *wil,
> 315 struct sk_buff *skb)
> 316 {
> 317 struct wil6210_rtap {
> 318 struct ieee80211_radiotap_header rthdr;
> 319 /* fields should be in the order of bits in rthdr.it_present */
> 320 /* flags */
> 321 u8 flags;
> 322 /* channel */
> 323 __le16 chnl_freq __aligned(2);
> 324 __le16 chnl_flags;
> 325 /* MCS */
> 326 u8 mcs_present;
> 327 u8 mcs_flags;
> 328 u8 mcs_index;
> 329 } __packed;
This is an odd place to define a structure.
> 330 struct vring_rx_desc *d = wil_skb_rxdesc(skb);
> 331 struct wil6210_rtap *rtap;
> 332 int rtap_len = sizeof(struct wil6210_rtap);
> 333 struct ieee80211_channel *ch = wil->monitor_chandef.chan;
> 334
> 335 if (skb_headroom(skb) < rtap_len &&
> 336 pskb_expand_head(skb, rtap_len, 0, GFP_ATOMIC)) {
> 337 wil_err(wil, "Unable to expand headroom to %d\n", rtap_len);
> 338 return;
> 339 }
> 340
> > 341 rtap->rthdr.it_version = PKTHDR_RADIOTAP_VERSION;
Looks like a valid warning to me.
--
Kalle Valo
^ 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