On Tue, Oct 15, 2019 at 05:16:43PM +0200, Lorenzo Bianconi wrote:
> Read busy counters not holding cc_lock spinlock since usb read can't be
> performed in interrupt context. Move cc_active and cc_rx counters out of
> cc_lock since they are not modified in interrupt context.
> Grab cc_lock updating
On Tue, Oct 01, 2019 at 10:06:29PM +0200, Johannes Berg wrote:
> index f1cdcd61c54a..b74e758cce09 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -10489,7 +10489,7 @@ int rt2800_ampdu_action(struct ieee80211_hw *hw,
> struct
sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable
> hardware
> sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - Device
> failed to enter state 4 (-5)
>
> Unable to bring up the network interface here.
This most likely is the problem int
Initialize last_reset variable to INITIAL_JIFFIES, otherwise it is not
possible to test H/W reset for first 5 minutes of system run.
Fixes: e403fa31ed71 ("rt2x00: add restart hw")
Reported-and-tested-by: Jonathan Liu
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ral
nchuk
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index c9b957ac5733..b2bfa
On Thu, Aug 29, 2019 at 12:42:44PM +0300, Sergey Maranchuk wrote:
> I got some problem after upgrade kernel to 5.2 version (debian testing
> linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
> Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
> 5Ghz - 53dBm !, for lon
do not nullify initialization vector data")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wirel
On Fri, Aug 23, 2019 at 11:27:41AM +0200, Felix Fietkau wrote:
> On 2019-08-23 10:52, Stanislaw Gruszka wrote:
> > Waking tx queues will cause that txq's will be scheduled. Calling
> > mt76_txq_schedule_all() while queues are blocked is not necessary.
> > We w
n the moment after channel switch or other situation
when we wake up queues).
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 1 -
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 -
dr
We allways return 0 from mt76x0_phy_set_channel(), no need to pass
return value upward.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 13 -
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 4 ++--
drivers/net/wireless/mediatek/mt76
We set dev->mt76.chandef in mt76_set_channel() already.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/ph
Stanislaw Gruszka (3):
mt76: remove redundant mt76_txq_schedule_all
mt76: mt76x0: remove redundant chandef copy
mt76: mt76x0: remove unneeded return value on set channel
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 1 -
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2
mt76_rx_convert() not need to be exported any longer.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 3 +--
drivers/net/wireless/mediatek/mt76/mt76.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek
when connecting with iwlwifi devices. But currently possibly due
to reacent changes in rt2x00 removing the flag has no effect on
those test cases.
So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 ---
1 file
On Fri, Jul 12, 2019 at 12:32:28PM +0200, Stanislaw Gruszka wrote:
> According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
> to be used when we do not receive BA (BlockAck). However on rt2x00 we
> use it when remote station fail to decode one or more subframes within
>
On Thu, Aug 22, 2019 at 01:50:52PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> > > Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> > > since we just need retry_q length to notify mac80211 to reschedule the
> > > curren
On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> since we just need retry_q length to notify mac80211 to reschedule the
> current tx queue
>
> Signed-off-by: Lorenzo Bianconi
> ---
> drivers/net/wireless/med
On Wed, Aug 21, 2019 at 12:40:14PM +0200, Felix Fietkau wrote:
> On 2019-08-21 11:03, Felix Fietkau wrote:
> > On 2019-08-21 10:47, Stanislaw Gruszka wrote:
> >> On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
> >>> > Can you test if disabling
On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
> > Can you test if disabling hw encryption only for shared or only for
> > pairwise keys makes any difference?
>
> Disabling only pairwise keys helps. Disabling only shared keys does
> not help.
>
&g
On Wed, Aug 21, 2019 at 03:43:05AM +0530, Balakrishna Bandi wrote:
> Added rt2x00 queue flush fix and beacon frames checks.
Please post separate patch for each issue and provide
more descriptive information about the changes, especially
what problems are intended to solve.
> diff --git a/drivers/
On Tue, Aug 20, 2019 at 01:20:50PM +0200, Fredrik Noring wrote:
> Hi Stanislaw,
>
> Commit 710e6cc1595e ("rt2800: do not nullify initialization vector data")
> breaks USB device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070
> Wireless Adapter. No particular error messages are produced,
On Tue, Aug 20, 2019 at 12:31:56PM +0200, Felix Fietkau wrote:
> >> >> void mt76x0e_wake_tx_queue(struct ieee80211_hw *hw, struct
> >> >> ieee80211_txq *txq)
> >> >> {
> >> >> if (is_mt7630(dev)) {
> >> >> mt76_txq_schedule(dev, txq->ac);
> >> >> } else {
> >> >>
Patch fixes AP mode regression.
Reported-and-tested-by: Emil Karlson
Fixes: 710e6cc1595e ("rt2800: do not nullify initialization vector data")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 +
drivers/net/wireless/ralink/rt2x00/r
On Thu, Aug 15, 2019 at 12:20:54PM +0200, Felix Fietkau wrote:
> On 2019-08-15 12:09, Stanislaw Gruszka wrote:
> >> Hi Stanislaw,
> >>
> >> Can you please try if disabling/enabling the tx tasklet during hw key
> >> configuration fix
On Fri, Aug 16, 2019 at 11:00:12AM +0300, Emil Karlson wrote:
> Greetings
>
> On Wed, 14 Aug 2019 10:50:19 +0200
> Stanislaw Gruszka wrote:
>
> > (cc linux-wireless mailing list)
> >
> > On Tue, Aug 13, 2019 at 09:50:00PM +0300, Emil Karlson wrote:
> > &
cryption as fix for the issue.
> >
> > Fixes: 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> > Signed-off-by: Stanislaw Gruszka
> > ---
> > drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++-
> > 1 file changed, 14 insertions(
On Tue, Aug 13, 2019 at 05:55:26PM +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.8,
(cc linux-wireless mailing list)
On Tue, Aug 13, 2019 at 09:50:00PM +0300, Emil Karlson wrote:
> Greetings
>
> After upgrading my ap running rt2800usb to linux-5.3-rc1 I noticed an
> unusual problem of not being able to connect to my ap with my android
> devices (nexus7/flo and nexus5x/bullhead),
band for MT7630E .
Cc: sta...@vger.kernel.org
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
ince issue is a firmware hang, that is super
hard to debug, just disable HW encryption as fix for the issue.
Fixes: 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++-
1 fi
On Mon, Aug 05, 2019 at 02:39:16PM +0200, Stanislaw Gruszka wrote:
> On Mon, Aug 05, 2019 at 01:27:19PM +0200, Lorenzo Bianconi wrote:
> > > ... but I think we have bug when do mt76_txq_schedule_all() in
> > > tx_tasklet, because we can schedule on queues that are stope
> > This should be fixed or disabled.
> >
>
> Hi Stanislaw,
>
> I have just tested STA/STA configuration and it works in my setup.
Confirmed, it works for me as well on current code base.
Tested-by: Stanislaw Gruszka
On Mon, Aug 05, 2019 at 01:27:19PM +0200, Lorenzo Bianconi wrote:
> > ... but I think we have bug when do mt76_txq_schedule_all() in
> > tx_tasklet, because we can schedule on queues that are stoped.
> > So reverting 41634aa8d6db and then optimize by removing tx_tasklet
> > for mmio and remove not
On Thu, Aug 01, 2019 at 12:43:26PM -0400, Sid Hayn wrote:
> While testing wireless-testing kernel for some other fixes, I
> encountered this warning. I have a few different chipsets and drivers
> all channel hopping in monitor mode on the test box, but I get this
> warning from rt2x00 over and ove
On Fri, Aug 02, 2019 at 04:36:20PM +0200, Lorenzo Bianconi wrote:
> Enable multi-interface support for mt76x02u driver. For the moment
> allow max two concurrent interfaces in order to preserve enough room
> for ps traffic since we are using beacon slots for it.
> I have successfully tested the fol
On Wed, Jul 31, 2019 at 11:09:27AM +0200, Lorenzo Bianconi wrote:
> > On Wed, Jul 31, 2019 at 10:19:58AM +0200, Stanislaw Gruszka wrote:
> > > On Tue, Jul 30, 2019 at 04:55:31PM +0200, Lorenzo Bianconi wrote:
> > > > > > > diff --git a/drivers/net/w
On Wed, Jul 31, 2019 at 10:19:58AM +0200, Stanislaw Gruszka wrote:
> On Tue, Jul 30, 2019 at 04:55:31PM +0200, Lorenzo Bianconi wrote:
> > > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > > b/drivers/net/wireless/mediatek/mt
On Tue, Jul 30, 2019 at 04:55:31PM +0200, Lorenzo Bianconi wrote:
> > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > > > index 467b28379870..622251faa415 100644
> > > > --- a/drivers/net/wireless/mediatek/mt76/mt76
On Mon, Jul 29, 2019 at 04:02:41PM +0200, Lorenzo Bianconi wrote:
> > On Fri, Jul 26, 2019 at 02:10:56PM +0200, Stanislaw Gruszka wrote:
> > > Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> > > I can observe firmware hangs o
On Tue, Jul 30, 2019 at 03:13:35AM +, Tony Chuang wrote:
> > Those coex response skb buffers are allocated in rtw_pci_rx_isr(),
> > but I do not see where they are freed (seems we do not process
> > them in c2h_work which does dev_kfree_skb()).
>
> You're right, that SKB leaked. Should free th
On Fri, Jul 26, 2019 at 02:10:56PM +0200, Stanislaw Gruszka wrote:
> Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> I can observe firmware hangs on MT7630E on station mode: tx stop
> functioning after minor activity (rx keep working) and on module
>
On Thu, Jul 25, 2019 at 10:53:31AM +0800, yhchu...@realtek.com wrote:
> +static struct sk_buff *rtw_coex_info_request(struct rtw_dev *rtwdev,
> + struct rtw_coex_info_req *req)
> +{
> + struct rtw_coex *coex = &rtwdev->coex;
> + struct sk_buff *skb_r
registers programming (or assuring proper order
of actions), but so far I can not came up with any better fix than
a partial revert of 41634aa8d6db.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
Hi
On Mon, Jul 22, 2019 at 06:40:20PM +0200, Johannes Stezenbach wrote:
> I met failure to resume from suspend to RAM with v5.1.19
> and TP-Link Archer T2UH connected to my PC (Asus P8H77-V).
> I tried about a dozen times while trying to figure out the reason,
> the issue happened every time.
> Ev
On Fri, Jul 19, 2019 at 12:45:23AM +, Sasha Levin wrote:
> v5.1.18: Failed to apply! Possible dependencies:
> Unable to calculate
>
> v4.19.59: Failed to apply! Possible dependencies:
> How should we proceed with this patch?
I'll provide backported version of the patch for 4.19 and 5.1
.
This can be avoided, if we do not perform mt76x0_chip_onoff() reset.
Cc: sta...@vger.kernel.org
Fixes: 134b2d0d1fcf ("mt76x0: init files")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
There is no point to use pointer to params->ssn.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt7601u/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/main.c
b/drivers/net/wireless/mediatek/mt7601u/mai
There is no point to use pointer to params->ssn.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
b/drivers/net/wireless/media
There is no point to use pointer to params->ssn.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
b/drivers/net/wireless/mediatek/m
There is no point to use pointer to params->ssn.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
b/drivers/net/wireless/mediatek/m
problems with some buggy
clients. Do not sent BAR on PS wakeup since we lack all PS handling
code what mt76 has.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 1 +
drivers/net/wireless/ralink/rt2x00
On Thu, Jul 04, 2019 at 01:06:52PM +0200, Stanislaw Gruszka wrote:
> According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
> to be used when we do not recive BA (BlockAck). However on rt2x00 we
> use it when remote station fail to decode one or more subframes within
>
In contrast to mt76_wr() which we use to program registers,
on mt76_wr_copy() we should not change endian of the data.
Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
1 file changed, 2
Fix endian bug and do some minor optimizations in mt76u_{copy,rr,wr} .
v1 -> v2:
- drop patch 3
- fix pointer size in patch 1
Stanislaw Gruszka (2):
mt76: usb: fix endian in mt76u_copy
mt76: usb: remove unneeded {put,get}_unaligned
drivers/net/wireless/mediatek/mt76/mt76.h |
Compiler give us guaranties on variables alignment, so use
an variable as buffer when read/write registers and remove
unneeded {put,get}_unaligned.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76.h | 5 -
drivers/net/wireless/mediatek/mt76/usb.c | 8
2
On Tue, Jul 02, 2019 at 05:06:01PM +0200, Stanislaw Gruszka wrote:
> Instead of use several 4 bytes usb requests, use full 32 bytes buffer
> to copy data to device. With the change we use less requests and copy
> exact data size to the device regardless size is multiple of 4 or not.
And
On Tue, Jul 02, 2019 at 05:05:59PM +0200, Stanislaw Gruszka wrote:
> In contrast to mt76_wr() which we use to program registers,
> on mt76_wr_copy() we should not change endian of the data.
>
> Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
> Signed-
(for AP) like mt76 does.
But I do not understand for what this is needed.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
b/drivers/net/wireless/ralink/rt2x00
#x27;t need to save the individual debugfs files and
> directories, remove the local storage of them and just remove the entire
> debugfs directory in a single call, making things a lot simpler.
>
> Cc: Stanislaw Gruszka
> Cc: Helmut Schaa
> Cc: Kalle Valo
> Cc: "David
7;t need to save the individual debugfs files and
> directories, remove the local storage of them and just remove the entire
> debugfs directory in a single call, making things a lot simpler.
>
> Cc: Stanislaw Gruszka
> Cc: Helmut Schaa
> Cc: Kalle Valo
> Cc: "David S. Mill
On Mon, Jul 01, 2019 at 07:25:16PM +0500, Andrej Surkov wrote:
> Hi!
>
> Do you aware of rtl8xxxu do not work until suspend/resume issue?
>
> On my laptop, see below for details, after reboot wifi-menu tool shows one
> single wifi network found and can't connect to it, but after 'sudo systemctl
Instead of use several 4 bytes usb requests, use full 32 bytes buffer
to copy data to device. With the change we use less requests and copy
exact data size to the device regardless size is multiple of 4 or not.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/usb.c | 19
In contrast to mt76_wr() which we use to program registers,
on mt76_wr_copy() we should not change endian of the data.
Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
1 file changed, 2
mt76_wr_copy
Stanislaw Gruszka (3):
mt76: usb: fix endian in mt76u_copy
mt76: usb: remove unneeded {put,get}_unaligned
mt76: usb: use full intermediate buffer in mt76u_copy
drivers/net/wireless/mediatek/mt76/mt76.h | 5 -
drivers/net/wireless/mediatek/mt76/usb.c | 27
Compiler give us guaranties on variables alignment, so use
an variable as buffer when read/write registers and remove
unneeded {put,get}_unaligned.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76.h | 5 -
drivers/net/wireless/mediatek/mt76/usb.c | 8
2
Add ieee80211_restart_hw() to watchdog and debugfs file for testing
if restart works as expected.
Signed-off-by: Stanislaw Gruszka
---
.../net/wireless/ralink/rt2x00/rt2800lib.c| 4 +++
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 7
.../net/wireless/ralink/rt2x00/rt2x00debug.c
Make watchdog disabled by default and add module parameter to enable it.
User will have to create file in /etc/modprobe.d/ with
options rt2800lib watchdog=1
to enable the watchdog or load "rt2800lib watchdog=1" module manually
before loading rt2800{soc,pci,usb} module.
Signed-off-by:
If we restart hw we should keep existing IV (initialization vector)
otherwise HW encryption will be broken after restart.
Also fix some coding style issues on the way.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 -
1 file changed, 4
indexes from registers directly. What
will be used by watchdog.
Signed-off-by: Stanislaw Gruszka
---
.../net/wireless/ralink/rt2x00/rt2800lib.h| 8 +
.../net/wireless/ralink/rt2x00/rt2800mmio.c | 31 +++
.../net/wireless/ralink/rt2x00/rt2800mmio.h | 2 ++
.../net
Allow subdriver to change watchdog interval by intialize
link->watchdog_interval value before rt2x00link_register().
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 13 +
2 files chan
Add watchdog to address some remaining problems of Ralink devices
random hungs.
RFC -> v1
- better description for module parameter
- fix white space
v1 -> v2:
- rebase on latest tree.
Stanislaw Gruszka (7):
rt2x00: allow to specify watchdog interval
rt2800: add helpers for readi
Add watchdog for rt2800 devices. For now it only detect hung
and print error.
[Note: I verified that printing messages from process context is
fine on MT7620 (WT3020) platform that have problem when printk
is called from interrupt context].
Signed-off-by: Stanislaw Gruszka
---
.../net/wireless
Add routine to cleanup interfaces data before hw reset as
ieee80211_restart_hw() will do setup interfaces again.
Signed-off-by: Stanislaw Gruszka
---
.../net/wireless/ralink/rt2x00/rt2800lib.c| 19 +++
.../net/wireless/ralink/rt2x00/rt2800lib.h| 1 +
.../net/wireless
On Fri, Jun 14, 2019 at 02:46:36PM +0200, Lorenzo Bianconi wrote:
> > >
> > > ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> > >
> > > >
> > > > > + int i, data_size;
> > > > >
> > > > > + data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > > > +
On Fri, Jun 14, 2019 at 12:20:59PM +0200, Johannes Berg wrote:
> On Fri, 2019-06-14 at 12:11 +0200, Lorenzo Bianconi wrote:
>
> > Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen
> > +
> > 8, thx :)
> > In our case reuse_frag is true in __ieee80211_amsdu_copy, so we wil
On Fri, Jun 14, 2019 at 12:11:17PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> > > Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> > > for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> > > rece
On Fri, Jun 14, 2019 at 12:22:48PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> > > Set usb buffer size taking into account skb_shared_info in order to
> > > not always copy the first part of received frames if A-MSDU is enabled
> > > for SG
On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> Set usb buffer size taking into account skb_shared_info in order to
> not always copy the first part of received frames if A-MSDU is enabled
> for SG capable devices. Moreover align usb buffer size to max_ep
> boundaries and set bu
On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> receive frames up to q->buf_size but they will be discarded in
> mt76u_process_rx_entr
On Wed, Jun 12, 2019 at 04:44:01PM +0200, Lorenzo Bianconi wrote:
> On Jun 12, Stanislaw Gruszka wrote:
> > On Wed, Jun 12, 2019 at 02:59:05PM +0200, Stanislaw Gruszka wrote:
> > > > > If max RX AMSDU size is 3839B I do not see reason why we allocate
> > > > >
On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lorenzo Bianconi wrote:
> > On Wed, Jun 12, 2019 at 02:28:48PM +0200, Lorenzo Bianconi wrote:
>
> [...]
>
> > >
> > > using sg buffers we can support bigger rx AMSDU size in the future
> > > without using
> > > huge buffers (e.g. we can try to use IEEE8
Hi
On Thu, Jun 13, 2019 at 10:26:38AM +0200, Lorenzo Bianconi wrote:
> [...]
>
> > I looked at intel wifi drivers and this is handled by amsdu_size module
> > parameter, supported values are 4k, 8k and 12k. RX allocation size and
> > proper values in vht_cap & ht_cap are set accordingly. Assuming
On Wed, Jun 12, 2019 at 02:59:05PM +0200, Stanislaw Gruszka wrote:
> > > If max RX AMSDU size is 3839B I do not see reason why we allocate
> > > MT_SG_MAX_SIZE=8 of MT_RX_BUF_SIZE=2k buffers for sg_en case.
> > > I thought the reason is that max AMSDU size is 16kB so it
On Wed, Jun 12, 2019 at 02:28:48PM +0200, Lorenzo Bianconi wrote:
> [...]
> >
> > My sense of humor declined quite drastically lastly ;-/
> >
> > > > > but we can be more cautious since probably copying
> > > > > the first 128B will not make any difference
> > > >
> > > > Not sure if I understan
On Wed, Jun 12, 2019 at 12:49:22PM +0200, Lorenzo Bianconi wrote:
> > On Wed, Jun 12, 2019 at 11:53:03AM +0200, Lorenzo Bianconi wrote:
> > > > On Fri, May 31, 2019 at 11:38:23AM +0200, Lorenzo Bianconi wrote:
> > >
> > > [...]
> > >
> > > > > }
> > > > >
> > > > > urb->num_sgs = ma
On Wed, Jun 12, 2019 at 12:21:34PM +0200, Lorenzo Bianconi wrote:
> On Jun 12, Stanislaw Gruszka wrote:
> > On Wed, Jun 12, 2019 at 11:45:21AM +0200, Lorenzo Bianconi wrote:
> > > > > +mt76u_build_rx_skb(u8 *data, int len, int buf_size,
> > &g
On Wed, Jun 12, 2019 at 11:53:03AM +0200, Lorenzo Bianconi wrote:
> > On Fri, May 31, 2019 at 11:38:23AM +0200, Lorenzo Bianconi wrote:
>
> [...]
>
> > > }
> > >
> > > urb->num_sgs = max_t(int, i, urb->num_sgs);
> > > - urb->transfer_buffer_length = urb->num_sgs * q->buf_size,
> > > + urb->
On Wed, Jun 12, 2019 at 11:45:21AM +0200, Lorenzo Bianconi wrote:
> > > +mt76u_build_rx_skb(u8 *data, int len, int buf_size,
> > > +int *nsgs)
> > > +{
> > > + int data_len = min(len, MT_SKB_HEAD_LEN);
Oh, and this looks unneeded as well as for len < MT_SKB_HEAD_LEN=128
we will go thro
Cc Tony
On Sat, Jun 08, 2019 at 02:26:51PM +0200, g.schlmm wrote:
> my RTL8822BE M.2 card is not working with linux 5.2rc3
>
> the staging r8822be driver in linux 5.1 was working for this card
>
> from dmesg:
> > [8.001186] rtw_pci :04:00.0: rfe 3 isn't supported
> >
On Fri, May 31, 2019 at 11:38:23AM +0200, Lorenzo Bianconi wrote:
> Set usb buffer size taking into account skb_shared_info in order to
> not always copy the first part of received frames if A-MSDU is enabled
> for SG capable devices
>
> Signed-off-by: Lorenzo Bianconi
> ---
> drivers/net/wirele
Hi and sorry for late comment.
On Fri, May 31, 2019 at 11:38:22AM +0200, Lorenzo Bianconi wrote:
> Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> receive frames up to q->buf_size but they will be disc
On Wed, May 15, 2019 at 03:48:29PM +0200, Stanislaw Gruszka wrote:
> > Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
> > traffic) and moreover they do not always occur so I am not convinced they
> > are always EDCCA related and so I am not confident to r
3:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka
> > > > > > > > wrote:
> > > > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi
> > > >
On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > On Mon, May 13, 2019 at 11:48
On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > On Mon, May 13, 2019 at 10:41:2
On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > Lorenzo Bianconi writes:
> > > >
On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > Lorenzo Bianconi writes:
> > >
> > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > e
On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > Lorenzo Bianconi writes:
> >
> > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > edcca processing
> > >
> > > Signed-off-by: Lorenzo Bianconi
> >
> > It's good to explain what edcca does and how the file
On Mon, May 13, 2019 at 11:19:06AM +0200, Lorenzo Bianconi wrote:
> > On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
> > > This is a preliminary patch to run mt76x02_edcca_init atomically
> > >
> > > Signed-off-by: Lorenzo Bianconi
> > > ---
> > > .../wireless/mediatek/mt76/mt
On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
> This is a preliminary patch to run mt76x02_edcca_init atomically
>
> Signed-off-by: Lorenzo Bianconi
> ---
> .../wireless/mediatek/mt76/mt76x2/pci_main.c | 16 --
> .../wireless/mediatek/mt76/mt76x2/usb_main.c | 22
1 - 100 of 1230 matches
Mail list logo
