* Re: ath5k: fix EEPROM dumping via debugfs
From: Kalle Valo @ 2016-09-03 10:02 UTC (permalink / raw)
To: Sergey Ryazanov
Cc: Linux Wireless, Jiri Slaby, Nick Kossifidis, Luis R . Rodriguez
In-Reply-To: <1470136768-28077-1-git-send-email-ryazanov.s.a@gmail.com>
Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
> EEPROM size calculated in 16-bit words, so we should take into account
> this fact during buffer allocation.
>
> CC: Jiri Slaby <jirislaby@gmail.com>
> CC: Nick Kossifidis <mickflemm@gmail.com>
> CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
af8a9a67c346 ath5k: fix EEPROM dumping via debugfs
--
Sent by pwcli
https://patchwork.kernel.org/patch/9255675/
^ permalink raw reply
* Re: [1/1] mwifiex: remove superfluous condition
From: Kalle Valo @ 2016-09-03 10:00 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
linux-kernel, Heinrich Schuchardt
In-Reply-To: <1469961555-2123-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> for_each_property_of_node is only executed if the
> property prop is not NULL.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
2f69e67058fb mwifiex: remove superfluous condition
--
Sent by pwcli
https://patchwork.kernel.org/patch/9253329/
^ permalink raw reply
* Re: bcma: support BCM53573 series of wireless SoCs
From: Kalle Valo @ 2016-09-03 9:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rafał Miłecki,
open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA), open list
In-Reply-To: <1469471640-15656-1-git-send-email-zajec5@gmail.com>
Rafał Miłecki wrote:
> BCM53573 seems to be the first series of Northstar family with wireless
> on the chip. The base models are BCM53573-s (A0, A1) and there is also
> BCM47189B0 which seems to be some small modification.
>
> The only problem with these chipsets seems to be watchdog. It's totally
> unavailable on 53573A0 / 53573A1 and preferable PMU watchdog is broken
> on 53573B0 / 53573B1.
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
3f37ec79dd21 bcma: support BCM53573 series of wireless SoCs
--
Sent by pwcli
https://patchwork.kernel.org/patch/9246319/
^ permalink raw reply
* Re: [v2, 1/8] mwifiex: Fixed endianness problem for big endian platform
From: Kalle Valo @ 2016-09-03 9:58 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Karthik D A,
Amitkumar Karwar
In-Reply-To: <1469461871-3135-2-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Karthik D A <karthida@marvell.com>
>
> The driver sends and recives information to and from the firmware.
> Correct endianness should be ensured as firmware follows little
> endian format and host can be little/big endian.
>
> Signed-off-by: Karthik D A <karthida@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 8 patches applied to wireless-drivers-next.git:
902831a7629b mwifiex: Fixed endianness problem for big endian platform
e5988c62b9e6 mwifiex: add region code information in debugfs
c8ccf3ade785 mwifiex: fix failed to reconnect after interface disabled/enabled
c2a8f0ff9c6c mwifiex: support random MAC address for scanning
99ffe72cdae4 mwifiex: process rxba_sync event
5536c4aafcac mwifiex: remove misleading disconnect message
432da7d243da mwifiex: add HT aggregation support for adhoc mode
441756b6a6e3 mwifiex: fix radar detection issue
--
Sent by pwcli
https://patchwork.kernel.org/patch/9245981/
^ permalink raw reply
* Re: [-next] wlcore: spi: fix non static symbol warning
From: Kalle Valo @ 2016-09-03 9:55 UTC (permalink / raw)
To: Wei Yongjun
Cc: Andrew F. Davis, Arnd Bergmann, Igor Grinberg, Uri Mashiach,
Rob Herring, Reizer, Eyal, Wei Yongjun, linux-wireless
In-Reply-To: <1469196488-21050-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun <weiyj.lk@gmail.com> wrote:
> Fixes the following sparse warning:
>
> drivers/net/wireless/ti/wlcore/spi.c:87:34: warning:
> symbol 'wilink_data' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
4ad0579a28c0 wlcore: spi: fix non static symbol warning
--
Sent by pwcli
https://patchwork.kernel.org/patch/9243695/
^ permalink raw reply
* Re: hostap: Use memdup_user() to reuse code
From: Kalle Valo @ 2016-09-03 9:55 UTC (permalink / raw)
To: Rajan Vaja; +Cc: j, linux-wireless
In-Reply-To: <1469088884-28469-1-git-send-email-rajan.vaja@gmail.com>
Rajan Vaja <rajan.vaja@gmail.com> wrote:
> Fix coccicheck warning which recommends to
> use memdup_user() instead of reimplementing its
> code.
>
> This patch fixes below coccicheck warnings:
>
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3044:9-16: WARNING
> opportunity for memdup_user
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3806:9-16: WARNING
> opportunity for memdup_user
>
> Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
8432ebd66205 hostap: Use memdup_user() to reuse code
--
Sent by pwcli
https://patchwork.kernel.org/patch/9241109/
^ permalink raw reply
* [PATCH] ath10k: ensure pdev sta kickout threshold is set.
From: greearb @ 2016-09-02 19:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
The station kickout threshold is a pdev value, not per vdev,
so it should be set all the time, not just when vdev is an
AP. This should fix setting the station kickout threshold
when using ibss interfaces.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 27 ++++++++++++++++++---------
drivers/net/wireless/ath/ath10k/mac.h | 2 ++
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 39fcdad..4aa0736 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -744,21 +744,26 @@ static int ath10k_peer_create(struct ath10k *ar,
return 0;
}
+int ath10k_mac_set_pdev_kickout(struct ath10k *ar)
+{
+ u32 param = ar->wmi.pdev_param->sta_kickout_th;
+ int rv;
+
+ rv = ath10k_wmi_pdev_set_param(ar, param,
+ ar->sta_xretry_kickout_thresh);
+ if (rv) {
+ ath10k_warn(ar, "failed to set sta kickout threshold to %d: %d\n",
+ ar->sta_xretry_kickout_thresh, rv);
+ }
+ return rv;
+}
+
static int ath10k_mac_set_kickout(struct ath10k_vif *arvif)
{
struct ath10k *ar = arvif->ar;
u32 param;
int ret;
- param = ar->wmi.pdev_param->sta_kickout_th;
- ret = ath10k_wmi_pdev_set_param(ar, param,
- ar->sta_xretry_kickout_thresh);
- if (ret) {
- ath10k_warn(ar, "failed to set kickout threshold on vdev %i: %d\n",
- arvif->vdev_id, ret);
- return ret;
- }
-
param = ar->wmi.vdev_param->ap_keepalive_min_idle_inactive_time_secs;
ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, param,
ATH10K_KEEPALIVE_MIN_IDLE);
@@ -5427,6 +5432,10 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->peer_id = HTT_INVALID_PEERID;
}
+ ret = ath10k_mac_set_pdev_kickout(ar);
+ if (ret)
+ return ret;
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
ret = ath10k_mac_set_kickout(arvif);
if (ret) {
diff --git a/drivers/net/wireless/ath/ath10k/mac.h b/drivers/net/wireless/ath/ath10k/mac.h
index 5f027ec..1a34cab 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -113,4 +113,6 @@ static inline void ath10k_tx_h_seq_no(struct ieee80211_vif *vif,
}
}
+int ath10k_mac_set_pdev_kickout(struct ath10k *ar);
+
#endif /* _MAC_H_ */
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-02 18:23 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <20160902164623.GY15161@tuxbot>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote:
>
>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>
>> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> > @@ -1,6 +1,6 @@
>> > config WCN36XX
>> > tristate "Qualcomm Atheros WCN3660/3680 support"
>> > - depends on MAC80211 && HAS_DMA
>> > + depends on MAC80211 && HAS_DMA && QCOM_SMD
>>
>> While I had this patch on my pending branch I noticed that I can't
>> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
>> example then it's easy to miss mac80211 API changes etc. Is there any
>> way we could continue build testing wcn36xx on x86 (or all) platforms?
>>
>
> Sorry about that, we should at least be able to COMPILE_TEST it in
> non-qcom builds. Thanks for letting me know.
Yeah, that would be better. Even though it's a bit shame that
COMPILE_TEST disables DEBUG_INFO (I use the same build also for
development) so I need to toggle it on and off whenever I need debug
symbols. Oh well...
> And the driver should also depend on QCOM_WCNSS_CTRL, in the normal
> case.
>
> I'll respin this, unless you prefer an incremental patch for those
> changes(?)
Yes, please respin.
>> Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
>> with help of backports project. I can't do that anymore, right?
>>
>
> This has been tested on 8064, 8974 and 8916. So your Nexus 4 is covered.
>
> Unfortunately I don't have a Nexus 4, but we currently have Nexus 7
> (the 8064 version), Xperia Z, Xperia Z1 and DB410c using this chip and
> all four has been tested with this code.
Actually I meant running wcn36xx on older kernels, where your QCOM_SMD
is not yet supported.
> I've staged the PIL/remoteproc (firmware "loader") driver for v4.9, so
> with this patch the only thing missing to fill in the dts files is one
> clock from the RPM.
Nice.
> JFYI, There seems to be some race in the removal path, which I will look
> into. But I would prefer if we could merge this to make the driver
> usable, and more accessible to work on.
Sure, a race like that isn't that big of a deal compared to the benefits
your work brings. But it's good to document knows regressions to the
commit log anyway so that others can be prepared if they test it.
--
Kalle Valo
^ permalink raw reply
* Re: Debugging RTL8192CU firmware loading on 3.12 powerpc
From: Larry Finger @ 2016-09-02 17:53 UTC (permalink / raw)
To: Simon Wunderlich, linux-wireless; +Cc: sven, Pannirselvam Kanagaratnam
In-Reply-To: <1586991.4QUcrJhXOm@prime>
[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]
On 09/02/2016 03:50 AM, Simon Wunderlich wrote:
> Hi,
>
> we are trying to integrate a RTL8192CU based WiFi adapter (TP-Link TL-WL822N)
> on a PowerPC based platform running a vendor-supplied/modified 3.12 kernel
> using compat-wireless (I've tried 2016-01-06 and 2016-06-20 versions). While
> the adapter works fine on my Laptop (using Debian 4.6 and 4.7 kernels), it
> seems the firmware loading fails on the PowerPC box. Here is some output from
> the kernel log:
>
> [ 36.945820] rtl8192cu: Chip version 0x11
> [ 37.026208] rtl8192cu: MAC address: ec:08:6b:15:38:0e
> [ 37.031301] rtl8192cu: Board Type 0
> [ 37.035074] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [ 37.040911] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [ 37.049583] usbcore: registered new interface driver rtl8192cu
> [...]
> [ 221.588911] rtl8192cu:_ResetDigitalProcedure1():<0-0> #####=> 8051 reset
> failed!.........................
> [ 221.637599] rtl8192cu: MAC auto ON okay!
> [ 221.674610] rtl8192cu: Tx queue select: 0x05
> [ 233.233554] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready
> fail!! REG_MCUFWDL:0x00030006 .
> [ 233.233566] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not
> ready to run!
>
> The outputs at 221 starts when I enable hostapd with a minimal AP-starting
> configuration.
>
> Do you have any recommendations where the firmware loading problems could come
> from, and where we could start to debug? Any pointers would be appreciated.
Simon,
The patch I included in my previous E-mail, and attached here, does get the
firmware loaded correctly. There is still a problem that prevents
authentication. I'm still looking for that issue.
Larry
[-- Attachment #2: rtl8192cu_fix_firmware_write.patch --]
[-- Type: text/x-patch, Size: 966 bytes --]
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
index 43fcb25..cd7ae70 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -74,18 +74,19 @@ static void _rtl92c_fw_block_write(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
u32 blocksize = sizeof(u32);
u8 *bufferptr = (u8 *)buffer;
- u32 *pu4byteptr = (u32 *)buffer;
+ __le32 *pu4byteptr = (__le32 *)buffer;
u32 i, offset, blockcount, remainsize;
+ u32 data;
blockcount = size / blocksize;
remainsize = size % blocksize;
for (i = 0; i < blockcount; i++) {
offset = i * blocksize;
+ data = le32_to_cpu(*(pu4byteptr + i));
rtl_write_dword(rtlpriv, (FW_8192C_START_ADDRESS + offset),
- *(pu4byteptr + i));
+ data);
}
-
if (remainsize) {
offset = blockcount * blocksize;
bufferptr += offset;
^ permalink raw reply related
* Re: Debugging RTL8192CU firmware loading on 3.12 powerpc
From: Larry Finger @ 2016-09-02 17:17 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Sven Eckelmann, Arend Van Spriel, linux-wireless,
Pannirselvam Kanagaratnam
In-Reply-To: <6578938.N4SWO0a2Ic@bentobox>
On 09/02/2016 06:26 AM, Sven Eckelmann wrote:
> On Freitag, 2. September 2016 13:13:20 CEST Arend Van Spriel wrote:
> [...]
>>> Do you have any recommendations where the firmware loading problems could
>>> come from, and where we could start to debug? Any pointers would be
>>> appreciated.
>> Hi Simon,
>>
>> Could it be an endian issue?
>
> Yes, it could be one (at least I've also guessed this - I could still be
> completely wrong). But the problem is now to find a good starting point for
> the debugging effort.
>
> I've only looked at Simon's screen once while he gather USB dumps but didn't
> spot any obvious at that time. There was also the problem that the comparison
> dump looked already a lot different due to some timing differences.
>
> I think Simon can give you later more details (when required).
Simon,
Yes, it is an endian issue. I can see part of the problem, but I do not have a
fix yet.
The firmware is read in as an array of bytes, thus it is effectively in
little-endian order. When it is written back to the device in routine
_rtl92c_fw_block_write(), the data output uses 32-bit writes. Of course, all
data supplied in all 2- and 4-byte writes is assumed to be in CPU order. As the
device needs the data to be little-endian, it will be byte swapped on BE
machines. As a result, the firmware is written out in the wrong byte order. I
think that this problem should be fixed with:
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
index 43fcb25..cd7ae70 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -74,18 +74,19 @@ static void _rtl92c_fw_block_write(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
u32 blocksize = sizeof(u32);
u8 *bufferptr = (u8 *)buffer;
- u32 *pu4byteptr = (u32 *)buffer;
+ __le32 *pu4byteptr = (__le32 *)buffer;
u32 i, offset, blockcount, remainsize;
+ u32 data;
blockcount = size / blocksize;
remainsize = size % blocksize;
for (i = 0; i < blockcount; i++) {
offset = i * blocksize;
+ data = le32_to_cpu(*(pu4byteptr + i));
rtl_write_dword(rtlpriv, (FW_8192C_START_ADDRESS + offset),
- *(pu4byteptr + i));
+ data);
}
-
if (remainsize) {
offset = blockcount * blocksize;
bufferptr += offset;
Unfortunately, applying the patch results in a checksum error on my PPC.
I'll let you know what I find.
Larry
^ permalink raw reply related
* Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-02 16:46 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <87mvjqz2ul.fsf@kamboji.qca.qualcomm.com>
On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
> > The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > channel, as such it should be a SMD client. This patch makes this
> > transition, now that we have the necessary frameworks available.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> [...]
>
> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> > @@ -1,6 +1,6 @@
> > config WCN36XX
> > tristate "Qualcomm Atheros WCN3660/3680 support"
> > - depends on MAC80211 && HAS_DMA
> > + depends on MAC80211 && HAS_DMA && QCOM_SMD
>
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?
>
Sorry about that, we should at least be able to COMPILE_TEST it in
non-qcom builds. Thanks for letting me know.
And the driver should also depend on QCOM_WCNSS_CTRL, in the normal
case.
I'll respin this, unless you prefer an incremental patch for those
changes(?)
> Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
> with help of backports project. I can't do that anymore, right?
>
This has been tested on 8064, 8974 and 8916. So your Nexus 4 is covered.
Unfortunately I don't have a Nexus 4, but we currently have Nexus 7
(the 8064 version), Xperia Z, Xperia Z1 and DB410c using this chip and
all four has been tested with this code.
I've staged the PIL/remoteproc (firmware "loader") driver for v4.9, so
with this patch the only thing missing to fill in the dts files is one
clock from the RPM.
JFYI, There seems to be some race in the removal path, which I will look
into. But I would prefer if we could merge this to make the driver
usable, and more accessible to work on.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client
From: Marcel Holtmann @ 2016-09-02 16:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Bjorn Andersson, Eugene Krasnikov, wcn36xx, linux-wireless,
Network Development, LKML, linux-arm-msm
In-Reply-To: <87mvjqz2ul.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> @@ -1,6 +1,6 @@
>> config WCN36XX
>> tristate "Qualcomm Atheros WCN3660/3680 support"
>> - depends on MAC80211 && HAS_DMA
>> + depends on MAC80211 && HAS_DMA && QCOM_SMD
>
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?
I would also like that for the btqcomsmd Bluetooth driver. Doing quick build tests on x86 would be great.
Regards
Marcel
^ permalink raw reply
* Re: ath9k: fix AR5416 access GPIO warning
From: Kalle Valo @ 2016-09-02 16:34 UTC (permalink / raw)
To: miaoqing pan; +Cc: linux-wireless, ath9k-devel, s.l-h, Miaoqing Pan
In-Reply-To: <1470296914-9152-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> The warning was seen on AR5416 chip, which invoke ath9k_hw_gio_get()
> before the GPIO initialized correctly.
>
> WARNING: CPU: 1 PID: 1159 at ~/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
> ...
> CPU: 1 PID: 1159 Comm: systemd-udevd Not tainted 4.7.0-rc7-aptosid-amd64 #1 aptosid 4.7~rc7-1~git92.slh.3
> Hardware name: /DH67CL, BIOS BLH6710H.86A.0160.2012.1204.1156 12/04/2012
> 0000000000000286 00000000f912d633 ffffffff81290fd3 0000000000000000
> 0000000000000000 ffffffff81063fd4 ffff88040c6dc018 0000000000000000
> 0000000000000002 0000000000000000 0000000000000100 ffff88040c6dc018
> Call Trace:
> [<ffffffff81290fd3>] ? dump_stack+0x5c/0x79
> [<ffffffff81063fd4>] ? __warn+0xb4/0xd0
> [<ffffffffa0668fb8>] ? ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Thanks, 1 patch applied to ath-current branch of ath.git:
db7b542e4a78 ath9k: fix AR5416 access GPIO warning
--
Sent by pwcli
https://patchwork.kernel.org/patch/9262875/
^ permalink raw reply
* Re: ath10k: fix throughput regression in multi client mode
From: Valo, Kalle @ 2016-09-02 16:30 UTC (permalink / raw)
To: Manoharan, Rajkumar
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
rmanohar@codeaurora.org
In-Reply-To: <425ad8d804bf46feada839a8e0d0c77e@euamsexm01a.eu.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
>> commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing
>> severe throughput drop in multi client mode. This issue is originally
>> reported in veriwave setup with 50 clients with TCP downlink traffic.
>> While increasing number of clients, the average throughput drops
>> gradually. With 50 clients, the combined peak throughput is decreased
>> to 98 Mbps whereas reverting given commit restored it to 550 Mbps.
>>=20
>> Processing txqs for every tx completion is causing overhead. Ideally for
>> management frame tx completion, pending txqs processing can be avoided.
>> The change partly reverts the commit "ath10k: improve tx scheduling".
>> Processing pending txqs after all skbs tx completion will yeild enough
>> room to burst tx frames.
>>=20
>> Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling")
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>
> I'm planning to queue this to 4.8 if no objections.
Actually the patch doesn't apply to ath-current branch so I'll apply to
ath-next instead.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-02 16:24 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <1472741468-24762-1-git-send-email-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> channel, as such it should be a SMD client. This patch makes this
> transition, now that we have the necessary frameworks available.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[...]
> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> @@ -1,6 +1,6 @@
> config WCN36XX
> tristate "Qualcomm Atheros WCN3660/3680 support"
> - depends on MAC80211 && HAS_DMA
> + depends on MAC80211 && HAS_DMA && QCOM_SMD
While I had this patch on my pending branch I noticed that I can't
compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
example then it's easy to miss mac80211 API changes etc. Is there any
way we could continue build testing wcn36xx on x86 (or all) platforms?
Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
with help of backports project. I can't do that anymore, right?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 1/6] rtl8723au: remove declaration of unimplemented functions
From: Kalle Valo @ 2016-09-02 16:18 UTC (permalink / raw)
To: Luca Ceresoli
Cc: devel, Larry Finger, Jes Sorensen, Greg Kroah-Hartman,
linux-wireless, linux-kernel
In-Reply-To: <1472821069-5437-1-git-send-email-luca@lucaceresoli.net>
Luca Ceresoli <luca@lucaceresoli.net> writes:
> These functions have been declared without any implementation since
> the first commit (364e30ebd2dbaccba430c603da03e68746eb932a) and there
> has been no mention of them in following commits.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: devel@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Changes v1 -> v2:
> - improve the commit message.
> ---
> drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
> 1 file changed, 3 deletions(-)
Please prefix staging drivers with "staging:".
--
Kalle Valo
^ permalink raw reply
* Re: [v2] ath9k: mark ath_fill_led_pin() static
From: Kalle Valo @ 2016-09-02 16:09 UTC (permalink / raw)
To: Baoyou Xie
Cc: ath9k-devel, kvalo, linux-wireless, ath9k-devel, netdev,
linux-kernel, arnd, baoyou.xie, xie.baoyou
In-Reply-To: <1472473273-2972-1-git-send-email-baoyou.xie@linaro.org>
Baoyou Xie <baoyou.xie@linaro.org> wrote:
> We get 1 warning about global functions without a declaration
> in the ath9k gpio driver when building with W=1:
> drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype for 'ath_fill_led_pin' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is declared
> and don't need a declaration, but can be made static.
> so this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Thanks, 1 patch applied to ath-next branch of ath.git:
c39265f72ae6 ath9k: mark ath_fill_led_pin() static
--
Sent by pwcli
https://patchwork.kernel.org/patch/9303795/
^ permalink raw reply
* Re: ath10k: fix spelling mistake "montior" -> "monitor"
From: Kalle Valo @ 2016-09-02 16:03 UTC (permalink / raw)
To: Colin Ian King; +Cc: ath10k, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160826180852.32248-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in ath10k_warn message.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
7f03d3069381 ath10k: fix spelling mistake "montior" -> "monitor"
--
Sent by pwcli
https://patchwork.kernel.org/patch/9301869/
^ permalink raw reply
* Re: [v5] ath10k: Fix broken NULL func data frame status for 10.4
From: Kalle Valo @ 2016-09-02 16:00 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, Tamizh chelvam, linux-wireless,
Mohammed Shafi Shajakhan
In-Reply-To: <1472199140-8404-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Older firmware with HTT delivers incorrect tx status for null func
> frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
> Also this workaround results in reporting of incorrect null func status
> for 10.4. Fix this is by introducing a firmware feature flag for 10.4
> so that this workaround is skipped and proper tx status for null func
> frames are reported
>
> Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
2cdce425aa33 ath10k: Fix broken NULL func data frame status for 10.4
--
Sent by pwcli
https://patchwork.kernel.org/patch/9300961/
^ permalink raw reply
* Re: ath10k: replace config_enabled() with IS_REACHABLE()
From: Kalle Valo @ 2016-09-02 15:57 UTC (permalink / raw)
To: Masahiro Yamada
Cc: ath10k, linux-wireless, Masahiro Yamada, Andrew Morton,
linux-kernel, netdev
In-Reply-To: <1471969646-13119-1-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Commit 97f2645f358b ("tree-wide: replace config_enabled() with
> IS_ENABLED()") mostly did away with config_enabled().
>
> This is one of the postponed TODO items as config_enabled() is used
> for a tristate option here. Theoretically, config_enabled() is
> equivalent to IS_BUILTIN(), but I guess IS_REACHABLE() is the best
> fit for this case because both CONFIG_HWMON and CONFIG_ATH10K are
> tristate.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
749bc03ae2cd ath10k: replace config_enabled() with IS_REACHABLE()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9295945/
^ permalink raw reply
* Re: linux-4.8-rcX: ath9k traceback
From: Mimi Zohar @ 2016-09-02 15:56 UTC (permalink / raw)
To: Kalle Valo
Cc: QCA ath9k Development, ath9k-devel, linux-wireless,
Luis R. Rodriguez
In-Reply-To: <87eg5338b5.fsf@purkki.adurom.net>
On Thu, 2016-09-01 at 19:15 +0300, Kalle Valo wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
>
> > There weren't any problems on linux-4.7 kernels. I'm getting the
> > following traceback on linux-4.8-rc1/-rc4 kernels. Let me know if you
> > need any additional information.
> >
> > [ 64.006529] WARNING: CPU: 3 PID: 94 at drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_beacon_config+0x12c/0x140 [ath9k]
>
> This should fix it:
>
> ath9k: fix client mode beacon configuration
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=05860bed491b114a9f2d7a4f6e09fb02c0b69056
Yep, that resolved the problem. Thanks!
Mimi
^ permalink raw reply
* Re: ath10k: Added support for extended dbglog module id for 10.4
From: Kalle Valo @ 2016-09-02 15:56 UTC (permalink / raw)
To: c_mkenna; +Cc: ath10k, mkenna, linux-wireless, Maharaja Kennadyrajan
In-Reply-To: <1471946736-28214-1-git-send-email-c_mkenna@qti.qualcomm.com>
c_mkenna@qti.qualcomm.com wrote:
> From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
>
> For 10.4 fw versions, dbglog module id has been extended from u32
> to u64, hence this patch fixes the same in the ath10k driver side.
>
> This patch doesn't break the older 10.4 releases. The FW change
> is already present in the older FWs.
>
> Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
afcbc82cea52 ath10k: Added support for extended dbglog module id for 10.4
--
Sent by pwcli
https://patchwork.kernel.org/patch/9295361/
^ permalink raw reply
* Re: [2/2] ath10k: use complete() instead complete_all()
From: Kalle Valo @ 2016-09-02 15:55 UTC (permalink / raw)
To: Daniel Wagner
Cc: Kalle Valo, netdev, linux-wireless, linux-kernel, ath10k,
Daniel Wagner, Luis R . Rodriguez, Christian Lamparter
In-Reply-To: <1471525926-20384-3-git-send-email-wagi@monom.org>
Daniel Wagner <wagi@monom.org> wrote:
> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>
> There is only one waiter for the completion, therefore there
> is no need to use complete_all(). Let's make that clear by
> using complete() instead of complete_all().
>
> The usage pattern of the completion is:
>
> waiter context waker context
>
> scan.started
> ------------
>
> ath10k_start_scan()
> lockdep_assert_held(conf_mutex)
> auth10k_wmi_start_scan()
> wait_for_completion_timeout(scan.started)
>
> ath10k_wmi_event_scan_start_failed()
> complete(scan.started)
>
> ath10k_wmi_event_scan_started()
> complete(scan.started)
>
> scan.completed
> --------------
>
> ath10k_scan_stop()
> lockdep_assert_held(conf_mutex)
> ath10k_wmi_stop_scan()
> wait_for_completion_timeout(scan.completed)
>
> __ath10k_scan_finish()
> complete(scan.completed)
>
> scan.on_channel
> ---------------
>
> ath10k_remain_on_channel()
> mutex_lock(conf_mutex)
> ath10k_start_scan()
> wait_for_completion_timeout(scan.on_channel)
>
> ath10k_wmi_event_scan_foreign_chan()
> complete(scan.on_channel)
>
> offchan_tx_completed
> --------------------
>
> ath10k_offchan_tx_work()
> mutex_lock(conf_mutex)
> reinit_completion(offchan_tx_completed)
> wait_for_completion_timeout(offchan_tx_completed)
>
> ath10k_report_offchain_tx()
> complete(offchan_tx_completed)
>
> install_key_done
> ----------------
> ath10k_install_key()
> lockep_assert_held(conf_mutex)
> reinit_completion(install_key_done)
> wait_for_completion_timeout(install_key_done)
>
> ath10k_htt_t2h_msg_handler()
> complete(install_key_done)
>
> vdev_setup_done
> ---------------
>
> ath10k_monitor_vdev_start()
> lockdep_assert_held(conf_mutex)
> reinit_completion(vdev_setup_done)
> ath10k_vdev_setup_sync()
> wait_for_completion_timeout(vdev_setup_done)
>
> ath10k_wmi_event_vdev_start_resp()
> complete(vdev_setup_done)
>
> ath10k_monitor_vdev_stop()
> lockdep_assert_held(conf_mutex)
> reinit_completion(vdev_setup_done()
> ath10k_vdev_setup_sync()
> wait_for_completion_timeout(vdev_setup_done)
>
> ath10k_wmi_event_vdev_stopped()
> complete(vdev_setup_done)
>
> thermal.wmi_sync
> ----------------
> ath10k_thermal_show_temp()
> mutex_lock(conf_mutex)
> reinit_completion(thermal.wmi_sync)
> wait_for_completion_timeout(thermal.wmi_sync)
>
> ath10k_thermal_event_temperature()
> complete(thermal.wmi_sync)
>
> bss_survey_done
> ---------------
> ath10k_mac_update_bss_chan_survey
> lockdep_assert_held(conf_mutex)
> reinit_completion(bss_survey_done)
> wait_for_completion_timeout(bss_survey_done)
>
> ath10k_wmi_event_pdev_bss_chan_info()
> complete(bss_survey_done)
>
> All complete() calls happen while the conf_mutex is taken. That means
> at max one waiter is possible.
>
> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Thanks, 1 patch applied to ath-next branch of ath.git:
881ed54ecc13 ath10k: use complete() instead complete_all()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9287731/
^ permalink raw reply
* Re: ath10k: fix sending frame in management path in push txq logic
From: Kalle Valo @ 2016-09-02 15:53 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: ath10k, Ashok Raj Nagarajan, arnagara, linux-wireless
In-Reply-To: <1471514404-24098-1-git-send-email-arnagara@qti.qualcomm.com>
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> wrote:
> In the wake tx queue path, we are not checking if the frame to be sent
> takes management path or not. For eg. QOS null func frame coming here will
> take the management path. Since we are not incrementing the descriptor
> counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is
> possible to see negative values.
>
> When the above counter reaches a negative value, we will not be sending a
> probe response out.
>
> if (is_presp &&
> ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx)
>
> For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against
> num_pending_mgmt_tx (int) and the above condtions comes true if the counter
> is negative and we drop the probe response.
>
> To avoid this, check on the wake tx queue path as well for the tx path of
> the frame and increment the appropriate counters
>
> Fixes: cac085524cf1 "ath10k: move mgmt descriptor limit handle under mgmt_tx"
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
e4fd726f21cd ath10k: fix sending frame in management path in push txq logic
--
Sent by pwcli
https://patchwork.kernel.org/patch/9287191/
^ permalink raw reply
* Re: ath10k: improve wake_tx_queue ops performance
From: Kalle Valo @ 2016-09-02 15:52 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160817153253.6615-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> txqs_lock is interfering with wake_tx_queue submitting more frames.
> so queues don't get filled in and don't keep firmware/hardware busy
> enough. This change helps to reduce the txqs_lock contention and
> wake_tx_queue() blockage to being possible in txrx_unref().
>
> To reduce turn around time of wake_tx_queue ops and to maintain fairness
> among all txqs, the callback is updated to push first txq alone from
> pending list for every wake_tx_queue call. Remaining txqs will be
> processed later upon tx completion.
>
> Below improvements are observed in push-only mode and validated on
> IPQ4019 platform. With this change, in AP mode ~10Mbps increase is
> observed in downlink (AP -> STA) traffic and approx. 5-10% of CPU
> usage is reduced.
>
> Major improvement is observed in 1-hop Mesh mode topology in 11ACVHT80.
> Compared to Infra mode, CPU overhead is higher in Mesh mode due to path
> lookup and no fast-xmit support. So reducing spin lock contention is
> helping in Mesh.
>
> TOT +change
> -------- --------
> TCP DL 545 Mbps 595 Mbps
> TCP UL 555 Mbps 585 Mbps
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
83e164b7679d ath10k: improve wake_tx_queue ops performance
--
Sent by pwcli
https://patchwork.kernel.org/patch/9286083/
^ 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