* ath10k-sdio: failed to load firmware
From: Hermida, Isaac @ 2019-07-01 12:02 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi guys,
I know that it is still under development, but I am trying to use the ath10k driver with SDIO support on the QCA6574 chip. At least, based on all the commits, I should be able to load the firmware and have at least a minimal support (station), but currently I am unable to load the FW correctly.
I am using the latest "firmware-sdio-6.bin_WLAN.RMH.4.4.1-00011-QCARMSWP-2", board.bin and board-2.bin from [1].
"""
# md5sum *
db8264c352f202f38dfb99175209274c board-2.bin
cb37c63d9ca28f53fea1ff09ad7c7a82 board.bin
2e18e9b185e2f5f0940ca26f9f608f4a firmware-sdio-6.bin
"""
I am using an upstream kernel "5.1.14" and commit " a7891b029909009ffa4cd7b62593979f3d91aef7" from [2].
The load of the driver fails as:
"""
# dmesg | grep -iE "ath10k|mmc"
<4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is work-in-progress, problems may arise!
<6>ath10k_sdio mmc0:0001:1: qca6174 hw3.2 sdio target 0x05030000 chip_id 0x00000000 sub 0000:0000
<6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
<6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.RMH.4.4.1-00011-QCARMSWP-2 api 6 features wowlan,ignore-otp crc32 727e5047
<3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=050a,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA6174/hw3.0/board-2.bin
<6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 ed5f849a
<4>ath10k_sdio mmc0:0001:1: unsupported HTC service id: 1536
<6>ath10k_sdio mmc0:0001:1: htt-ver 3.60 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
<4>ath10k_sdio mmc0:0001:1: suspend timed out - target pause event never came
<4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
<4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
<4>ath10k_sdio mmc0:0001:1: unsupported HTC service id: 1536
<4>ath10k_sdio mmc0:0001:1: wmi command 135169 timeout, restarting hardware
<4>ath10k_sdio mmc0:0001:1: failed to enable adaptive qcs: -11
<4>ath10k_sdio mmc0:0001:1: could not suspend target (-108)
<4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
<4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
<4>ath10k_sdio mmc0:0001:1: cannot restart a device that hasn't been started
"""
I am using the correct FW files? Is anything else needed, maybe rename some file?
[1] https://github.com/kvalo/ath10k-firmware/blob/master/QCA6174/hw3.0
[2] https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath
^ permalink raw reply
* Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)
From: Martin Blumenstingl @ 2019-07-01 11:29 UTC (permalink / raw)
To: Christian Lamparter
Cc: Kalle Valo, chrisrblake93, jonas.gorski, linux-wireless,
QCA ath9k Development, Julian Calaby, dev, juhosg, john,
Hauke Mehrtens, jow
In-Reply-To: <2176615.mE3b70Bg5n@debian64>
On Sat, Jun 29, 2019 at 10:44 AM Christian Lamparter <chunkeey@gmail.com> wrote:
[...]
> That said: I have no problem relicensing my code under the ISC, if it
> helps with the upstreaming process. I've added Chris, Martin and
> Mathias as they both were consultants, as well as the previous
> authors of three targets to "let them know".
I am also fine with re-licensing my part of the code (to make it
explicit: of the ath9k PCI OWL loader) under the ISC (which is
expressed as MODULE_LICENSE("Dual BSD/GPL") in the ath9k driver code)
Martin
^ permalink raw reply
* [PATCH] mt76: round up length on mt76_wr_copy
From: Felix Fietkau @ 2019-07-01 11:27 UTC (permalink / raw)
To: linux-wireless; +Cc: stable
When beacon length is not a multiple of 4, the beacon could be sent with
the last 1-3 bytes corrupted. The skb data is guaranteed to have enough
room for reading beyond the end, because it is always followed by
skb_shared_info, so rounding up is safe.
All other callers of mt76_wr_copy have multiple-of-4 length already.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mmio.c | 2 +-
drivers/net/wireless/mediatek/mt76/usb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mmio.c b/drivers/net/wireless/mediatek/mt76/mmio.c
index 38368d19aa6f..83c96a47914f 100644
--- a/drivers/net/wireless/mediatek/mt76/mmio.c
+++ b/drivers/net/wireless/mediatek/mt76/mmio.c
@@ -43,7 +43,7 @@ static u32 mt76_mmio_rmw(struct mt76_dev *dev, u32 offset, u32 mask, u32 val)
static void mt76_mmio_copy(struct mt76_dev *dev, u32 offset, const void *data,
int len)
{
- __iowrite32_copy(dev->mmio.regs + offset, data, len >> 2);
+ __iowrite32_copy(dev->mmio.regs + offset, data, DIV_ROUND_UP(len, 4));
}
static int mt76_mmio_wr_rp(struct mt76_dev *dev, u32 base,
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 61b27f3ec6e4..87ecbe290f99 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -164,7 +164,7 @@ static void mt76u_copy(struct mt76_dev *dev, u32 offset,
int i, ret;
mutex_lock(&usb->usb_ctrl_mtx);
- for (i = 0; i < (len / 4); i++) {
+ for (i = 0; i < DIV_ROUND_UP(len, 4); i++) {
put_unaligned_le32(val[i], usb->data);
ret = __mt76u_vendor_request(dev, MT_VEND_MULTI_WRITE,
USB_DIR_OUT | USB_TYPE_VENDOR,
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] rt2x00usb: remove unnecessary rx flag checks
From: Stanislaw Gruszka @ 2019-07-01 11:07 UTC (permalink / raw)
To: Soeren Moch
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190701105314.9707-2-smoch@web.de>
On Mon, Jul 01, 2019 at 12:53:14PM +0200, Soeren Moch wrote:
> In contrast to the TX path, there is no need to separately read the transfer
> status from the device after receiving RX data. Consequently, there is no
> real STATUS_PENDING RX processing queue entry state.
> Remove the unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path.
> Also remove the misleading comment about reading RX status from device.
>
> Suggested-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Signed-off-by: Soeren Moch <smoch@web.de>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] rt2x00usb: fix rx queue hang
From: Stanislaw Gruszka @ 2019-07-01 11:07 UTC (permalink / raw)
To: Soeren Moch
Cc: stable, Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190701105314.9707-1-smoch@web.de>
On Mon, Jul 01, 2019 at 12:53:13PM +0200, Soeren Moch wrote:
> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
> ->complete() handler") the handler rt2x00usb_interrupt_rxdone() is
> not running with interrupts disabled anymore. So this completion handler
> is not guaranteed to run completely before workqueue processing starts
> for the same queue entry.
> Be sure to set all other flags in the entry correctly before marking
> this entry ready for workqueue processing. This way we cannot miss error
> conditions that need to be signalled from the completion handler to the
> worker thread.
> Note that rt2x00usb_work_rxdone() processes all available entries, not
> only such for which queue_work() was called.
>
> This patch is similar to what commit df71c9cfceea ("rt2x00: fix order
> of entry flags modification") did for TX processing.
>
> This fixes a regression on a RT5370 based wifi stick in AP mode, which
> suddenly stopped data transmission after some period of heavy load. Also
> stopping the hanging hostapd resulted in the error message "ieee80211
> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
> Other operation modes are probably affected as well, this just was
> the used testcase.
>
> Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
> Cc: stable@vger.kernel.org # 4.20+
> Signed-off-by: Soeren Moch <smoch@web.de>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH] rt2x00: fix rx queue hang
From: Stanislaw Gruszka @ 2019-07-01 11:04 UTC (permalink / raw)
To: Soeren Moch
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <06c55c1d-6da6-76b2-f6e7-c8eeccd5aa35@web.de>
On Mon, Jul 01, 2019 at 12:49:50PM +0200, Soeren Moch wrote:
> Hello!
>
> On 29.06.19 10:50, Stanislaw Gruszka wrote:
> > Hello
> >
> > On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote:
> >> Hi Stanislaw,
> >>
> >> the good news is: your patch below also solves the issue for me. But
> >> removing the ENTRY_DATA_STATUS_PENDING check in
> >> rt2x00usb_kick_rx_entry() alone does not help, while removing this check
> >> in rt2x00usb_work_rxdone() alone does the trick.
> >>
> >> So the real race seems to be that the flags set in the completion
> >> handler are not yet visible on the cpu core running the workqueue. And
> >> because the worker is not rescheduled when aborted, the entry can just
> >> wait forever.
> >> Do you think this could make sense?
> > Yes.
> >
> >>> I'm somewhat reluctant to change the order, because TX processing
> >>> might relay on it (we first mark we wait for TX status and
> >>> then mark entry is no longer owned by hardware).
> >> OK, maybe it's just good luck that changing the order solves the rx
> >> problem. Or can memory barriers associated with the spinlock in
> >> rt2x00lib_dmadone() be responsible for that?
> >> (I'm testing on a armv7 system, Cortex-A9 quadcore.)
> > I'm not sure, rt2x00queue_index_inc() also disable/enable interrupts,
> > so maybe that make race not reproducible.
> I tested some more, the race is between setting ENTRY_DATA_IO_FAILED (if
> needed) and enabling workqueue processing. This enabling was done via
> ENTRY_DATA_STATUS_PENDING in my patch. So setting
> ENTRY_DATA_STATUS_PENDING behind the spinlock in
> rt2x00lib_dmadone()/rt2x00queue_index_inc() moved this very close to
> setting of ENTRY_DATA_IO_FAILED (if needed). While still in the wrong
> order, this made it very unlikely for the race to show up.
> >
> >> While looking at it, why we double-clear ENTRY_OWNER_DEVICE_DATA in
> >> rt2x00usb_interrupt_rxdone() directly and in rt2x00lib_dmadone() again,
> > rt2x00lib_dmadone() is called also on other palaces (error paths)
> > when we have to clear flags.
> Yes, but also clearing ENTRY_OWNER_DEVICE_DATA in
> rt2x00usb_interrupt_rxdone() directly is not necessary and can lead to
> the wrong processing order.
> >> while not doing the same for tx?
> > If I remember correctly we have some races on rx (not happened on tx)
> > that was solved by using test_and_clear_bit(ENTRY_OWNER_DEVICE_DATA).
> I searched in the history, it actually was the other way around. You
> changed test_and_clear_bit() to test_bit() in the TX path. I think this
> is also the right way to go in RX.
> >> Would it make more sense to possibly
> >> set ENTRY_DATA_IO_FAILED before clearing ENTRY_OWNER_DEVICE_DATA in
> >> rt2x00usb_interrupt_rxdone() as for tx?
> > I don't think so, ENTRY_DATA_IO_FAILED should be only set on error
> > case.
>
> Yes of course. But if the error occurs, it should be signalled before
> enabling the workqueue processing, see the race described above.
>
> After some more testing I'm convinced that this would be the right fix
> for this problem. I will send a v2 of this patch accordingly.
Great, now I understand the problem. Thank you very much!
Stanislaw
^ permalink raw reply
* [PATCH v2 1/2] rt2x00usb: fix rx queue hang
From: Soeren Moch @ 2019-07-01 10:53 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Soeren Moch, stable, Helmut Schaa, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
Since commit ed194d136769 ("usb: core: remove local_irq_save() around
->complete() handler") the handler rt2x00usb_interrupt_rxdone() is
not running with interrupts disabled anymore. So this completion handler
is not guaranteed to run completely before workqueue processing starts
for the same queue entry.
Be sure to set all other flags in the entry correctly before marking
this entry ready for workqueue processing. This way we cannot miss error
conditions that need to be signalled from the completion handler to the
worker thread.
Note that rt2x00usb_work_rxdone() processes all available entries, not
only such for which queue_work() was called.
This patch is similar to what commit df71c9cfceea ("rt2x00: fix order
of entry flags modification") did for TX processing.
This fixes a regression on a RT5370 based wifi stick in AP mode, which
suddenly stopped data transmission after some period of heavy load. Also
stopping the hanging hostapd resulted in the error message "ieee80211
phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
Other operation modes are probably affected as well, this just was
the used testcase.
Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
Cc: stable@vger.kernel.org # 4.20+
Signed-off-by: Soeren Moch <smoch@web.de>
---
Changes in v2:
complete rework
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 67b81c7221c4..7e3a621b9c0d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -372,14 +372,9 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
struct queue_entry *entry = (struct queue_entry *)urb->context;
struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
- if (!test_and_clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags))
+ if (!test_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags))
return;
- /*
- * Report the frame as DMA done
- */
- rt2x00lib_dmadone(entry);
-
/*
* Check if the received data is simply too small
* to be actually valid, or if the urb is signaling
@@ -388,6 +383,11 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
if (urb->actual_length < entry->queue->desc_size || urb->status)
set_bit(ENTRY_DATA_IO_FAILED, &entry->flags);
+ /*
+ * Report the frame as DMA done
+ */
+ rt2x00lib_dmadone(entry);
+
/*
* Schedule the delayed work for reading the RX status
* from the device.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] rt2x00usb: remove unnecessary rx flag checks
From: Soeren Moch @ 2019-07-01 10:53 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Soeren Moch, Helmut Schaa, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20190701105314.9707-1-smoch@web.de>
In contrast to the TX path, there is no need to separately read the transfer
status from the device after receiving RX data. Consequently, there is no
real STATUS_PENDING RX processing queue entry state.
Remove the unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path.
Also remove the misleading comment about reading RX status from device.
Suggested-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Soeren Moch <smoch@web.de>
---
Changes in v2:
new patch
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 7e3a621b9c0d..bc2dfef0de22 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -349,8 +349,7 @@ static void rt2x00usb_work_rxdone(struct work_struct *work)
while (!rt2x00queue_empty(rt2x00dev->rx)) {
entry = rt2x00queue_get_entry(rt2x00dev->rx, Q_INDEX_DONE);
- if (test_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags) ||
- !test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
+ if (test_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags))
break;
/*
@@ -389,8 +388,7 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
rt2x00lib_dmadone(entry);
/*
- * Schedule the delayed work for reading the RX status
- * from the device.
+ * Schedule the delayed work for processing RX data
*/
queue_work(rt2x00dev->workqueue, &rt2x00dev->rxdone_work);
}
@@ -402,8 +400,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry *entry, void *data)
struct queue_entry_priv_usb *entry_priv = entry->priv_data;
int status;
- if (test_and_set_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags) ||
- test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
+ if (test_and_set_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags))
return false;
rt2x00lib_dmastart(entry);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: fix rx queue hang
From: Soeren Moch @ 2019-07-01 10:49 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <20190629085041.GA2854@redhat.com>
Hello!
On 29.06.19 10:50, Stanislaw Gruszka wrote:
> Hello
>
> On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote:
>> Hi Stanislaw,
>>
>> the good news is: your patch below also solves the issue for me. But
>> removing the ENTRY_DATA_STATUS_PENDING check in
>> rt2x00usb_kick_rx_entry() alone does not help, while removing this check
>> in rt2x00usb_work_rxdone() alone does the trick.
>>
>> So the real race seems to be that the flags set in the completion
>> handler are not yet visible on the cpu core running the workqueue. And
>> because the worker is not rescheduled when aborted, the entry can just
>> wait forever.
>> Do you think this could make sense?
> Yes.
>
>>> I'm somewhat reluctant to change the order, because TX processing
>>> might relay on it (we first mark we wait for TX status and
>>> then mark entry is no longer owned by hardware).
>> OK, maybe it's just good luck that changing the order solves the rx
>> problem. Or can memory barriers associated with the spinlock in
>> rt2x00lib_dmadone() be responsible for that?
>> (I'm testing on a armv7 system, Cortex-A9 quadcore.)
> I'm not sure, rt2x00queue_index_inc() also disable/enable interrupts,
> so maybe that make race not reproducible.
I tested some more, the race is between setting ENTRY_DATA_IO_FAILED (if
needed) and enabling workqueue processing. This enabling was done via
ENTRY_DATA_STATUS_PENDING in my patch. So setting
ENTRY_DATA_STATUS_PENDING behind the spinlock in
rt2x00lib_dmadone()/rt2x00queue_index_inc() moved this very close to
setting of ENTRY_DATA_IO_FAILED (if needed). While still in the wrong
order, this made it very unlikely for the race to show up.
>
>> While looking at it, why we double-clear ENTRY_OWNER_DEVICE_DATA in
>> rt2x00usb_interrupt_rxdone() directly and in rt2x00lib_dmadone() again,
> rt2x00lib_dmadone() is called also on other palaces (error paths)
> when we have to clear flags.
Yes, but also clearing ENTRY_OWNER_DEVICE_DATA in
rt2x00usb_interrupt_rxdone() directly is not necessary and can lead to
the wrong processing order.
>> while not doing the same for tx?
> If I remember correctly we have some races on rx (not happened on tx)
> that was solved by using test_and_clear_bit(ENTRY_OWNER_DEVICE_DATA).
I searched in the history, it actually was the other way around. You
changed test_and_clear_bit() to test_bit() in the TX path. I think this
is also the right way to go in RX.
>> Would it make more sense to possibly
>> set ENTRY_DATA_IO_FAILED before clearing ENTRY_OWNER_DEVICE_DATA in
>> rt2x00usb_interrupt_rxdone() as for tx?
> I don't think so, ENTRY_DATA_IO_FAILED should be only set on error
> case.
Yes of course. But if the error occurs, it should be signalled before
enabling the workqueue processing, see the race described above.
After some more testing I'm convinced that this would be the right fix
for this problem. I will send a v2 of this patch accordingly.
>
>>> However on RX
>>> side ENTRY_DATA_STATUS_PENDING bit make no sense as we do not
>>> wait for status. We should remove ENTRY_DATA_STATUS_PENDING on
>>> RX side and perhaps this also will solve issue you observe.
>> I agree that removing the unnecessary checks is a good idea in any case.
>>> Could you please check below patch, if it fixes the problem as well?
>> At least I could not trigger the problem within transferring 10GB of
>> data. But maybe the probability for triggering this bug is just lower
>> because ENTRY_OWNER_DEVICE_DATA is cleared some time before
>> ENTRY_DATA_STATUS_PENDING is set?
> Not sure. Anyway, could you post patch removing not needed checks
> with proper description/changelog ?
>
OK, I will do so.
Soeren
^ permalink raw reply
* Re: [PATCH 4/6] mt76: mt7615: unlock dfs bands
From: Kalle Valo @ 2019-07-01 10:49 UTC (permalink / raw)
To: Ryder Lee
Cc: Lorenzo Bianconi, Lorenzo Bianconi, Felix Fietkau, linux-wireless,
Roy Luo, YF Luo, linux-mediatek
In-Reply-To: <1561975021.3950.9.camel@mtkswgap22>
Ryder Lee <ryder.lee@mediatek.com> writes:
> On Mon, 2019-07-01 at 10:59 +0300, Kalle Valo wrote:
>> Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:
>>
>> >>
>> >> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>> >>
>> >> > Unlock dfs channels since now mt7615 driver supports radar detection
>> >> >
>> >> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> >> > ---
>> >> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>> >> > 1 file changed, 6 insertions(+)
>> >> >
>> >> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> >> > index 5dc4cced5789..6d336d82cafe 100644
>> >> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> >> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> >> > @@ -152,6 +152,12 @@ static const struct ieee80211_iface_combination if_comb[] = {
>> >> > .max_interfaces = 4,
>> >> > .num_different_channels = 1,
>> >> > .beacon_int_infra_match = true,
>> >> > + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
>> >> > + BIT(NL80211_CHAN_WIDTH_20) |
>> >> > + BIT(NL80211_CHAN_WIDTH_40) |
>> >> > + BIT(NL80211_CHAN_WIDTH_80) |
>> >> > + BIT(NL80211_CHAN_WIDTH_160) |
>> >> > + BIT(NL80211_CHAN_WIDTH_80P80),
>> >>
>> >> Isn't it questionable to enable these without any testing on real
>> >> hardware? Getting DFS to work correctly is hard so I'm very suspicious
>> >> about this.
>> >>
>> >> --
>> >> Kalle Valo
>> >
>> > Hi Kalle,
>> >
>> > unfortunately at the moment I am not able to run any tests with a real
>> > signal generator so I just ported the code from vendor sdk.
>> > I am pretty confident it works since the radar pattern detection is
>> > done in fw/hw so I guess it has been already tested in the vendor sdk
>>
>> DFS is really tricky to get it working right, so I'm not easily
>> convinced :)
>>
>> > but we can postpone this patch and apply just the rest of the series
>> > until we have some test results.
>>
>> Yeah, I think it would be best to drop this patch so that DFS is not
>> enabled by default and apply this patch only after positive test
>> results.
>>
>
> That's why I suggested Lorenzo to add this one - "[6/6] mt76: mt7615:
> add radar pattern test knob to debugfs"
>
> We can feed radar pattern through debugfs to test if a pattern is
> detected as radar pattern or not and verify the fw radar detection
> algorithm.
Sure, that's nice for testing but does not guarantee that it works with
real hardware as well. I take regulatory rules very seriously and that's
why I'm extra careful here.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the wireless-drivers-next tree
From: Lorenzo Bianconi @ 2019-07-01 10:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kalle Valo, Wireless, Linux Next Mailing List,
Linux Kernel Mailing List, Felix Fietkau, Ryder Lee
In-Reply-To: <20190701074437.6455d067@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
> Hi all,
>
> In commit
>
> d923cf6bc38a ("mt76: mt7615: fix sparse warnings: warning: cast from restricted __le16")
>
> Fixes tag
>
> Fixes: 3ca0a6f6e9df ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: 516c3e380533 ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send")
>
> In commit
>
> eda96044de27 ("mt76: mt7615: fix sparse warnings: incorrect type in assignment (different base types)")
>
> Fixes tag
>
> Fixes: 7339fbc0caa5 ("mt7615: mcu: do not use function pointers whenever possible")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: 1ca8089a55ee ("mt7615: mcu: do not use function pointers whenever possible")
>
> In commit
>
> 1a09d9e0e5f0 ("mt76: mt7615: fix incorrect settings in mesh mode")
>
> Fixes tag
>
> Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
Hi Stephen,
I used the hashes from my local git tree that are different from upstream ones,
sorry for the inconvenience. I will pay more attention next time.
Regards,
Lorenzo
>
> --
> Cheers,
> Stephen Rothwell
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] mt76: mt7615: unlock dfs bands
From: Ryder Lee @ 2019-07-01 9:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Lorenzo Bianconi, Lorenzo Bianconi, Felix Fietkau, linux-wireless,
Roy Luo, YF Luo, linux-mediatek
In-Reply-To: <87tvc69odh.fsf@kamboji.qca.qualcomm.com>
On Mon, 2019-07-01 at 10:59 +0300, Kalle Valo wrote:
> Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:
>
> >>
> >> Lorenzo Bianconi <lorenzo@kernel.org> writes:
> >>
> >> > Unlock dfs channels since now mt7615 driver supports radar detection
> >> >
> >> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >> > ---
> >> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> >> > 1 file changed, 6 insertions(+)
> >> >
> >> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> >> > index 5dc4cced5789..6d336d82cafe 100644
> >> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> >> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> >> > @@ -152,6 +152,12 @@ static const struct ieee80211_iface_combination if_comb[] = {
> >> > .max_interfaces = 4,
> >> > .num_different_channels = 1,
> >> > .beacon_int_infra_match = true,
> >> > + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
> >> > + BIT(NL80211_CHAN_WIDTH_20) |
> >> > + BIT(NL80211_CHAN_WIDTH_40) |
> >> > + BIT(NL80211_CHAN_WIDTH_80) |
> >> > + BIT(NL80211_CHAN_WIDTH_160) |
> >> > + BIT(NL80211_CHAN_WIDTH_80P80),
> >>
> >> Isn't it questionable to enable these without any testing on real
> >> hardware? Getting DFS to work correctly is hard so I'm very suspicious
> >> about this.
> >>
> >> --
> >> Kalle Valo
> >
> > Hi Kalle,
> >
> > unfortunately at the moment I am not able to run any tests with a real
> > signal generator so I just ported the code from vendor sdk.
> > I am pretty confident it works since the radar pattern detection is
> > done in fw/hw so I guess it has been already tested in the vendor sdk
>
> DFS is really tricky to get it working right, so I'm not easily
> convinced :)
>
> > but we can postpone this patch and apply just the rest of the series
> > until we have some test results.
>
> Yeah, I think it would be best to drop this patch so that DFS is not
> enabled by default and apply this patch only after positive test
> results.
>
That's why I suggested Lorenzo to add this one - "[6/6] mt76: mt7615:
add radar pattern test knob to debugfs"
We can feed radar pattern through debugfs to test if a pattern is
detected as radar pattern or not and verify the fw radar detection
algorithm.
In this format:
RadarPulsePattern="3680128-2-245;3683878-2-245;3687628-2-245;3691378-2-245;3695128-2-245;3698878-2-245;3702628-2-245;3706378-2-245;3710128-2-245;3713878-2-245"
As for testing it on 'real hardware' I need to take some other time to
borrow equipment.
Ryder
^ permalink raw reply
* [RFC PATCH v6] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-07-01 9:29 UTC (permalink / raw)
To: jes.sorensen, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
v3:
- Remove ugly rtl8xxxu_watchdog data structure
- Make sure only one vif exists
v4:
- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
- Clear priv->vif in rtl8xxxu_remove_interface
- Add rateid as the function argument of update_rate_mask
- Rephrase the comment for priv->vif more explicit.
v5:
- Make refresh_rate_mask() generic for all sub-drivers.
- Add definitions for SNR related to help determine rssi_level
v6:
- Fix typo of the comment for priv->vif
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 226 +++++++++++++++++-
2 files changed, 274 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 8828baf26e7b..95b990c976ed 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1195,6 +1195,48 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN -95
+#define RTL8XXXU_SNR_THRESH_HIGH 50
+#define RTL8XXXU_SNR_THRESH_LOW 20
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1299,6 +1341,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 rssi_level;
+ /*
+ * Only one virtual interface permitted because only STA mode
+ * is supported and no iface_combinations are provided.
+ */
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1334,7 +1383,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1419,9 +1468,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 039e5ca9d2e4..474dea2291a9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4311,7 +4311,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
}
-void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
+void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
@@ -4331,7 +4332,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi)
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
u8 bw = 0;
@@ -4345,7 +4346,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = rateid;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4485,6 +4486,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+static u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4527,7 +4562,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
- priv->fops->update_rate_mask(priv, ramask, sgi);
+ priv->vif = vif;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5471,6 +5509,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ if (!priv->vif)
+ priv->vif = vif;
+ else
+ return -EOPNOTSUPP;
rtl8xxxu_stop_tx_beacon(priv);
val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
@@ -5494,6 +5536,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
struct rtl8xxxu_priv *priv = hw->priv;
dev_dbg(&priv->udev->dev, "%s\n", __func__);
+
+ if (priv->vif)
+ priv->vif = NULL;
}
static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
@@ -5779,6 +5824,174 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static u8 rtl8xxxu_signal_to_snr(int signal)
+{
+ if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
+ signal = RTL8XXXU_NOISE_FLOOR_MIN;
+ return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
+}
+
+static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_idx;
+ u8 txbw_40mhz;
+ u8 snr, snr_thresh_high, snr_thresh_low;
+ u8 go_up_gap = 5;
+
+ rssi_level = priv->rssi_level;
+ snr = rtl8xxxu_signal_to_snr(signal);
+ snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
+ snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_MID:
+ snr_thresh_high += go_up_gap;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ snr_thresh_high += go_up_gap;
+ snr_thresh_low += go_up_gap;
+ break;
+ default:
+ break;
+ }
+
+ if (snr > snr_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (snr > snr_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_idx = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_idx = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_idx = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_GN_N2SS;
+ else
+ ratr_idx = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_idx = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ }
+}
+
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_priv *priv;
+
+ priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
+ vif = priv->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ rtl8xxxu_refresh_rate_mask(priv, signal, sta);
+ }
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5835,6 +6048,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -5886,6 +6101,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
if (priv->usb_interrupts)
rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
+ cancel_delayed_work_sync(&priv->ra_watchdog);
+
rtl8xxxu_free_rx_resources(priv);
rtl8xxxu_free_tx_resources(priv);
}
@@ -6058,6 +6275,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
--
2.21.0
^ permalink raw reply related
* Re: use exact allocation for dma coherent memory
From: Christoph Hellwig @ 2019-07-01 8:48 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten
Cc: devel, linux-s390, Intel Linux Wireless, linux-rdma, netdev,
intel-gfx, linux-wireless, linux-kernel, dri-devel, linux-mm,
iommu, moderated list:ARM PORT, linux-media
In-Reply-To: <20190614134726.3827-1-hch@lst.de>
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
> Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
> but it turns out that because we didn't filter valid gfp_t flags
> on the DMA allocator, a bunch of drivers were passing __GFP_COMP
> to it, which is rather bogus in too many ways to explain. Arm has
> been filtering it for a while, but this series instead tries to fix
> the drivers and warn when __GFP_COMP is passed, which makes it much
> larger than just adding the functionality.
Dear driver maintainers,
can you look over the patches touching your drivers, please? I'd
like to get as much as possible of the driver patches into this
merge window, so that it can you through your maintainer trees.
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-01 8:27 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <20190627095247.8792-1-chiu@endlessm.com>
Hi Chris,
On Thu, Jun 27, 2019 at 5:53 PM Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> This commit hand over the antenna control to PTA, the wifi signal
> will be back to normal and the bluetooth scan can also work at the
> same time. However, the btcoexist still needs to be handled under
> different circumstances. If there's a BT connection established,
> the wifi still fails to connect until disconneting the BT.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
Really nice work finding this!
I know that after this change, you plan to bring over the btcoexist
code from the vendor driver (or at least the minimum required code)
for a more complete fix, but I'm curious how you found these magic
register values and how they compare to the values used by the vendor
driver with btcoexist?
What's PTA? A type of firmware-implemented btcoexist that works for
scanning but doesn't work when a BT connection is actually
established?
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> index 3adb1d3d47ac..6c3c70d93ac1 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> /*
> * WLAN action by PTA
> */
> - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
The comment above this still says "WLAN action by PTA" and the vendor
driver has:
//set wlan_act control by PTA
pBtCoexist->fBtcWrite1Byte(pBtCoexist, 0x76e, 0x4);
but then also:
//set wlan_act control by PTA
pBtCoexist->fBtcWrite1Byte(pBtCoexist, 0x76e, 0xc);
So this change seems to be at least consistent with ambiguity of the
vendor driver, do you have any understanding of the extra bit that is
now set here?
It's not easy to follow the code flow of the vendor driver to see what
actually happens, have you checked that, does it end up using the 0xc
value?
> - * 0x280, 0x00, 0x200, 0x80 - not clear
> + * Different settings per different antenna position.
> + * Antenna switch to BT: 0x280, 0x00 (inverse)
> + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
I don't quite follow the comment here. Why are there 2 values listed
for each possibility, what do you mean by inverse? You say the
register settings were incorrect, but the previous value was 0x00
which you now document as "antenna switch to wifi" which sounds like
it was already correct?
Which value does the vendor driver use?
> /*
> * Software control, antenna at WiFi side
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 8136e268b4e6..87b2179a769e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
>
> /* Check if MAC is already powered on */
> val8 = rtl8xxxu_read8(priv, REG_CR);
> + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
>
> /*
> * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> * initialized. First MAC returns 0xea, second MAC returns 0x00
> */
> - if (val8 == 0xea)
> + if (val8 == 0xea || !(val16 & BIT(11)))
> macpower = false;
> else
> macpower = true;
At a glance I can't see which code this corresponds to in the vendor
driver, can you point that out?
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH 4/6] mt76: mt7615: unlock dfs bands
From: Kalle Valo @ 2019-07-01 7:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Lorenzo Bianconi, Felix Fietkau, linux-wireless, Ryder Lee,
Roy Luo, YF Luo
In-Reply-To: <CAJ0CqmU6TLhFa4ZJxWHBzvpx+5g5E4-WkSPECx47F9d3T=5YjQ@mail.gmail.com>
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:
>>
>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>>
>> > Unlock dfs channels since now mt7615 driver supports radar detection
>> >
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > ---
>> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>> > 1 file changed, 6 insertions(+)
>> >
>> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> > index 5dc4cced5789..6d336d82cafe 100644
>> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>> > @@ -152,6 +152,12 @@ static const struct ieee80211_iface_combination if_comb[] = {
>> > .max_interfaces = 4,
>> > .num_different_channels = 1,
>> > .beacon_int_infra_match = true,
>> > + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
>> > + BIT(NL80211_CHAN_WIDTH_20) |
>> > + BIT(NL80211_CHAN_WIDTH_40) |
>> > + BIT(NL80211_CHAN_WIDTH_80) |
>> > + BIT(NL80211_CHAN_WIDTH_160) |
>> > + BIT(NL80211_CHAN_WIDTH_80P80),
>>
>> Isn't it questionable to enable these without any testing on real
>> hardware? Getting DFS to work correctly is hard so I'm very suspicious
>> about this.
>>
>> --
>> Kalle Valo
>
> Hi Kalle,
>
> unfortunately at the moment I am not able to run any tests with a real
> signal generator so I just ported the code from vendor sdk.
> I am pretty confident it works since the radar pattern detection is
> done in fw/hw so I guess it has been already tested in the vendor sdk
DFS is really tricky to get it working right, so I'm not easily
convinced :)
> but we can postpone this patch and apply just the rest of the series
> until we have some test results.
Yeah, I think it would be best to drop this patch so that DFS is not
enabled by default and apply this patch only after positive test
results.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH v5] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Daniel Drake @ 2019-07-01 7:57 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <20190617065600.40405-1-chiu@endlessm.com>
On Mon, Jun 17, 2019 at 2:56 PM Chris Chiu <chiu@endlessm.com> wrote:
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps
suggestion: add:
, indicating that rtl8xxxu could still be further improved.
Then remove this paragraph, I think we're in agreement of the approach here:
> I believe the firmware of RTL8723BU may need fix. And I think we
> can still bring in the dm_watchdog as rtlwifi to improve from the
> driver side. Please leave precious comments for my commits and
> suggest what I can do better. Or suggest if there's any better idea
> to fix this. Thanks.
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
> + * is supported and no iface_combinations are providec.
typo: provided
^ permalink raw reply
* Re: [RFC PATCH v5] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-07-01 5:09 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, David Miller
Cc: linux-wireless, netdev, Linux Kernel, Linux Upstreaming Team
In-Reply-To: <20190617065600.40405-1-chiu@endlessm.com>
On Mon, Jun 17, 2019 at 2:56 PM Chris Chiu <chiu@endlessm.com> wrote:
>
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps.
>
> I believe the firmware of RTL8723BU may need fix. And I think we
> can still bring in the dm_watchdog as rtlwifi to improve from the
> driver side. Please leave precious comments for my commits and
> suggest what I can do better. Or suggest if there's any better idea
> to fix this. Thanks.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> ---
>
>
> Notes:
> v2:
> - Fix errors and warnings complained by checkpatch.pl
> - Replace data structure rate_adaptive by 2 member variables
> - Make rtl8xxxu_wireless_mode non-static
> - Runs refresh_rate_mask() only in station mode
> v3:
> - Remove ugly rtl8xxxu_watchdog data structure
> - Make sure only one vif exists
> v4:
> - Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
> - Clear priv->vif in rtl8xxxu_remove_interface
> - Add rateid as the function argument of update_rate_mask
> - Rephrase the comment for priv->vif more explicit.
> v5:
> - Make refresh_rate_mask() generic for all sub-drivers.
> - Add definitions for SNR related to help determine rssi_level
>
>
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 226 +++++++++++++++++-
> 2 files changed, 274 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index 8828baf26e7b..1498a8c94d5f 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1195,6 +1195,48 @@ struct rtl8723bu_c2h {
>
> struct rtl8xxxu_fileops;
>
> +/*mlme related.*/
> +enum wireless_mode {
> + WIRELESS_MODE_UNKNOWN = 0,
> + /* Sub-Element */
> + WIRELESS_MODE_B = BIT(0),
> + WIRELESS_MODE_G = BIT(1),
> + WIRELESS_MODE_A = BIT(2),
> + WIRELESS_MODE_N_24G = BIT(3),
> + WIRELESS_MODE_N_5G = BIT(4),
> + WIRELESS_AUTO = BIT(5),
> + WIRELESS_MODE_AC = BIT(6),
> + WIRELESS_MODE_MAX = 0x7F,
> +};
> +
> +/* from rtlwifi/wifi.h */
> +enum ratr_table_mode_new {
> + RATEID_IDX_BGN_40M_2SS = 0,
> + RATEID_IDX_BGN_40M_1SS = 1,
> + RATEID_IDX_BGN_20M_2SS_BN = 2,
> + RATEID_IDX_BGN_20M_1SS_BN = 3,
> + RATEID_IDX_GN_N2SS = 4,
> + RATEID_IDX_GN_N1SS = 5,
> + RATEID_IDX_BG = 6,
> + RATEID_IDX_G = 7,
> + RATEID_IDX_B = 8,
> + RATEID_IDX_VHT_2SS = 9,
> + RATEID_IDX_VHT_1SS = 10,
> + RATEID_IDX_MIX1 = 11,
> + RATEID_IDX_MIX2 = 12,
> + RATEID_IDX_VHT_3SS = 13,
> + RATEID_IDX_BGN_3SS = 14,
> +};
> +
> +#define RTL8XXXU_RATR_STA_INIT 0
> +#define RTL8XXXU_RATR_STA_HIGH 1
> +#define RTL8XXXU_RATR_STA_MID 2
> +#define RTL8XXXU_RATR_STA_LOW 3
> +
> +#define RTL8XXXU_NOISE_FLOOR_MIN -95
> +#define RTL8XXXU_SNR_THRESH_HIGH 50
> +#define RTL8XXXU_SNR_THRESH_LOW 20
> +
> struct rtl8xxxu_priv {
> struct ieee80211_hw *hw;
> struct usb_device *udev;
> @@ -1299,6 +1341,13 @@ struct rtl8xxxu_priv {
> u8 pi_enabled:1;
> u8 no_pape:1;
> u8 int_buf[USB_INTR_CONTENT_LENGTH];
> + u8 rssi_level;
> + /*
> + * Only one virtual interface permitted because only STA mode
> + * is supported and no iface_combinations are providec.
> + */
> + struct ieee80211_vif *vif;
> + struct delayed_work ra_watchdog;
> };
>
> struct rtl8xxxu_rx_urb {
> @@ -1334,7 +1383,7 @@ struct rtl8xxxu_fileops {
> void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
> bool ht40);
> void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
> - u32 ramask, int sgi);
> + u32 ramask, u8 rateid, int sgi);
> void (*report_connect) (struct rtl8xxxu_priv *priv,
> u8 macid, bool connect);
> void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
> @@ -1419,9 +1468,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
> void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
> void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
> void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, int sgi);
> + u32 ramask, u8 rateid, int sgi);
> void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, int sgi);
> + u32 ramask, u8 rateid, int sgi);
> void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
> u8 macid, bool connect);
> void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 039e5ca9d2e4..474dea2291a9 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -4311,7 +4311,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
> rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
> }
>
> -void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
> +void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> + u32 ramask, u8 rateid, int sgi)
> {
> struct h2c_cmd h2c;
>
> @@ -4331,7 +4332,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
> }
>
> void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, int sgi)
> + u32 ramask, u8 rateid, int sgi)
> {
> struct h2c_cmd h2c;
> u8 bw = 0;
> @@ -4345,7 +4346,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
>
> h2c.ramask.arg = 0x80;
> - h2c.b_macid_cfg.data1 = 0;
> + h2c.b_macid_cfg.data1 = rateid;
> if (sgi)
> h2c.b_macid_cfg.data1 |= BIT(7);
>
> @@ -4485,6 +4486,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
> rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
> }
>
> +static u16
> +rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
> +{
> + u16 network_type = WIRELESS_MODE_UNKNOWN;
> + u32 rate_mask;
> +
> + rate_mask = (sta->supp_rates[0] & 0xfff) |
> + (sta->ht_cap.mcs.rx_mask[0] << 12) |
> + (sta->ht_cap.mcs.rx_mask[0] << 20);
> +
> + if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
> + if (sta->vht_cap.vht_supported)
> + network_type = WIRELESS_MODE_AC;
> + else if (sta->ht_cap.ht_supported)
> + network_type = WIRELESS_MODE_N_5G;
> +
> + network_type |= WIRELESS_MODE_A;
> + } else {
> + if (sta->vht_cap.vht_supported)
> + network_type = WIRELESS_MODE_AC;
> + else if (sta->ht_cap.ht_supported)
> + network_type = WIRELESS_MODE_N_24G;
> +
> + if (sta->supp_rates[0] <= 0xf)
> + network_type |= WIRELESS_MODE_B;
> + else if (sta->supp_rates[0] & 0xf)
> + network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
> + else
> + network_type |= WIRELESS_MODE_G;
> + }
> +
> + return network_type;
> +}
> +
> static void
> rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> struct ieee80211_bss_conf *bss_conf, u32 changed)
> @@ -4527,7 +4562,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> sgi = 1;
> rcu_read_unlock();
>
> - priv->fops->update_rate_mask(priv, ramask, sgi);
> + priv->vif = vif;
> + priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
> +
> + priv->fops->update_rate_mask(priv, ramask, 0, sgi);
>
> rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
>
> @@ -5471,6 +5509,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
>
> switch (vif->type) {
> case NL80211_IFTYPE_STATION:
> + if (!priv->vif)
> + priv->vif = vif;
> + else
> + return -EOPNOTSUPP;
> rtl8xxxu_stop_tx_beacon(priv);
>
> val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
> @@ -5494,6 +5536,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
> struct rtl8xxxu_priv *priv = hw->priv;
>
> dev_dbg(&priv->udev->dev, "%s\n", __func__);
> +
> + if (priv->vif)
> + priv->vif = NULL;
> }
>
> static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
> @@ -5779,6 +5824,174 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> return 0;
> }
>
> +static u8 rtl8xxxu_signal_to_snr(int signal)
> +{
> + if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
> + signal = RTL8XXXU_NOISE_FLOOR_MIN;
> + return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
> +}
> +
> +static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
> + int signal, struct ieee80211_sta *sta)
> +{
> + struct ieee80211_hw *hw = priv->hw;
> + u16 wireless_mode;
> + u8 rssi_level, ratr_idx;
> + u8 txbw_40mhz;
> + u8 snr, snr_thresh_high, snr_thresh_low;
> + u8 go_up_gap = 5;
> +
> + rssi_level = priv->rssi_level;
> + snr = rtl8xxxu_signal_to_snr(signal);
> + snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
> + snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
> + txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
> +
> + switch (rssi_level) {
> + case RTL8XXXU_RATR_STA_MID:
> + snr_thresh_high += go_up_gap;
> + break;
> + case RTL8XXXU_RATR_STA_LOW:
> + snr_thresh_high += go_up_gap;
> + snr_thresh_low += go_up_gap;
> + break;
> + default:
> + break;
> + }
> +
> + if (snr > snr_thresh_high)
> + rssi_level = RTL8XXXU_RATR_STA_HIGH;
> + else if (snr > snr_thresh_low)
> + rssi_level = RTL8XXXU_RATR_STA_MID;
> + else
> + rssi_level = RTL8XXXU_RATR_STA_LOW;
> +
> + if (rssi_level != priv->rssi_level) {
> + int sgi = 0;
> + u32 rate_bitmap = 0;
> +
> + rcu_read_lock();
> + rate_bitmap = (sta->supp_rates[0] & 0xfff) |
> + (sta->ht_cap.mcs.rx_mask[0] << 12) |
> + (sta->ht_cap.mcs.rx_mask[1] << 20);
> + if (sta->ht_cap.cap &
> + (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
> + sgi = 1;
> + rcu_read_unlock();
> +
> + wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
> + switch (wireless_mode) {
> + case WIRELESS_MODE_B:
> + ratr_idx = RATEID_IDX_B;
> + if (rate_bitmap & 0x0000000c)
> + rate_bitmap &= 0x0000000d;
> + else
> + rate_bitmap &= 0x0000000f;
> + break;
> + case WIRELESS_MODE_A:
> + case WIRELESS_MODE_G:
> + ratr_idx = RATEID_IDX_G;
> + if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
> + rate_bitmap &= 0x00000f00;
> + else
> + rate_bitmap &= 0x00000ff0;
> + break;
> + case (WIRELESS_MODE_B | WIRELESS_MODE_G):
> + ratr_idx = RATEID_IDX_BG;
> + if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
> + rate_bitmap &= 0x00000f00;
> + else if (rssi_level == RTL8XXXU_RATR_STA_MID)
> + rate_bitmap &= 0x00000ff0;
> + else
> + rate_bitmap &= 0x00000ff5;
> + break;
> + case WIRELESS_MODE_N_24G:
> + case WIRELESS_MODE_N_5G:
> + case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
> + case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
> + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> + ratr_idx = RATEID_IDX_GN_N2SS;
> + else
> + ratr_idx = RATEID_IDX_GN_N1SS;
> + case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
> + case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
> + if (txbw_40mhz) {
> + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> + ratr_idx = RATEID_IDX_BGN_40M_2SS;
> + else
> + ratr_idx = RATEID_IDX_BGN_40M_1SS;
> + } else {
> + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> + ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
> + else
> + ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
> + }
> +
> + if (priv->tx_paths == 2 && priv->rx_paths == 2) {
> + if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
> + rate_bitmap &= 0x0f8f0000;
> + } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
> + rate_bitmap &= 0x0f8ff000;
> + } else {
> + if (txbw_40mhz)
> + rate_bitmap &= 0x0f8ff015;
> + else
> + rate_bitmap &= 0x0f8ff005;
> + }
> + } else {
> + if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
> + rate_bitmap &= 0x000f0000;
> + } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
> + rate_bitmap &= 0x000ff000;
> + } else {
> + if (txbw_40mhz)
> + rate_bitmap &= 0x000ff015;
> + else
> + rate_bitmap &= 0x000ff005;
> + }
> + }
> + break;
> + default:
> + ratr_idx = RATEID_IDX_BGN_40M_2SS;
> + rate_bitmap &= 0x0fffffff;
> + break;
> + }
> +
> + priv->rssi_level = rssi_level;
> + priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
> + }
> +}
> +
> +static void rtl8xxxu_watchdog_callback(struct work_struct *work)
> +{
> + struct ieee80211_vif *vif;
> + struct rtl8xxxu_priv *priv;
> +
> + priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
> + vif = priv->vif;
> +
> + if (vif && vif->type == NL80211_IFTYPE_STATION) {
> + int signal;
> + struct ieee80211_sta *sta;
> +
> + rcu_read_lock();
> + sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
> + if (!sta) {
> + struct device *dev = &priv->udev->dev;
> +
> + dev_info(dev, "%s: no sta found\n", __func__);
> + rcu_read_unlock();
> + return;
> + }
> + rcu_read_unlock();
> +
> + signal = ieee80211_ave_rssi(vif);
> + rtl8xxxu_refresh_rate_mask(priv, signal, sta);
> + }
> +
> + schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
> +}
> +
> static int rtl8xxxu_start(struct ieee80211_hw *hw)
> {
> struct rtl8xxxu_priv *priv = hw->priv;
> @@ -5835,6 +6048,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>
> ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
> }
> +
> + schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
> exit:
> /*
> * Accept all data and mgmt frames
> @@ -5886,6 +6101,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
> if (priv->usb_interrupts)
> rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
>
> + cancel_delayed_work_sync(&priv->ra_watchdog);
> +
> rtl8xxxu_free_rx_resources(priv);
> rtl8xxxu_free_tx_resources(priv);
> }
> @@ -6058,6 +6275,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> INIT_LIST_HEAD(&priv->rx_urb_pending_list);
> spin_lock_init(&priv->rx_urb_lock);
> INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
> + INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
>
> usb_set_intfdata(interface, hw);
>
> --
> 2.21.0
>
Gentle ping. Cheers.
Chris
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-01 5:09 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, David Miller
Cc: linux-wireless, netdev, Linux Kernel, Linux Upstreaming Team
In-Reply-To: <20190627095247.8792-1-chiu@endlessm.com>
On Thu, Jun 27, 2019 at 5:52 PM Chris Chiu <chiu@endlessm.com> wrote:
>
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> This commit hand over the antenna control to PTA, the wifi signal
> will be back to normal and the bluetooth scan can also work at the
> same time. However, the btcoexist still needs to be handled under
> different circumstances. If there's a BT connection established,
> the wifi still fails to connect until disconneting the BT.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++++++---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> index 3adb1d3d47ac..6c3c70d93ac1 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> /*
> * WLAN action by PTA
> */
> - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
>
> /*
> * BT select S0/S1 controlled by WiFi
> @@ -1568,9 +1568,12 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
>
> /*
> - * 0x280, 0x00, 0x200, 0x80 - not clear
> + * Different settings per different antenna position.
> + * Antenna switch to BT: 0x280, 0x00 (inverse)
> + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> /*
> * Software control, antenna at WiFi side
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 8136e268b4e6..87b2179a769e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
>
> /* Check if MAC is already powered on */
> val8 = rtl8xxxu_read8(priv, REG_CR);
> + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
>
> /*
> * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> * initialized. First MAC returns 0xea, second MAC returns 0x00
> */
> - if (val8 == 0xea)
> + if (val8 == 0xea || !(val16 & BIT(11)))
> macpower = false;
> else
> macpower = true;
> --
> 2.11.0
>
Gentle ping. Cheers.
Chris
^ permalink raw reply
* Fwd: rtl8723au: WiFi scanning stops working shortly after driver loads?
From: Daniel Lenski @ 2019-06-30 21:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Jes Sorensen
In-Reply-To: <CAOw_LSHsioZ2TP1FeZT3L6gHeeV72e2aKW0bGkAzcJRgVzE43Q@mail.gmail.com>
Hi,
I recently started to use an older laptop with RTL8723AU
WiFi/Bluetooth again for the first time in a couple years.
I've noticed a strange behavior of this device/driver (rtl8xxxu with
4.4.0 kernel): the ability to do a WiFi scan *while associated with an
access point* somehow disappears ~30 seconds after the driver is
loaded.
That is, right after loading the module and connecting to a WiFi
network, I can successfully do `iwlist wlan0 scan`; but after a short
period of time, the scan stops returning any results other than for
the AP that I'm already connected to. Disconnecting from the AP
"resets" this behavior, but once I reconnect to a network, my ability
to scan disappears again shortly thereafter.
Steps to reproduce:
# rmmod rtl8xxxu
# modprobe rtl8xxxu debug=99
# while true; do sudo iwlist wlan0 scan | grep ESSID | wc -l ; sleep 2; done
13
13
13
13
1 # only my current AP
1
...
Is this a known issue with the hardware, or with the driver? Any
advice on how to debug it? I've looked through the debug messages, and
found nothing that seems to indicate a state change around the time
that the scan stops working.
Thanks,
Dan
ps: I'm using the "standard" rtl8723aufw_B_NoBT.bin firmware
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtlwifi/rtl8723aufw_B_NoBT.bin)
and have loaded *only* the WiFi driver, *not* the Bluetooth driver.
[ 3110.201258] usb 1-1.4: Vendor: Realtek
[ 3110.201267] usb 1-1.4: Product: 802.11n WLAN Adapter
[ 3110.201274] usb 1-1.4: RTL8723AU rev B (TSMC) 1T1R, TX queues 2,
WiFi=1, BT=1, GPS=0, HI PA=0
[ 3110.201279] usb 1-1.4: RTL8723AU MAC: 20:16:d8:ce:5e:29
[ 3110.201284] usb 1-1.4: rtl8xxxu: Loading firmware
rtlwifi/rtl8723aufw_B_NoBT.bin
[ 3110.201355] usb 1-1.4: Firmware revision 31.0 (signature 0x2302)
^ permalink raw reply
* linux-next: Fixes tag needs some work in the wireless-drivers-next tree
From: Stephen Rothwell @ 2019-06-30 21:44 UTC (permalink / raw)
To: Kalle Valo, Wireless
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Lorenzo Bianconi, Felix Fietkau, Ryder Lee
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
Hi all,
In commit
d923cf6bc38a ("mt76: mt7615: fix sparse warnings: warning: cast from restricted __le16")
Fixes tag
Fixes: 3ca0a6f6e9df ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: 516c3e380533 ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send")
In commit
eda96044de27 ("mt76: mt7615: fix sparse warnings: incorrect type in assignment (different base types)")
Fixes tag
Fixes: 7339fbc0caa5 ("mt7615: mcu: do not use function pointers whenever possible")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: 1ca8089a55ee ("mt7615: mcu: do not use function pointers whenever possible")
In commit
1a09d9e0e5f0 ("mt76: mt7615: fix incorrect settings in mesh mode")
Fixes tag
Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??
From: Christian Hewitt @ 2019-06-30 17:06 UTC (permalink / raw)
To: Arend Van Spriel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Wright.Feng, Neil Armstrong, Christoph Muellner
In-Reply-To: <db1e6182-d8fe-a68a-e769-b6460c68fab0@broadcom.com>
> On 24 Jun 2019, at 8:04 pm, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>
> Hi Christian,
>
> Here it is. Hopefully unmangled this time.
Hi Arend.
The extra logging patch is un-mangled and applies fine, but I bumped to 5.2-rc4 recently (and now 5.2-rc7) and hit a major problem.
If I add the BCM4359 device ID’s with the following commit I see a brcmfmac splat and the system fails to boot.
commit: https://github.com/chewitt/linux/commit/f07161815699a48e636600a0b835d7ff64715383
splat: https://imgur.com/a/28wu5kh
defconfig: https://github.com/chewitt/LibreELEC.tv/blob/amlogic-master/projects/Amlogic/linux/linux.aarch64.conf
Adding the extra logging changes you suggested is not the issue, it’s adding the device ID’s.
I was previously using 5.1-rc1 and 5.1.9 kernels and didn’t see any issues adding the ID’s.
Any ideas?
Christian
^ permalink raw reply
* Re: [PATCH 4/6] mt76: mt7615: unlock dfs bands
From: Lorenzo Bianconi @ 2019-06-30 11:25 UTC (permalink / raw)
To: Kalle Valo
Cc: Lorenzo Bianconi, Felix Fietkau, linux-wireless, Ryder Lee,
Roy Luo, YF Luo
In-Reply-To: <87muhzs9qv.fsf@purkki.adurom.net>
>
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> > Unlock dfs channels since now mt7615 driver supports radar detection
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > index 5dc4cced5789..6d336d82cafe 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > @@ -152,6 +152,12 @@ static const struct ieee80211_iface_combination if_comb[] = {
> > .max_interfaces = 4,
> > .num_different_channels = 1,
> > .beacon_int_infra_match = true,
> > + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
> > + BIT(NL80211_CHAN_WIDTH_20) |
> > + BIT(NL80211_CHAN_WIDTH_40) |
> > + BIT(NL80211_CHAN_WIDTH_80) |
> > + BIT(NL80211_CHAN_WIDTH_160) |
> > + BIT(NL80211_CHAN_WIDTH_80P80),
>
> Isn't it questionable to enable these without any testing on real
> hardware? Getting DFS to work correctly is hard so I'm very suspicious
> about this.
>
> --
> Kalle Valo
Hi Kalle,
unfortunately at the moment I am not able to run any tests with a real
signal generator so I just ported the code from vendor sdk.
I am pretty confident it works since the radar pattern detection is
done in fw/hw so I guess it has been already tested in the vendor sdk
but we can postpone this patch and apply just the rest of the series
until we have some test results.
@Ryder: do you have the possibility to carry out some real tests?
Regards,
Lorenzo
^ permalink raw reply
* Re: pull request: mt76 2019-06-27
From: Kalle Valo @ 2019-06-30 9:30 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <a0e08791-e4e0-6772-751c-be05a4d25d8c@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> Hi Kalle,
>
> here's my first pull request for 5.3
>
> - Felix
>
> The following changes since commit e5db0ad7563c38b7b329504836c9a64ae025a47a:
>
> airo: switch to skcipher interface (2019-06-25 08:12:20 +0300)
>
> are available in the Git repository at:
>
> https://github.com/nbd168/wireless tags/mt76-for-kvalo-2019-06-27
>
> for you to fetch changes up to 676fabd1d2f089f9fb8bece3476c2ab5584b4a1a:
>
> mt76: mt7603: fix sparse warnings: warning: incorrect type in assignment (different base types) (2019-06-27 12:59:07 +0200)
>
> ----------------------------------------------------------------
> mt76 patches for 5.3
>
> * use NAPI polling for tx cleanup on mt7603/mt7615
> * various fixes for mt7615
> * unify some code between mt7603 and mt7615
> * fix locking issues on mt76x02
> * add support for toggling edcca on mt7603
> * fix reading target tx power with ext PA on mt7603/mt7615
> * fix initalizing channel maximum power
> * fix rate control / tx status reporting issues on mt76x02/mt7603
> * add support for eeprom calibration data from mtd on mt7615
> * support configuring tx power on mt7615
> * fix external PA support on mt76x0
> * per-chain signal reporting on mt7615
> * rx/tx buffer fixes for USB devices
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 4/6] mt76: mt7615: unlock dfs bands
From: Kalle Valo @ 2019-06-30 9:28 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: nbd, lorenzo.bianconi, linux-wireless, ryder.lee, royluo, yf.luo
In-Reply-To: <33184e0b78983fe7c79fa70c5fbb21042aafa4f5.1561804422.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
> Unlock dfs channels since now mt7615 driver supports radar detection
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> index 5dc4cced5789..6d336d82cafe 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> @@ -152,6 +152,12 @@ static const struct ieee80211_iface_combination if_comb[] = {
> .max_interfaces = 4,
> .num_different_channels = 1,
> .beacon_int_infra_match = true,
> + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
> + BIT(NL80211_CHAN_WIDTH_20) |
> + BIT(NL80211_CHAN_WIDTH_40) |
> + BIT(NL80211_CHAN_WIDTH_80) |
> + BIT(NL80211_CHAN_WIDTH_160) |
> + BIT(NL80211_CHAN_WIDTH_80P80),
Isn't it questionable to enable these without any testing on real
hardware? Getting DFS to work correctly is hard so I'm very suspicious
about this.
--
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