* Re: [01/10] brcmfmac: Split brcmf_sdiod_buffrw function up.
From: Kalle Valo @ 2017-12-14 12:41 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> From: Ian Molton <ian@mnementh.co.uk>
>
> This function needs to be split up into separate read / write variants
> for clarity.
>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
10 patches applied to wireless-drivers-next.git, thanks.
8f13c87ccc49 brcmfmac: Split brcmf_sdiod_buffrw function up.
6e24dd012bfd brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
a7323378dcf1 brcmfmac: Clarify if using braces.
71bd508d7ded brcmfmac: Rename / replace old IO functions with simpler ones.
eeef8a5da781 brcmfmac: Tidy register definitions a little
a7c3aa1509e2 brcmfmac: Remove brcmf_sdiod_addrprep()
c900072bd6fa brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()
e4c05fc3c0a6 brcmfmac: Cleanup offsetof()
5cfe38f1f8d3 brcmfmac: Remove unused macro.
21a10846d09d brcmfmac: Remove repeated calls to brcmf_chip_get_core()
--
https://patchwork.kernel.org/patch/10102409/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: enlarge buffer size of caps to 512 bytes
From: Kalle Valo @ 2017-12-14 12:42 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <1512977901-12726-1-git-send-email-wright.feng@cypress.com>
Wright Feng <wright.feng@cypress.com> wrote:
> The buffer size of return of cap iovar is greater than 256 bytes in some
> firmwares. For instance, the return size of cap iovar is 271 bytes in 4373
> 13.10.246.79 firmare. It makes feature capability parsing failed because
> caps buffer is default value.
> So we enlarge caps buffer size to 512 bytes and add the error print for
> cap iovar error.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
7762bb134e3b brcmfmac: enlarge buffer size of caps to 512 bytes
--
https://patchwork.kernel.org/patch/10104357/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/3] rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet to HIQ
From: Kalle Valo @ 2017-12-14 12:43 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Ping-Ke Shih, Larry Finger, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting
In-Reply-To: <20171209173710.9879-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> Making this change to HIQ, which has high priority, improves the response
> time for transmission after TBTT or beacon.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
2 patches applied to wireless-drivers-next.git, thanks.
e298be2a97fd rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet to HIQ
b7573a0a27bf rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
--
https://patchwork.kernel.org/patch/10103759/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/1] rtlwifi: always initialize variables given to RT_TRACE()
From: Kalle Valo @ 2017-12-14 12:44 UTC (permalink / raw)
To: Nicolas Iooss
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel,
Nicolas Iooss
In-Reply-To: <20171210195159.7454-1-nicolas.iooss_linux@m4x.org>
Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
> In rtl_rx_ampdu_apply(), when rtlpriv->cfg->ops->get_btc_status()
> returns false, RT_TRACE() is called with the values of variables
> reject_agg and agg_size, which have not been initialized.
>
> Always initialize these variables in order to prevent using
> uninitialized values.
>
> This issue has been found with clang. The compiler reported:
>
> drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
> 'agg_size' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> if (rtlpriv->cfg->ops->get_btc_status())
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/base.c:1671:31: note:
> uninitialized use occurs here
> reject_agg, ctrl_agg_size, agg_size);
> ^~~~~~~~
>
> drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
> 'reject_agg' is used uninitialized whenever 'if' condition
> is false [-Werror,-Wsometimes-uninitialized]
> if (rtlpriv->cfg->ops->get_btc_status())
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/base.c:1671:4: note:
> uninitialized use occurs here
> reject_agg, ctrl_agg_size, agg_size);
> ^~~~~~~~~~
>
> Fixes: 2635664e6e4a ("rtlwifi: Add rx ampdu cfg for btcoexist.")
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Patch applied to wireless-drivers-next.git, thanks.
e4779162f737 rtlwifi: always initialize variables given to RT_TRACE()
--
https://patchwork.kernel.org/patch/10103995/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 1/3] mac80211: Add TXQ scheduling API
From: Felix Fietkau @ 2017-12-14 12:44 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
Cc: Johannes Berg
In-Reply-To: <87lgi5jyka.fsf@toke.dk>
On 2017-12-14 13:15, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> On 2017-10-31 12:27, Toke Høiland-Jørgensen wrote:
>>> This adds an API to mac80211 to handle scheduling of TXQs and changes the
>>> interface between driver and mac80211 for TXQ handling as follows:
>>>
>>> - The wake_tx_queue callback interface no longer includes the TXQ. Instead,
>>> the driver is expected to retrieve that from ieee80211_next_txq()
>>>
>>> - Two new mac80211 functions are added: ieee80211_next_txq() and
>>> ieee80211_schedule_txq(). The former returns the next TXQ that should be
>>> scheduled, and is how the driver gets a queue to pull packets from. The
>>> latter is called internally by mac80211 to start scheduling a queue, and
>>> the driver is supposed to call it to re-schedule the TXQ after it is
>>> finished pulling packets from it (unless the queue emptied).
>>>
>>> The ath9k and ath10k drivers are changed to use the new API.
>>>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>> Sorry that I didn't have time to give this a thorough review earlier,
>> since I was pretty busy with other projects. Now that I'm working on
>> porting mt76 to this new API, some things in this patch strike me as
>> rather odd, and there might be some bugs and nasty limitations here:
>>
>> In the new API you can no longer select txq entries by hardware queue.
>> When using multiple WMM queues, this could lead to station entries being
>> requeued unnecessarily (because there is no room in the hw queue for the
>> txq entry that ieee80211_next_txq happens to return).
>
> Yeah, there's some tension between enforcing fairness (which is a per
> station thing) and the WMM queueing stuff (which gives priority based on
> WMM levels and ignores stations). There are basically two ways to
> resolve this: Prioritising fairness or prioritising WMM levels. In the
> former case, we first select which station to transmit to, and then
> select the highest WMM priority level queued *for that station* (the
> last part of this is missing from the code as it is now). In the latter
> case, we keep scheduling per-WMM, then enforce fairness within that.
>
> The former case has the potential to lead to starved hardware queues,
> while the latter leads to unfairness. We had a bit of discussion of
> which is better at netdev, but did not resolve it. Personally, I think
> prioritising fairness is better, but I'm willing to be convinced
> otherwise by data :). So my plan is to implement that fully and try it
> out, then evaluate based on actual experiments...
I don't really see how the approach taken in the current code is
actually prioritising fairness by starving hardware queues, since any
txq that can't be serviced in the current call because of queue depth
will be requeued. So based on the traffic pattern this might actually
lead to *more* unfairness.
>> Since ieee80211_next_txq also refills the airtime fairness quantum, this
>> might lead to some minor fairness issues.
>
> I'm planning to change the way the scheduler works anyway, so this issue
> should go away. Haven't had time to do that yet, unfortunately.Well, the problem is that the new code inside ath9k is a lot harder to
verify for correct behavior (regarding the queue starvation issue), and
I would really like to avoid nasty regressions that will be a nightmare
to debug.
>> In ath9k the code used to have a loop that goes through all pending txq
>> entries until it has filled the hw queues again. You replaced that with
>> some calls to ath_txq_schedule which now only considers one single txq.
>> There are several reasons why this queue could potentially not be serviced:
>> - ieee80211_tx_dequeue returned no frame
>> - frame does not fit within BA window
>> - txq was for another queue which is already filled
>> Depending on the exact circumstances with enough stations this might
>> lead to hardware queues getting starved.
>
> Well, that loop was already removed when I implemented the in-driver
> fairness scheduler.
Now that's not true. I'm looking at the diff for "mac80211: Add TXQ
scheduling API", and it removes these lines:
- /*
- * If we succeed in scheduling something, immediately restart to
make
- * sure we keep the HW busy.
- */
- if(ath_tx_sched_aggr(sc, txq, tid)) {
- if (!active) {
- spin_lock_bh(&acq->lock);
- list_move_tail(&tid->list, &acq->acq_old);
- spin_unlock_bh(&acq->lock);
- }
- goto begin;
- }
> We can't really avoid those cases entirely if we
> want to enforce fairness (the BAW case in particular; if the only
> eligible station from an airtime PoW has a full BAW, you have to
> throttle and can potentially starve hwqs). However, don't think this
> happens much in practice (or we would have seen performance regressions
> by now).I think so far you simply haven't had enough users hammering on the new
code yet.
> The 'txq was for another queue' case is new with this patch, but that
> goes back to the WMM/fairness tention above.
I agree that this is something we need to figure out. One aspect that I
have a major problem with is the fact that this *really* intrusive patch
that completely changes the way that ath9k schedules tx queues is hidden
behind this "API change" patch.
The way the API stands now, mt76 would require an equally big rework to
a different scheduling model which I'm not comfortable with at this point.
I would like to suggest the following to resolve these issues:
First we should revert these patches.
We can respin them shortly after in a modified form where
ieee80211_next_txq takes a 'queue' argument.
I'm almost done with the incremental change for that, and it also
supports passing -1 for queue so incrementally switching to the
scheduling that you're proposing will also work.
With that in place we can replace the ath9k change with a much smaller
patch that is easier to verify for correctness and won't introduce the
potential regressions that I pointed out.
I will take care of the mt76 porting today and I'll also help with
sorting out the ath10k issues.
Is that acceptable to you?
- Felix
^ permalink raw reply
* Re: wlcore: fix unused function warning
From: Kalle Valo @ 2017-12-14 12:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Reizer, Eyal, Johannes Berg, Iain Hunter,
Arend Van Spriel, Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171211114718.3637010-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The newly added wlcore_fw_sleep function is called conditionally,
> which causes a warning without CONFIG_PM:
>
> drivers/net/wireless/ti/wlcore/main.c:981:12: error: 'wlcore_fw_sleep' defined but not used [-Werror=unused-function]
>
> Instead of trying to keep track of what should be in the #ifdef and what
> should not, it's easier to mark the top-level suspend/resume functions
> as __maybe_unused so the compiler can silently drop all the unused code.
>
> Fixes: 37bf241b8e7b ("wlcore: allow elp during wowlan suspend")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
7de241f3b705 wlcore: fix unused function warning
--
https://patchwork.kernel.org/patch/10104839/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2800usb firmware rt2870.bin 0.36 not scanning
From: Stanislaw Gruszka @ 2017-12-14 12:47 UTC (permalink / raw)
To: Craig McQueen; +Cc: linux-wireless
In-Reply-To: <17dbd0476f1e45c7af0cb70efb15d75f@innerrange.com.au>
On Wed, Dec 13, 2017 at 11:24:28PM +0000, Craig McQueen wrote:
> > Actually, I was wrong. With the 3.14.x Yocto-built kernel, this no-scan issue
> > only happens with the Edup with the 5390 chipset, and the D-Link is fine.
> >
> > But further testing with the 4.4.12 Yocto-built kernel shows that it randomly
> > sometimes happens and sometimes doesn't with either the Edup or D-Link
> > devices. That's especially interesting, because it suggests that there may be a
> > race condition happening during the driver initialisation code (called from
> > rt2x00lib_start()). At first I thought it was a race condition between the calls
> > to rt2x00lib_load_firmware() and rt2x00lib_initialize(), but adding a time
> > delay between those calls didn't help.
> >
> > I'm wondering what the difference is between the two chipsets, so that the
> > problem happens more on one chipset than the other. But not exclusively, as
> > I mentioned above, so again, this points to a marginal timing issue that
> > affects one more than the other.
> >
> > > With the Ubuntu 4.4.6 kernel, both devices work fine, without this
> > > no-scan problem.
> > > ...
>
> Now I'm using a 4.9.65 kernel, and this problem is still present. When the USB Wi-Fi dongle is plugged in, it just doesn't do anything -- doesn't scan for Wi-Fi networks, doesn't connect to anything.
>
> My project is using ConnMan, so I've patched ConnMan so that it takes the device up, then down, then up again. Then it reliably works. But of course this is an ugly hack.
>
> Based on my initial investigation, my hypothesis was that there's a race condition during rt2x00lib_start() in rt2x00dev.c. At first I thought it was between firmware loading and initialisation. But adding a time delay between the calls to rt2x00lib_load_firmware() and rt2x00lib_initialize() didn't help. Adding time delays at many possible points in the initialisation didn't seem to help. I thought there must be a race condition in a very specific location in the initialisation sequence, but could not confirm that hypothesis. So now I've drawn a blank.
>
> Any advice on how to diagnose and remedy this issue?
I know the vendor driver do initialization sequence twice - after
finish first sequence the same steps are repeated second time.
I don't know why that is needed and on all my Ralink USB devices
one initialization sequence is sufficient with rt2x00 driver.
Right fix to this will be found proper initialization sequence,
so second step will not be needed, but perhaps this is firmware
problem. Anyway ConnMan patch seems to be a good solution
as well ;-)
Cheers
Stanislaw
^ permalink raw reply
* Re: regulatory.db file for ath10k
From: Kalle Valo @ 2017-12-14 12:52 UTC (permalink / raw)
To: KAVITA MATHUR
Cc: Manikanta Pubbisetty, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20171213081213.M75864@cdot.in>
(please don't top post)
"KAVITA MATHUR" <kavitam@cdot.in> writes:
> I do not want to use regulatory.db. Can you please share your ath10k buil=
d
> configuration? I may be missing something in configuration.
If you don't want to use regulatory.db you can just ignore the warning
and continue to use CRDA as before.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] ath10k: fix recent bandwidth conversion bug
From: Kalle Valo @ 2017-12-14 13:21 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Sebastian Gottschall, linux-wireless@vger.kernel.org
In-Reply-To: <1882220.dvZB77Gu54@debian64>
Christian Lamparter <chunkeey@gmail.com> writes:
> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>> Christian Lamparter <chunkeey@gmail.com> writes:
>>=20
>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wro=
te:
>> >> a additional array bounds check would be good
>> >
>> > Ah, about that:
>> >
>> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
>> > in the following way [0]:
>> > | bw =3D info2 & 3;
>> >
>> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by =
[1]:
>> > | txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>> >
>> > ATH10K_HW_BW is a macro defined as [2]:
>> > | #define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
>> >
>> > In both cases the bandwidth values already are limited to 0-3 by
>> > the "and 3" operation.
>>=20
>> Until someone changes that part of the code (and the firmware
>> interface). IMHO a switch is safer as there we don't have any risk of
>> out of bands access.
>
> The kbuild-bot/CI can catch this too.=20
>
> For example, it will look like this:
> drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid
> access past the end of 'ath10k_bw_to_mac80211' (4 4)
Sure, but after reading about all these security vulnerabilities I have
become even more cautious and try to avoid all tricky stuff.
> BTW:
> Have you noticed:
>
> <https://github.com/lede-project/source/blob/master/package/kernel/mac802=
11/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>
>
> Is this really your signed-off-by or not?
I suspect that patch is taken from my pending branch.
> In any case, you - as the maintainer - can modify the patch as
> you see fit. So, please do so.
Ok, we'll send v2.
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH] wireless: Always rewrite generated files from scratch
From: Thierry Reding @ 2017-12-14 13:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: David S . Miller, linux-wireless, netdev, linux-kernel
From: Thierry Reding <treding@nvidia.com>
Currently the certs C code generation appends to the generated files,
which is most likely a leftover from commit 715a12334764 ("wireless:
don't write C files on failures"). This causes duplicate code in the
generated files if the certificates have their timestamps modified
between builds and thereby trigger the generation rules.
Fixes: 715a12334764 ("wireless: don't write C files on failures")
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Based on next-20171214
net/wireless/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index d7d6cb00c47b..b662be3422e1 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -43,7 +43,7 @@ $(obj)/shipped-certs.c: $(wildcard $(srctree)/$(src)/certs/*.x509)
echo "$$allf"; \
echo '};'; \
echo 'unsigned int shipped_regdb_certs_len = sizeof(shipped_regdb_certs);'; \
- ) >> $@)
+ ) > $@)
$(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%) \
$(wildcard $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%)/*.x509)
@@ -66,4 +66,4 @@ $(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%) \
echo "$$allf"; \
echo '};'; \
echo 'unsigned int extra_regdb_certs_len = sizeof(extra_regdb_certs);'; \
- ) >> $@)
+ ) > $@)
--
2.15.1
^ permalink raw reply related
* Re: [v5 5/8] Bluetooth: btrsi: add new rsi bluetooth driver
From: Amitkumar Karwar @ 2017-12-14 14:22 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Kalle Valo, linux-wireless, Amitkumar Karwar,
Prameela Rani Garnepudi, open list:BLUETOOTH DRIVERS,
Siva Rebbagondla
In-Reply-To: <117694D2-5C98-4C40-BF02-FC1EDBF41FE8@holtmann.org>
On Wed, Dec 13, 2017 at 7:16 PM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
> Hi Amitkumar,
>
>> Redpine bluetooth driver is a thin driver which depends on
>> 'rsi_91x' driver for transmitting and receiving packets
>> to/from device. It creates hci interface when attach() is
>> called from 'rsi_91x' module.
>>
>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
>> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
>> ---
>> v5: Addressed review comments from Marcel.
>> Removed reduntant switch case code from rsi_hci_recv_pkt()
>> Changed bt_cb(skb)->pkt_type to hci_skb_pkt_type(skb)
>> Removed reduntant '\n' from BT_ERR and redundant BT_INFO messages
>> Changed u8 *pkt to const u8 *pkt in rsi_hci_recv_pkt()
>> v4: Removed rsi_hci.h file. Made the functions static(Marcel)
>> v3: Made BT_RSI module by default off(Marcel)
>> Removed redundant exported function rsi_get_hci_ops()(Marcel)
>> v2: Addressed review comments from Marcel
>> Removed unnecessary 'depends on BT && BT_RFOMM' line in Kconfig
>> Removed redundant BT_INFO messages
>> h_adapter initialization and declaration in a single line.
>> Removed unnecessary error checks for HCI_RUNNING and fsm_state
>> Allocated new skb with skb_realloc_headroom() API if headroom is not =
sufficient
>> Used get_unaligned_le16 helpers
>> Moved a structure and union from header file to btrsi.c file
>> ---
>> drivers/bluetooth/Kconfig | 11 +++
>> drivers/bluetooth/Makefile | 2 +
>> drivers/bluetooth/btrsi.c | 188 +++++++++++++++++++++++++++++++++++++++=
++++++
>> include/linux/rsi_header.h | 4 +-
>> 4 files changed, 204 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/bluetooth/btrsi.c
>>
>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>> index 60e1c7d..33d7514 100644
>> --- a/drivers/bluetooth/Kconfig
>> +++ b/drivers/bluetooth/Kconfig
>> @@ -378,4 +378,15 @@ config BT_QCOMSMD
>> Say Y here to compile support for HCI over Qualcomm SMD into the
>> kernel or say M to compile as a module.
>>
>> +config BT_RSI
>> + tristate "Redpine HCI support"
>> + default n
>> + help
>> + Redpine BT driver.
>> + This driver handles BT traffic from upper layers and pass
>> + to the RSI_91x coex module for further scheduling to device
>> +
>> + Say Y here to compile support for HCI over Redpine into the
>> + kernel or say M to compile as a module.
>> +
>> endmenu
>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>> index 4e4e44d..712af83a 100644
>> --- a/drivers/bluetooth/Makefile
>> +++ b/drivers/bluetooth/Makefile
>> @@ -28,6 +28,8 @@ obj-$(CONFIG_BT_QCA) +=3D btqca.o
>>
>> obj-$(CONFIG_BT_HCIUART_NOKIA) +=3D hci_nokia.o
>>
>> +obj-$(CONFIG_BT_RSI) +=3D btrsi.o
>> +
>
> actually I never caught this before. Since this driver is doing the HCI p=
ortion, for consistency CONFIG_BT_HCIRSI would be better.
>
>> btmrvl-y :=3D btmrvl_main.o
>> btmrvl-$(CONFIG_DEBUG_FS) +=3D btmrvl_debugfs.o
>>
>> diff --git a/drivers/bluetooth/btrsi.c b/drivers/bluetooth/btrsi.c
>> new file mode 100644
>> index 0000000..c9e92cc
>> --- /dev/null
>> +++ b/drivers/bluetooth/btrsi.c
>> @@ -0,0 +1,188 @@
>> +/**
>> + * Copyright (c) 2017 Redpine Signals Inc.
>> + *
>> + * Permission to use, copy, modify, and/or distribute this software for=
any
>> + * purpose with or without fee is hereby granted, provided that the abo=
ve
>> + * copyright notice and this permission notice appear in all copies.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRAN=
TIES
>> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE =
FOR
>> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAG=
ES
>> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN A=
N
>> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT=
OF
>> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>> + */
>> +#include <linux/version.h>
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <net/bluetooth/bluetooth.h>
>> +#include <net/bluetooth/hci_core.h>
>> +#include <linux/unaligned/le_byteshift.h>
>> +#include <linux/rsi_header.h>
>> +#include <net/genetlink.h>
>> +
>> +#define RSI_HEADROOM_FOR_BT_HAL 16
>> +#define RSI_FRAME_DESC_SIZE 16
>> +
>> +static struct rsi_hci_adapter {
>> + void *priv;
>> + struct rsi_proto_ops *proto_ops;
>> + struct hci_dev *hdev;
>> +};
>> +
>> +static int rsi_hci_open(struct hci_dev *hdev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int rsi_hci_close(struct hci_dev *hdev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int rsi_hci_flush(struct hci_dev *hdev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int rsi_hci_send_pkt(struct hci_dev *hdev, struct sk_buff *skb)
>> +{
>> + struct rsi_hci_adapter *h_adapter =3D hci_get_drvdata(hdev);
>> + struct sk_buff *new_skb =3D NULL;
>> +
>> + switch (hci_skb_pkt_type(skb)) {
>> + case HCI_COMMAND_PKT:
>> + hdev->stat.cmd_tx++;
>> + break;
>> + case HCI_ACLDATA_PKT:
>> + hdev->stat.acl_tx++;
>> + break;
>> + case HCI_SCODATA_PKT:
>> + hdev->stat.sco_tx++;
>> + break;
>> + }
>> +
>> + if (skb_headroom(skb) < RSI_HEADROOM_FOR_BT_HAL) {
>> + /* Insufficient skb headroom - allocate a new skb */
>> + new_skb =3D skb_realloc_headroom(skb, RSI_HEADROOM_FOR_BT_=
HAL);
>> + if (unlikely(!new_skb))
>> + return -ENOMEM;
>> + bt_cb(new_skb)->pkt_type =3D hci_skb_pkt_type(skb);
>> + kfree_skb(skb);
>> + skb =3D new_skb;
>> + }
>> +
>> + return h_adapter->proto_ops->coex_send_pkt(h_adapter->priv, skb,
>> + RSI_BT_Q);
>> +}
>> +
>> +static int rsi_hci_recv_pkt(void *priv, const u8 *pkt)
>> +{
>> + struct rsi_hci_adapter *h_adapter =3D priv;
>> + struct hci_dev *hdev =3D h_adapter->hdev;
>> + struct sk_buff *skb;
>> + int pkt_len =3D get_unaligned_le16(pkt) & 0x0fff;
>> +
>> + skb =3D dev_alloc_skb(pkt_len);
>> + if (!skb)
>> + return -ENOMEM;
>> +
>> + memcpy(skb->data, pkt + RSI_FRAME_DESC_SIZE, pkt_len);
>> + skb_put(skb, pkt_len);
>> + h_adapter->hdev->stat.byte_rx +=3D skb->len;
>> +
>> + hci_skb_pkt_type(skb) =3D pkt[14];
>> +
>> + return hci_recv_frame(hdev, skb);
>> +}
>> +
>> +static int rsi_hci_attach(void *priv, struct rsi_proto_ops *ops)
>> +{
>> + struct rsi_hci_adapter *h_adapter =3D NULL;
>> + struct hci_dev *hdev;
>> + int err =3D 0;
>> +
>> + h_adapter =3D kzalloc(sizeof(*h_adapter), GFP_KERNEL);
>> + if (!h_adapter)
>> + return -ENOMEM;
>> +
>> + h_adapter->priv =3D priv;
>> + ops->set_bt_context(priv, h_adapter);
>> + h_adapter->proto_ops =3D ops;
>> +
>> + hdev =3D hci_alloc_dev();
>> + if (!hdev) {
>> + BT_ERR("Failed to alloc HCI device");
>> + goto err;
>> + }
>> +
>> + h_adapter->hdev =3D hdev;
>> +
>> + if (ops->get_host_intf(priv) =3D=3D RSI_HOST_INTF_SDIO)
>> + hdev->bus =3D HCI_SDIO;
>> + else
>> + hdev->bus =3D HCI_USB;
>> +
>> + hci_set_drvdata(hdev, h_adapter);
>> + hdev->dev_type =3D HCI_PRIMARY;
>> + hdev->open =3D rsi_hci_open;
>> + hdev->close =3D rsi_hci_close;
>> + hdev->flush =3D rsi_hci_flush;
>> + hdev->send =3D rsi_hci_send_pkt;
>
> this doesn=E2=80=99t have to be in this patch, but if you support hdev->s=
et_bdaddr, hdev->set_diag etc. that would be good to add in a follow up.
>
>> +
>> + err =3D hci_register_dev(hdev);
>> + if (err < 0) {
>> + BT_ERR("HCI registration failed with errcode %d", err);
>> + hci_free_dev(hdev);
>> + goto err;
>> + }
>> +
>> + return 0;
>> +err:
>> + h_adapter->hdev =3D NULL;
>> + kfree(h_adapter);
>> + return -EINVAL;
>> +}
>> +
>> +static void rsi_hci_detach(void *priv)
>> +{
>> + struct rsi_hci_adapter *h_adapter =3D priv;
>> + struct hci_dev *hdev;
>> +
>> + if (!h_adapter)
>> + return;
>> +
>> + hdev =3D h_adapter->hdev;
>> + if (hdev) {
>> + hci_unregister_dev(hdev);
>> + hci_free_dev(hdev);
>> + h_adapter->hdev =3D NULL;
>> + }
>> +
>> + kfree(h_adapter);
>> +}
>> +
>> +const struct rsi_mod_ops rsi_bt_ops =3D {
>> + .attach =3D rsi_hci_attach,
>> + .detach =3D rsi_hci_detach,
>> + .recv_pkt =3D rsi_hci_recv_pkt,
>> +};
>> +EXPORT_SYMBOL(rsi_bt_ops);
>> +
>> +static int rsi_91x_bt_module_init(void)
>> +{
>> + return 0;
>> +}
>> +
>> +static void rsi_91x_bt_module_exit(void)
>> +{
>> + return;
>> +}
>> +
>> +module_init(rsi_91x_bt_module_init);
>> +module_exit(rsi_91x_bt_module_exit);
>> +MODULE_AUTHOR("Redpine Signals Inc");
>> +MODULE_DESCRIPTION("RSI BT driver");
>> +MODULE_SUPPORTED_DEVICE("RSI-BT");
>> +MODULE_LICENSE("Dual BSD/GPL=E2=80=9D);
>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
>
Thanks Marcel.
I will wait for Kalle's review and suggestions.
I will address your minor comments while preparing updated version
based on Kalle's feedback.
Regards,
Amitkumar
^ permalink raw reply
* Re: BCM4356 does not initalize after firmware update
From: Stanislaw Gruszka @ 2017-12-14 14:22 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <5A3240B9.90007@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
On Thu, Dec 14, 2017 at 10:13:29AM +0100, Arend van Spriel wrote:
> The cur_etheraddr is the first piece of info we try to get from the
> firmware. Could you build the driver with CONFIG_BRCMDBG and load
> the module with 'debug=0x181416'.
dmesg attached.
Thanks
Stanislaw
[-- Attachment #2: brcmfmac-dmesg.txt --]
[-- Type: text/plain, Size: 7714 bytes --]
[ 2665.150833] usbcore: deregistering interface driver brcmfmac
[ 2685.122741] brcmfmac: brcmfmac_module_init No platform data available.
[ 2685.123368] usbcore: registered new interface driver brcmfmac
[ 2685.129239] brcmfmac: brcmf_pcie_register Enter
[ 2685.131783] brcmfmac: brcmf_pcie_probe Enter 14e4:43ec (1/3)
[ 2685.132186] brcmfmac: brcmf_pcie_get_resource Phys addr : reg space = ffffa0ff40af0000 base addr 0x000000f7c00000
[ 2685.132194] brcmfmac: brcmf_pcie_get_resource Phys addr : mem space = ffffa0ff41800000 base addr 0x000000f7800000 size 0x400000
[ 2685.132213] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4356, rev=2
[ 2685.133298] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:47 base 0x18000000 wrap 0x18100000
[ 2685.133306] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:48 base 0x18001000 wrap 0x18101000
[ 2685.133312] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:6 base 0x18002000 wrap 0x18102000
[ 2685.133320] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:11 base 0x18003000 wrap 0x18103000
[ 2685.133326] brcmfmac: brcmf_chip_cores_check [5 ] core 0x81a:22 base 0x18004000 wrap 0x18104000
[ 2685.133332] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:21 base 0x18005000 wrap 0x18105000
[ 2685.133337] brcmfmac: brcmf_chip_cores_check [7 ] core 0x83d:2 base 0x18006000 wrap 0x18106000
[ 2685.133343] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0 base 0x00000000 wrap 0x1810a000
[ 2685.133348] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0 base 0x00000000 wrap 0x00000000
[ 2685.133353] brcmfmac: brcmf_chip_set_passive Enter
[ 2685.236599] brcmfmac: brcmf_pcie_reset_device config offset 0x0004, value 0x100106
[ 2685.236610] brcmfmac: brcmf_pcie_reset_device config offset 0x004c, value 0x4008
[ 2685.236618] brcmfmac: brcmf_pcie_reset_device config offset 0x0058, value 0x886805
[ 2685.236625] brcmfmac: brcmf_pcie_reset_device config offset 0x005c, value 0xfee0300c
[ 2685.236632] brcmfmac: brcmf_pcie_reset_device config offset 0x0060, value 0x0000
[ 2685.236638] brcmfmac: brcmf_pcie_reset_device config offset 0x0064, value 0x4182
[ 2685.236645] brcmfmac: brcmf_pcie_reset_device config offset 0x00dc, value 0x10001
[ 2685.236652] brcmfmac: brcmf_pcie_reset_device config offset 0x0228, value 0x0222
[ 2685.236658] brcmfmac: brcmf_pcie_reset_device config offset 0x0248, value 0x0000
[ 2685.236665] brcmfmac: brcmf_pcie_reset_device config offset 0x04e0, value 0x0017
[ 2685.236672] brcmfmac: brcmf_pcie_reset_device config offset 0x04f4, value 0x0000
[ 2685.236679] brcmfmac: brcmf_chip_set_passive Enter
[ 2685.237106] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000 size=786432 (0xc0000) sr=0 (0x0)
[ 2685.237137] brcmfmac: brcmf_chip_setup ccrev=47, pmurev=24, pmucaps=0x420e5f18
[ 2685.237141] brcmfmac: brcmf_get_module_param Enter, bus=2, chip=17238, rev=2
[ 2685.237148] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x000002
[ 2685.248121] brcmfmac: brcmf_fw_get_firmwares_pcie enter: dev=0000:03:00.0
[ 2685.252332] brcmfmac: brcmf_fw_request_code_done enter: dev=0000:03:00.0
[ 2685.252606] brcmfmac: brcmf_fw_request_nvram_done enter: dev=0000:03:00.0
[ 2685.256784] brcmfmac: brcmf_pcie_download_fw_nvram Halt ARM.
[ 2685.256790] brcmfmac: brcmf_pcie_download_fw_nvram Download FW brcm/brcmfmac4356-pcie.bin
[ 2685.588821] brcmfmac: brcmf_pcie_download_fw_nvram No matching NVRAM file found brcm/brcmfmac4356-pcie.txt
[ 2685.588831] brcmfmac: brcmf_pcie_download_fw_nvram Bring ARM in running state
[ 2685.588834] brcmfmac: brcmf_chip_set_active Enter
[ 2685.589035] brcmfmac: brcmf_pcie_download_fw_nvram Wait for FW init
[ 2685.639593] brcmfmac: brcmf_pcie_download_fw_nvram Shared RAM addr: 0x001f1528
[ 2685.639603] brcmfmac: brcmf_pcie_init_share_ram_info PCIe protocol version 5
[ 2685.639620] brcmfmac: brcmf_pcie_init_share_ram_info max rx buf post 255, rx dataoffset 0
[ 2685.639633] brcmfmac: brcmf_pcie_bus_console_init Console: base 23debc, buf 23dab4, size 1024
[ 2685.639657] brcmfmac: brcmf_pcie_init_ringbuffers Using TCM indices
[ 2685.639712] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 40
[ 2685.639736] brcmfmac: brcmf_pcie_request_irq Enter
[ 2685.639822] brcmfmac 0000:03:00.0: irq 31 for MSI/MSI-X
[ 2685.640052] brcmfmac: brcmf_attach Enter
[ 2685.640202] brcmfmac: brcmf_proto_attach Enter
[ 2685.642347] brcmfmac: brcmf_pcie_ring_mb_write_wptr W w_ptr 255 (0), ring 1
[ 2685.642354] brcmfmac: brcmf_pcie_ring_mb_ring_bell RING !
[ 2685.642594] brcmfmac: brcmf_pcie_ring_mb_write_wptr W w_ptr 8 (0), ring 0
[ 2685.642599] brcmfmac: brcmf_pcie_ring_mb_ring_bell RING !
[ 2685.642790] brcmfmac: brcmf_pcie_ring_mb_write_wptr W w_ptr 16 (0), ring 0
[ 2685.642796] brcmfmac: brcmf_pcie_ring_mb_ring_bell RING !
[ 2685.642838] brcmfmac: brcmf_fweh_register event handler registered for PSM_WATCHDOG
[ 2685.642846] brcmfmac: brcmf_bus_started
[ 2685.642851] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[ 2685.642855] brcmfmac: brcmf_add_if allocate netdev interface
[ 2685.642876] brcmfmac: brcmf_add_if ==== pid:1c, if:wlan%d (00:00:00:00:00:00) created ===
[ 2685.642881] brcmfmac: brcmf_bus_change_state 0 -> 1
[ 2685.642996] brcmfmac: brcmf_pcie_ring_mb_write_wptr W w_ptr 17 (0), ring 0
[ 2685.643001] brcmfmac: brcmf_pcie_ring_mb_ring_bell RING !
[ 2685.701557] brcmfmac: brcmf_pcie_quick_check_isr Enter
[ 2685.701602] brcmfmac: brcmf_pcie_isr_thread Enter 100
[ 2685.701613] brcmfmac: brcmf_pcie_handle_mb_data D2H_MB_DATA: 0x10000000
[ 2685.701634] brcmfmac: CONSOLE: 0d
[ 2685.701706] brcmfmac: CONSOLE: 000000.049 sp+ec 00184635
[ 2685.701778] brcmfmac: CONSOLE: 000000.049 sp+f4 00182ca7
[ 2685.701854] brcmfmac: CONSOLE: 000000.049 sp+100 000001df
[ 2685.701928] brcmfmac: CONSOLE: 000000.049 sp+140 0000823f
[ 2685.702003] brcmfmac: CONSOLE: 000000.049 sp+150 0018b8d9
[ 2687.642667] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on response for query command
[ 2687.650464] brcmfmac: brcmf_fil_cmd_data Failed: BCME_NOTDOWN (-5)
[ 2687.650469] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=cur_etheraddr, len=6
[ 2687.650471] brcmutil: data
[ 2687.650475] 00000000: 00 00 00 00 00 00 ......
[ 2687.650479] brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -5
[ 2687.658056] brcmfmac: brcmf_bus_started: failed: -5
[ 2687.663054] brcmfmac: brcmf_pcie_attach_bus: dongle is not responding
[ 2687.669658] brcmfmac: brcmf_pcie_remove Enter
[ 2687.669664] brcmfmac: brcmf_detach Enter
[ 2687.672761] brcmfmac: brcmf_bus_change_state 1 -> 0
[ 2687.672767] brcmfmac: brcmf_proto_detach Enter
[ 2687.672770] brcmfmac: brcmf_proto_msgbuf_detach Enter
[ 2687.674601] brcmfmac: brcmf_fweh_unregister event handler cleared for PSM_WATCHDOG
[ 2687.826671] brcmfmac: brcmf_pcie_reset_device config offset 0x0004, value 0x100106
[ 2687.826681] brcmfmac: brcmf_pcie_reset_device config offset 0x004c, value 0x4008
[ 2687.826689] brcmfmac: brcmf_pcie_reset_device config offset 0x0058, value 0x886805
[ 2687.826696] brcmfmac: brcmf_pcie_reset_device config offset 0x005c, value 0xfee0300c
[ 2687.826702] brcmfmac: brcmf_pcie_reset_device config offset 0x0060, value 0x0000
[ 2687.826709] brcmfmac: brcmf_pcie_reset_device config offset 0x0064, value 0x4192
[ 2687.826716] brcmfmac: brcmf_pcie_reset_device config offset 0x00dc, value 0x10001
[ 2687.826722] brcmfmac: brcmf_pcie_reset_device config offset 0x0228, value 0x0222
[ 2687.826729] brcmfmac: brcmf_pcie_reset_device config offset 0x0248, value 0x0000
[ 2687.826735] brcmfmac: brcmf_pcie_reset_device config offset 0x04e0, value 0x0017
[ 2687.826742] brcmfmac: brcmf_pcie_reset_device config offset 0x04f4, value 0x0000
^ permalink raw reply
* Re: [PATCH v3 1/3] mac80211: Add TXQ scheduling API
From: Toke Høiland-Jørgensen @ 2017-12-14 14:34 UTC (permalink / raw)
To: Felix Fietkau, make-wifi-fast, linux-wireless; +Cc: Johannes Berg
In-Reply-To: <78c2f69c-fafa-6270-33b5-fbce57f4a278@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2017-12-14 13:15, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>=20
>>> On 2017-10-31 12:27, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>>> This adds an API to mac80211 to handle scheduling of TXQs and changes =
the
>>>> interface between driver and mac80211 for TXQ handling as follows:
>>>>=20
>>>> - The wake_tx_queue callback interface no longer includes the TXQ. Ins=
tead,
>>>> the driver is expected to retrieve that from ieee80211_next_txq()
>>>>=20
>>>> - Two new mac80211 functions are added: ieee80211_next_txq() and
>>>> ieee80211_schedule_txq(). The former returns the next TXQ that shoul=
d be
>>>> scheduled, and is how the driver gets a queue to pull packets from. =
The
>>>> latter is called internally by mac80211 to start scheduling a queue,=
and
>>>> the driver is supposed to call it to re-schedule the TXQ after it is
>>>> finished pulling packets from it (unless the queue emptied).
>>>>=20
>>>> The ath9k and ath10k drivers are changed to use the new API.
>>>>=20
>>>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>>> Sorry that I didn't have time to give this a thorough review earlier,
>>> since I was pretty busy with other projects. Now that I'm working on
>>> porting mt76 to this new API, some things in this patch strike me as
>>> rather odd, and there might be some bugs and nasty limitations here:
>>>
>>> In the new API you can no longer select txq entries by hardware queue.
>>> When using multiple WMM queues, this could lead to station entries being
>>> requeued unnecessarily (because there is no room in the hw queue for the
>>> txq entry that ieee80211_next_txq happens to return).
>>=20
>> Yeah, there's some tension between enforcing fairness (which is a per
>> station thing) and the WMM queueing stuff (which gives priority based on
>> WMM levels and ignores stations). There are basically two ways to
>> resolve this: Prioritising fairness or prioritising WMM levels. In the
>> former case, we first select which station to transmit to, and then
>> select the highest WMM priority level queued *for that station* (the
>> last part of this is missing from the code as it is now). In the latter
>> case, we keep scheduling per-WMM, then enforce fairness within that.
>>=20
>> The former case has the potential to lead to starved hardware queues,
>> while the latter leads to unfairness. We had a bit of discussion of
>> which is better at netdev, but did not resolve it. Personally, I think
>> prioritising fairness is better, but I'm willing to be convinced
>> otherwise by data :). So my plan is to implement that fully and try it
>> out, then evaluate based on actual experiments...
>
> I don't really see how the approach taken in the current code is
> actually prioritising fairness by starving hardware queues, since any
> txq that can't be serviced in the current call because of queue depth
> will be requeued. So based on the traffic pattern this might actually
> lead to *more* unfairness.
Yeah, I'm not quite happy with the current state of the code as far as
that is concerned. I thought I would have had time to revisit this, but
then a bunch of other stuff came up and I never got around to it... Will
come back to this soon I hope... :/
>>> Since ieee80211_next_txq also refills the airtime fairness quantum, this
>>> might lead to some minor fairness issues.
>>=20
>> I'm planning to change the way the scheduler works anyway, so this issue
>> should go away. Haven't had time to do that yet, unfortunately.
>
> Well, the problem is that the new code inside ath9k is a lot harder to
> verify for correct behavior (regarding the queue starvation issue), and
> I would really like to avoid nasty regressions that will be a nightmare
> to debug.
Fair point, avoiding that would be good of course :)
>>> In ath9k the code used to have a loop that goes through all pending txq
>>> entries until it has filled the hw queues again. You replaced that with
>>> some calls to ath_txq_schedule which now only considers one single txq.
>>> There are several reasons why this queue could potentially not be servi=
ced:
>>> - ieee80211_tx_dequeue returned no frame
>>> - frame does not fit within BA window
>>> - txq was for another queue which is already filled
>>> Depending on the exact circumstances with enough stations this might
>>> lead to hardware queues getting starved.
>>=20
>> Well, that loop was already removed when I implemented the in-driver
>> fairness scheduler.
> Now that's not true. I'm looking at the diff for "mac80211: Add TXQ
> scheduling API", and it removes these lines:
>
> - /*
> - * If we succeed in scheduling something, immediately restart to
> make
> - * sure we keep the HW busy.
> - */
> - if(ath_tx_sched_aggr(sc, txq, tid)) {
> - if (!active) {
> - spin_lock_bh(&acq->lock);
> - list_move_tail(&tid->list, &acq->acq_old);
> - spin_unlock_bh(&acq->lock);
> - }
> - goto begin;
> - }
Yeah, that is removed (which I suppose you are right could be
problematic in itself), but it was only being called when
ath_tx_sched_aggr() succeeds. Before (pre-airtime fairness) it did a
full loop through all scheduled tids until the hwq was full, which is
what I thought you were referring to.
>> We can't really avoid those cases entirely if we
>> want to enforce fairness (the BAW case in particular; if the only
>> eligible station from an airtime PoW has a full BAW, you have to
>> throttle and can potentially starve hwqs). However, don't think this
>> happens much in practice (or we would have seen performance regressions
>> by now).
> I think so far you simply haven't had enough users hammering on the
> new code yet.
Heh. Guess that could also be the case... ;)
>> The 'txq was for another queue' case is new with this patch, but that
>> goes back to the WMM/fairness tention above.
> I agree that this is something we need to figure out. One aspect that I
> have a major problem with is the fact that this *really* intrusive patch
> that completely changes the way that ath9k schedules tx queues is hidden
> behind this "API change" patch.
>
> The way the API stands now, mt76 would require an equally big rework to
> a different scheduling model which I'm not comfortable with at this
> point.
That is a fair point. I suppose that I was thinking too far ahead to
what I wanted to do next and didn't pay enough attention to splitting
things up into incremental changes. Of course this becomes more
important when there are more drivers affected.
> I would like to suggest the following to resolve these issues:
>
> First we should revert these patches.
> We can respin them shortly after in a modified form where
> ieee80211_next_txq takes a 'queue' argument.
By 'queue' you mean 'wmm hardware queue', right?
> I'm almost done with the incremental change for that, and it also
> supports passing -1 for queue so incrementally switching to the
> scheduling that you're proposing will also work.
>
> With that in place we can replace the ath9k change with a much smaller
> patch that is easier to verify for correctness and won't introduce the
> potential regressions that I pointed out.
>
> I will take care of the mt76 porting today and I'll also help with
> sorting out the ath10k issues.
>
> Is that acceptable to you?
Yup, sounds quite reasonable. And help with ath10k will be much
appreciated, thanks :)
-Toke
^ permalink raw reply
* Re: ath10k: handling qos at STA side based on AP WMM enable/disable
From: Kalle Valo @ 2017-12-14 15:19 UTC (permalink / raw)
To: bpothuno; +Cc: ath10k, linux-wireless, Balaji Pothunoori
In-Reply-To: <1511863650-9419-1-git-send-email-bpothuno@qti.qualcomm.com>
bpothuno@qti.qualcomm.com wrote:
> Data packets are not sent by STA in case of STA joined to
> non QOS AP (WMM disabled AP). This is happening because of STA
> is sending data packets to firmware from host with qos enabled
> along with non qos queue value(TID = 16).
> Due to qos enabled, firmware is discarding the packet.
>
> This patch fixes this issue by updating the qos based on station
> WME capability field if WMM is disabled in AP.
>
> This patch is required by 10.4 family chipsets like
> QCA4019/QCA9888/QCA9884/QCA99X0.
> Firmware Versoin : 10.4-3.5.1-00018.
>
> For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
> has no effect.
>
> Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
07ffb4497360 ath10k: handling qos at STA side based on AP WMM enable/disable
--
https://patchwork.kernel.org/patch/10079089/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCHv2, 1/3] ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics
From: Kalle Valo @ 2017-12-14 15:27 UTC (permalink / raw)
To: akolli; +Cc: ath10k, linux-wireless, akolli, Anilkumar Kolli
In-Reply-To: <1512480685-28471-2-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> Remove CONFIG_MAC80211_DEBUGFS dependency on ath10k_sta_statistics().
> ath10k_sta_statistics() has per sta tx/rx stats and this should not
> be dependent on MAC80211_DEBUGFS.
>
> No changes in functionality.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
3 patches applied to ath-next branch of ath.git, thanks.
6a7f891178c2 ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics
7f9befbb555d ath10k: move pktlog_filter out of ath10k_debug
e8123bb74c4e ath10k: add per peer tx stats support for 10.2.4
--
https://patchwork.kernel.org/patch/10092915/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2, 1/2] dt: bindings: add new dt entry for ath10k calibration variant
From: Kalle Valo @ 2017-12-14 15:28 UTC (permalink / raw)
To: Sven Eckelmann
Cc: ath10k, linux-wireless, devicetree, robh+dt, mark.rutland,
ext.waldemar.rymarkiewicz, kvalo, Sven Eckelmann
In-Reply-To: <20171208103742.3181-2-sven.eckelmann@openmesh.com>
Sven Eckelmann <sven.eckelmann@openmesh.com> wrote:
> The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
> board data file on QCA4019 based devices. Multiple different boards share
> the same values. Only the original reference designs can currently be
> identified and loaded from the board-2.bin. But these will not result in
> the correct calibration data when combined with the pre-calibration data
> from the device.
>
> An additional "variant" information has to be provided (via SMBIOS or DT)
> to select the correct board data for a design which was modified by an ODM.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
40fb0eab30ba dt: bindings: add new dt entry for ath10k calibration variant
d06f26c5c8a4 ath10k: search DT for qcom,ath10k-calibration-variant
--
https://patchwork.kernel.org/patch/10102249/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wcn36xx: Add hardware scan offload support
From: Kalle Valo @ 2017-12-14 15:29 UTC (permalink / raw)
To: Loic Poulain
Cc: kvalo, linux-arm-msm, linux-wireless, wcn36xx, bjorn.andersson,
k.eugene.e, Loic Poulain
In-Reply-To: <1512725730-19188-1-git-send-email-loic.poulain@linaro.org>
Loic Poulain <loic.poulain@linaro.org> wrote:
> Current hw_scan implementation does not trigger offloaded
> hardware scan and seems to only put the device in a kind of
> listening mode (beacon/probe-response) for software scan.
> Since no probe request are generated by the software, current
> scanning method is similar to a passive scan.
>
> This patch introduces support for 'true' hardware offloaded scan.
> Hardware scan is configured and started via the start-scan-offload
> firmware message. Once scan has been completed a scan indicator
> message is received from firmware.
>
> Moreover, this patch includes support for directed probe-request,
> allowing connection with hidden APs. It also fixes scan issues with
> band-steering AP which are not 'visible' with passive scan (due to
> hidden ssid in beacons).
>
> Let's keep the 'legacy' scanning method in case scan-offload is not
> supported.
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
2f3bef4b247e wcn36xx: Add hardware scan offload support
--
https://patchwork.kernel.org/patch/10101937/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mt76x2: eeprom: fix typo in mt76x2_get_power_info_5g()
From: Felix Fietkau @ 2017-12-14 15:29 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: colin.king, linux-wireless
In-Reply-To: <2ae397aff0b058615a558a2352067fad2c9201e6.1513248071.git.lorenzo.bianconi@redhat.com>
On 2017-12-14 11:46, Lorenzo Bianconi wrote:
> Fix typo in 5GHz power vs channel eeprom parsing
>
> Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
^ permalink raw reply
* Re: [PATCH 0/2] Fix two possible NULL pointer dereferencing issues
From: Felix Fietkau @ 2017-12-14 15:30 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: dan.carpenter, linux-wireless
In-Reply-To: <cover.1513252573.git.lorenzo.bianconi@redhat.com>
On 2017-12-14 13:03, Lorenzo Bianconi wrote:
> Lorenzo Bianconi (2):
> mt76: fix possible NULL pointer dereferencing in mt76x2_ampdu_action()
> mt76: fix possible NULL pointer dereferencing in
> mt76x2_mac_write_txwi()
For both patches:
Acked-by: Felix Fietkau <nbd@nbd.name>
^ permalink raw reply
* Re: ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
From: Kalle Valo @ 2017-12-14 15:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: QCA ath9k Development, Sujith, Kalle Valo, linux-wireless,
kernel-janitors
In-Reply-To: <20171205143508.qbnbm4d3wesguu2g@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Smatch generates a warning here:
>
> drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action()
> error: buffer overflow 'ista->tid_state' 8 <= 15
>
> I don't know if it's a real bug or not but the other paths through this
> function all ensure that "tid" is less than ATH9K_HTC_MAX_TID (8) so
> checking here makes things more consistent.
>
> Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
413fd2f5c023 ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
--
https://patchwork.kernel.org/patch/10093021/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wcn36xx: Reduce spinlock in indication handler
From: Kalle Valo @ 2017-12-14 15:32 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, Kalle Valo, Loic Poulain, wcn36xx,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20171209003508.3507-1-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> The purpose of pushing indication on a list and handle these in a
> separate worker is to allow the handlers to sleep. It does therefor not
> make much sense to hold the queue spinlock through the entire indication
> worker function.
>
> By removing items from the queue early we don't need to hold the lock
> throughout the indication worker, allowing the individual handlers to
> sleep.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
6d1f37323f5b wcn36xx: Reduce spinlock in indication handler
--
https://patchwork.kernel.org/patch/10103469/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,1/4] ath10k: WMI: modify svc bitmap parsing for wcn3990
From: Kalle Valo @ 2017-12-14 15:33 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless, Rakesh Pillai, Govind Singh
In-Reply-To: <1513002175-2498-2-git-send-email-pillair@qti.qualcomm.com>
Rakesh Pillai <pillair@qti.qualcomm.com> wrote:
> Due to the limitation of wmi tlv parsing logic, if there are
> two parameters in a wmi event with same tlv tag, we can get only
> the last value, as it overwrites the prev value of the same tlv tag.
>
> The service ready event in wcn3990 contains two parameters of the
> same tag UINT32, due to which the svc bitmap is overwritten with the
> DBS support parameter.
>
> Refactor the service ready event parsing to allow parsing two tlv
> of the same tag UINT32 for wcn3990.
>
> Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
> Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
4 patches applied to ath-next branch of ath.git, thanks.
229329ff345f ath10k: wmi: modify svc bitmap parsing for wcn3990
1807da49733e ath10k: wmi: add management tx by reference support over wmi
9f2992fea580 ath10k: wmi: get wmi init parameter values from hw params
03a72288c546 ath10k: wmi: add hw params entry for wcn3990
--
https://patchwork.kernel.org/patch/10105283/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 02/14] mt76: fix returnvar.cocci warnings
From: Felix Fietkau @ 2017-12-14 15:39 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20171214153918.43774-1-nbd@nbd.name>
From: Fengguang Wu <fengguang.wu@intel.com>
drivers/net/wireless/mediatek/mt76/mt76x2_main.c:86:5-8: Unneeded variable: "ret". Return "0" on line 112
Remove unneeded variable used to store return value.
Generated by: scripts/coccinelle/misc/returnvar.cocci
Fixes: a5f6039c8f9c ("mt76: add driver code for MT76x2e")
CC: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
index 33469e32567b..88fe5e0de0b9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
@@ -83,7 +83,6 @@ mt76x2_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
struct mt76x2_dev *dev = hw->priv;
struct mt76x2_vif *mvif = (struct mt76x2_vif *) vif->drv_priv;
unsigned int idx = 0;
- int ret = 0;
if (vif->addr[0] & BIT(1))
idx = 1 + (((dev->mt76.macaddr[0] ^ vif->addr[0]) >> 2) & 7);
@@ -109,7 +108,7 @@ mt76x2_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
mvif->group_wcid.hw_key_idx = -1;
mt76x2_txq_init(dev, vif->txq);
- return ret;
+ return 0;
}
static void
--
2.14.2
^ permalink raw reply related
* [PATCH 04/14] mt76x2: fix transmission of encrypted management frames
From: Felix Fietkau @ 2017-12-14 15:39 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20171214153918.43774-1-nbd@nbd.name>
Hardware encryption seems to break encrypted unicast mgmt tx.
Unfortunately the hardware TXWI header does not have a bit to indicate
that a frame is software encrypted, so sw-encrypted frames need to use a
different WCID. For that to work, the CCMP PN needs to be generated in
software, which makes things a bit slower, so only do it for keys that
also need to tx management frames.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 16 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 8 +++++++-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 6 ++++--
4 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index aa0880bbea7f..f88d9a15210a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -129,6 +129,7 @@ struct mt76_wcid {
bool tx_rate_set;
u8 tx_rate_nss;
s8 max_txpwr_adj;
+ bool sw_iv;
};
struct mt76_txq {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
index f7c0df0759f7..a7416a01baa4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
@@ -171,10 +171,12 @@ void mt76x2_mac_write_txwi(struct mt76x2_dev *dev, struct mt76x2_txwi *txwi,
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_tx_rate *rate = &info->control.rates[0];
+ struct ieee80211_key_conf *key = info->control.hw_key;
u16 rate_ht_mask = FIELD_PREP(MT_RXWI_RATE_PHY, BIT(1) | BIT(2));
u16 txwi_flags = 0;
u8 nss;
s8 txpwr_adj, max_txpwr_adj;
+ u8 ccmp_pn[8];
memset(txwi, 0, sizeof(*txwi));
@@ -185,6 +187,20 @@ void mt76x2_mac_write_txwi(struct mt76x2_dev *dev, struct mt76x2_txwi *txwi,
txwi->pktid = 1;
+ if (wcid && wcid->sw_iv && key) {
+ u64 pn = atomic64_inc_return(&key->tx_pn);
+ ccmp_pn[0] = pn;
+ ccmp_pn[1] = pn >> 8;
+ ccmp_pn[2] = 0;
+ ccmp_pn[3] = 0x20 | (key->keyidx << 6);
+ ccmp_pn[4] = pn >> 16;
+ ccmp_pn[5] = pn >> 24;
+ ccmp_pn[6] = pn >> 32;
+ ccmp_pn[7] = pn >> 40;
+ txwi->iv = *((u32 *) &ccmp_pn[0]);
+ txwi->eiv = *((u32 *) &ccmp_pn[1]);
+ }
+
spin_lock_bh(&dev->mt76.lock);
if (wcid && (rate->idx < 0 || !rate->count)) {
txwi->rate = wcid->tx_rate;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
index 88fe5e0de0b9..02dd2cafa52f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
@@ -343,9 +343,15 @@ mt76x2_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
if (cmd == SET_KEY) {
key->hw_key_idx = wcid->idx;
wcid->hw_key_idx = idx;
+ if (key->flags & IEEE80211_KEY_FLAG_RX_MGMT) {
+ key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
+ wcid->sw_iv = true;
+ }
} else {
- if (idx == wcid->hw_key_idx)
+ if (idx == wcid->hw_key_idx) {
wcid->hw_key_idx = -1;
+ wcid->sw_iv = true;
+ }
key = NULL;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_tx.c b/drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
index 1a32e1fb8743..534e4bf9a34c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
@@ -36,7 +36,9 @@ void mt76x2_tx(struct ieee80211_hw *hw, struct ieee80211_tx_control *control,
msta = (struct mt76x2_sta *) control->sta->drv_priv;
wcid = &msta->wcid;
- } else if (vif) {
+ }
+
+ if (vif || (!info->control.hw_key && wcid->hw_key_idx != -1)) {
struct mt76x2_vif *mvif;
mvif = (struct mt76x2_vif *) vif->drv_priv;
@@ -166,7 +168,7 @@ int mt76x2_tx_prepare_skb(struct mt76_dev *mdev, void *txwi,
*tx_info = FIELD_PREP(MT_TXD_INFO_QSEL, qsel) |
MT_TXD_INFO_80211;
- if (!wcid || wcid->hw_key_idx == 0xff)
+ if (!wcid || wcid->hw_key_idx == 0xff || wcid->sw_iv)
*tx_info |= MT_TXD_INFO_WIV;
return 0;
--
2.14.2
^ permalink raw reply related
* [PATCH 03/14] mt76x2: remove some harmless WARN_ONs in tx status and rx path
From: Felix Fietkau @ 2017-12-14 15:39 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20171214153918.43774-1-nbd@nbd.name>
Discard affected packets instead. Should reduce the frequency of bogus
bug reports
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 28 ++++++++++++-------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
index a1f695e9b51c..f7c0df0759f7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
@@ -28,7 +28,7 @@ void mt76x2_mac_set_bssid(struct mt76x2_dev *dev, u8 idx, const u8 *addr)
get_unaligned_le16(addr + 4));
}
-static void
+static int
mt76x2_mac_process_rate(struct ieee80211_rx_status *status, u16 rate)
{
u8 idx = FIELD_GET(MT_RXWI_RATE_INDEX, rate);
@@ -42,7 +42,7 @@ mt76x2_mac_process_rate(struct ieee80211_rx_status *status, u16 rate)
idx += 4;
status->rate_idx = idx;
- return;
+ return 0;
case MT_PHY_TYPE_CCK:
if (idx >= 8) {
idx -= 8;
@@ -53,7 +53,7 @@ mt76x2_mac_process_rate(struct ieee80211_rx_status *status, u16 rate)
idx = 0;
status->rate_idx = idx;
- return;
+ return 0;
case MT_PHY_TYPE_HT_GF:
status->enc_flags |= RX_ENC_FLAG_HT_GF;
/* fall through */
@@ -67,8 +67,7 @@ mt76x2_mac_process_rate(struct ieee80211_rx_status *status, u16 rate)
status->nss = FIELD_GET(MT_RATE_INDEX_VHT_NSS, idx) + 1;
break;
default:
- WARN_ON(1);
- return;
+ return -EINVAL;
}
if (rate & MT_RXWI_RATE_LDPC)
@@ -92,6 +91,8 @@ mt76x2_mac_process_rate(struct ieee80211_rx_status *status, u16 rate)
default:
break;
}
+
+ return 0;
}
static __le16
@@ -272,12 +273,10 @@ int mt76x2_mac_process_rx(struct mt76x2_dev *dev, struct sk_buff *skb,
status->freq = dev->mt76.chandef.chan->center_freq;
status->band = dev->mt76.chandef.chan->band;
- mt76x2_mac_process_rate(status, rate);
-
- return 0;
+ return mt76x2_mac_process_rate(status, rate);
}
-static void
+static int
mt76x2_mac_process_tx_rate(struct ieee80211_tx_rate *txrate, u16 rate,
enum nl80211_band band)
{
@@ -293,13 +292,13 @@ mt76x2_mac_process_tx_rate(struct ieee80211_tx_rate *txrate, u16 rate,
idx += 4;
txrate->idx = idx;
- return;
+ return 0;
case MT_PHY_TYPE_CCK:
if (idx >= 8)
idx -= 8;
txrate->idx = idx;
- return;
+ return 0;
case MT_PHY_TYPE_HT_GF:
txrate->flags |= IEEE80211_TX_RC_GREEN_FIELD;
/* fall through */
@@ -312,8 +311,7 @@ mt76x2_mac_process_tx_rate(struct ieee80211_tx_rate *txrate, u16 rate,
txrate->idx = idx;
break;
default:
- WARN_ON(1);
- return;
+ return -EINVAL;
}
switch (FIELD_GET(MT_RXWI_RATE_BW, rate)) {
@@ -326,12 +324,14 @@ mt76x2_mac_process_tx_rate(struct ieee80211_tx_rate *txrate, u16 rate,
txrate->flags |= IEEE80211_TX_RC_80_MHZ_WIDTH;
break;
default:
- WARN_ON(1);
+ return -EINVAL;
break;
}
if (rate & MT_RXWI_RATE_SGI)
txrate->flags |= IEEE80211_TX_RC_SHORT_GI;
+
+ return 0;
}
static void
--
2.14.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox