* Re: [v2] bcma: use of_dma_configure() to set initial dma mask
From: Kalle Valo @ 2016-09-03 14:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafał Miłecki, Arnd Bergmann, Hauke Mehrtens,
linux-wireless, linux-kernel
In-Reply-To: <1458207563-3453369-1-git-send-email-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> While fixing another bug, I noticed that bcma manually sets up
> a dma_mask pointer for its child devices. We have a generic
> helper for that now, which should be able to cope better with
> any variations that might be needed to deal with cache coherency,
> unusual DMA address offsets, iommus, or limited DMA masks, none
> of which are currently handled here.
>
> This changes the core to use the of_dma_configure(), like
> we do for platform devices that are probed directly from
> DT.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Nobody tested this, so I'll drop the patch.
--
Sent by pwcli
https://patchwork.kernel.org/patch/8608751/
^ permalink raw reply
* Re: fix:rtl8xxxu_core: mark symbols static where possible
From: Jes Sorensen @ 2016-09-03 12:31 UTC (permalink / raw)
To: Kalle Valo
Cc: Baoyou Xie, linux-wireless, netdev, linux-kernel, arnd,
xie.baoyou
In-Reply-To: <20160903102822.84E496201B@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Baoyou Xie <baoyou.xie@linaro.org> wrote:
>> We get 1 warning about global functions without a declaration
>> in the rtl8xxxu rtl8xxxu_core.c when building with W=1:
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1:
>> warning: no previous prototype for 'rtl8xxxu_gen1_h2c_cmd'
>> [-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>
>
> The title should be "rtl8xxxu: ". See:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
>
> Also I assume Jes will take this.
Yes to both accounts!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCHv8 0/4] register-field manipulation macros
From: Kalle Valo @ 2016-09-03 11:05 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Linux Wireless List, linux-kernel
In-Reply-To: <1472644007-20959-1-git-send-email-jakub.kicinski@netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> Small improvement suggested by Daniel Borkmann - use
> two underscore prefix.
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg125423.html
>
> -- v6 blurb:
>
> This set moves to a global header file macros which I find
> very useful and worth popularising. The basic problem is
> that since C bitfields are not very dependable accessing
> subfields of registers becomes slightly inconvenient.
> It is nice to have the necessary mask and shift operations
> wrapped in a macro and have that macro compute shift
> at compilation time using FFS.
>
> My implementation follows what Felix Fietkau has done in
> mt76. Hannes Frederic Sowa suggested more use of standard
> Linux/GCC functions. Since the RFC I've also added a
> compile-time check to validate that the value passed to
> setters fits in the mask.
>
> I attempted the use of static inlines instead of macros
> but it makes GCC < 6.0 barf at the BUILD_BUG_ON()s.
> I also noticed that forcing arguments to be u32 for inlines
> makes the compiler use 32bit arithmetic where it could
> get away with 64bit before (on 64bit machines, obviously).
> That's a potential performance concern but probably not
> a very practical one today. Apart from looking "cleaner"
> static inlines would have the advantage that we could #undef
> the auxiliary macros at the end of the header.
>
> Build bot caught a build failure with -Os set. AFAICT gcc
> did not handle temporary variable I put in the macro
> expression too well. I work around that by defining
> __BUILD_BUG_ON_NOT_POWER_OF_2 and using it instead of
> BUILD_BUG_ON(!tmp || is_power_of_2(tmp)).
>
> I'm planning to use those macros in another driver soon,
> Felix may also use them when upstreaming mt76 if he chooses
> to do so.
>
> IMHO if accepted it would be best to push these through
> Kalle's wireless drivers' tree, since the only existing
> user is in drivers/net/wireless/.
>
> v8:
> - use two underscores for auxiliary macros (Daniel B).
> v7:
> - drop the explicit type marking (u32/u64) - depend on the type
> of the mask instead;
> - only allow compilation time constant masks;
> - barf at "type of register too small to ever match mask" on get;
> - rename PUT -> PREP.
> v6:
> - do a full rename in patch 2;
> - CC many people.
> v5:
> - repost.
> v4:
> - add documentation in the header.
> v3:
> - don't use variables in statement expressions;
> - use __BUILD_BUG_ON_NOT_POWER_OF_2.
> v2:
> - change Felix's email address.
>
> Jakub Kicinski (4):
> add basic register-field manipulation macros
> mt7601u: remove redefinition of GENMASK
> mt7601u: remove unnecessary include
> mt7601u: use linux/bitfield.h
I applied these now to the pending branch of my wireless-drivers-next
tree. Let's see if the kbuild bot finds any problems.
Please also CC lkml, did that now.
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Kalle Valo @ 2016-09-03 10:35 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Javier Martinez Canillas, Amitkumar Karwar, netdev,
linux-wireless, Nishant Sarmukadam
In-Reply-To: <1471529868-13669-1-git-send-email-javier@osg.samsung.com>
Javier Martinez Canillas <javier@osg.samsung.com> wrote:
> If request_irq() fails in mwifiex_sdio_probe_of(), only an error message
> is printed but the actual error is not propagated to the caller function.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
What's the conclusion with this patch? Should I drop it or take it?
(The discussion is available from the patchwork link in the signature.)
--
Sent by pwcli
https://patchwork.kernel.org/patch/9288169/
^ permalink raw reply
* Re: fix:rtl8xxxu_core: mark symbols static where possible
From: Kalle Valo @ 2016-09-03 10:28 UTC (permalink / raw)
To: Baoyou Xie
Cc: Jes.Sorensen, linux-wireless, netdev, linux-kernel, arnd,
baoyou.xie, xie.baoyou
In-Reply-To: <1472314476-23351-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 rtl8xxxu rtl8xxxu_core.c when building with W=1:
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1: warning: no previous prototype for 'rtl8xxxu_gen1_h2c_cmd' [-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>
The title should be "rtl8xxxu: ". See:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
Also I assume Jes will take this.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9302457/
^ permalink raw reply
* Re: [2/2,v2] wlcore: Remove wl pointer from wl_sta structure
From: Kalle Valo @ 2016-09-03 10:24 UTC (permalink / raw)
To: Maxim Altshul; +Cc: linux-kernel, Maxim Altshul, linux-wireless
In-Reply-To: <20160815082400.12053-1-maxim.altshul@ti.com>
Maxim Altshul <maxim.altshul@ti.com> wrote:
> This field was added to wl_sta struct to get hw in situations
> where it was not given to driver by mac80211.
>
> In our case, get_expected_throughput op did not send hw to driver.
>
> This patch reverts the change, as it is no longer needed due to
> get_expected_throughput op change (hw is now sent as a parameter)
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
I'll change the end of commit log to:
This patch reverts the change, as it is no longer needed due to commit
4fdbc67a25ce ("mac80211: call get_expected_throughput only after adding
station") as hw is now sent as a parameter.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9280419/
^ permalink raw reply
* Re: [PATCH v5] ath9k: Switch to using mac80211 intermediate software queues.
From: Felix Fietkau @ 2016-09-03 10:16 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
Cc: Tim Shepard
In-Reply-To: <20160902140030.11798-1-toke@toke.dk>
On 2016-09-02 16:00, Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
>
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
>
> Based on Tim's original patch set, but reworked quite thoroughly.
>
> Cc: Tim Shepard <shep@alum.mit.edu>
> Cc: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
You can add:
Signed-off-by: Felix Fietkau <nbd@nbd.name>
- Felix
^ permalink raw reply
* Re: [1/1] mwifiex: key_material_v2 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: <1469967081-3937-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> We are using mac as source address in a memcpy.
> In the lines below we can assume mac 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:
b0d80f19c14f mwifiex: key_material_v2 remove superfluous condition
--
Sent by pwcli
https://patchwork.kernel.org/patch/9253367/
^ permalink raw reply
* Re: [v4] brcmfmac: add missing header dependencies
From: Kalle Valo @ 2016-09-03 10:10 UTC (permalink / raw)
To: Baoyou Xie
Cc: arend.vanspriel, franky.lin, hante.meuleman, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel, arnd, baoyou.xie,
xie.baoyou
In-Reply-To: <1472474375-29910-1-git-send-email-baoyou.xie@linaro.org>
Baoyou Xie <baoyou.xie@linaro.org> wrote:
> We get 1 warning when building kernel with W=1:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning: no previous prototype for '__brcmf_err' [-Wmissing-prototypes]
>
> In fact, this function is declared in brcmfmac/debug.h, so this patch
> adds missing header dependencies.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks, 1 patch applied to wireless-drivers-next.git:
8af92af3f2d5 brcmfmac: add missing header dependencies
--
Sent by pwcli
https://patchwork.kernel.org/patch/9303939/
^ permalink raw reply
* Re: mwifiex: fix missing break on IEEE80211_STYPE_ACTION case
From: Kalle Valo @ 2016-09-03 10:08 UTC (permalink / raw)
To: Colin Ian King
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1471349413-21893-1-git-send-email-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The IEEE80211_STYPE_ACTION case is missing a break in the switch
> statement, causing it to fall through to the default case that
> reports a debug message about an unknown frame subtype. Fix this
> by adding in the missing break statement.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
d393be3ed0be mwifiex: fix missing break on IEEE80211_STYPE_ACTION case
--
Sent by pwcli
https://patchwork.kernel.org/patch/9283755/
^ permalink raw reply
* Re: rt2x00usb: Fix error return code
From: Kalle Valo @ 2016-09-03 10:07 UTC (permalink / raw)
To: Christophe Jaillet
Cc: sgruszka, helmut.schaa, linux-wireless, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <1470926334-24532-1-git-send-email-christophe.jaillet@wanadoo.fr>
Christophe Jaillet <christophe.jaillet@wanadoo.fr> wrote:
> We know that 'retval = 0' because it has been tested a few lines above.
> So, if 'devm_kmalloc' fails, 0 will be returned instead of an error code.
> Return -ENOMEM instead.
>
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
410280bac622 rt2x00usb: Fix error return code
--
Sent by pwcli
https://patchwork.kernel.org/patch/9275379/
^ permalink raw reply
* Re: [1/3] mwifiex: correct aid value during tdls setup
From: Kalle Valo @ 2016-09-03 10:06 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1470754246-635-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> AID gets updated during TDLS setup, but modified value isn't reflected
> in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is
> fixed here.
>
> Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 3 patches applied to wireless-drivers-next.git:
b64db1b252e9 mwifiex: correct aid value during tdls setup
41960b4dfdfc mwifiex: add CHAN_REGION_CFG command
72539799104d mwifiex: add custom regulatory domain support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9271429/
^ permalink raw reply
* Re: [1/2] mwifiex: fix the length parameter of a memset
From: Kalle Valo @ 2016-09-03 10:04 UTC (permalink / raw)
To: Christophe Jaillet
Cc: akarwar, nishants, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <1470641928-26616-1-git-send-email-christophe.jaillet@wanadoo.fr>
Christophe Jaillet <christophe.jaillet@wanadoo.fr> wrote:
> In 'mwifiex_get_ver_ext', we have:
> struct mwifiex_ver_ext ver_ext;
>
> memset(&ver_ext, 0, sizeof(struct host_cmd_ds_version_ext));
>
> This is likely that memset'ing sizeof(struct mwifiex_ver_ext) was expected.
> Remove the ambiguity by using the variable name directly instead of its
> type.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks, 2 patches applied to wireless-drivers-next.git:
ba852018d493 mwifiex: fix the length parameter of a memset
6a1622000ac9 mwifiex: simplify length computation for some memset
--
Sent by pwcli
https://patchwork.kernel.org/patch/9266889/
^ permalink raw reply
* Re: wl3501_cs: Add spinlock to wl3501_reset
From: Kalle Valo @ 2016-09-03 10:01 UTC (permalink / raw)
To: Pavel Andrianov
Cc: Arnaldo Carvalho de Melo, Pavel Andrianov, linux-wireless, netdev,
linux-kernel, ldv-project, vaishali.thakkar
In-Reply-To: <1470130913-5218-1-git-send-email-andrianov@ispras.ru>
Pavel Andrianov <andrianov@ispras.ru> wrote:
> Likely wl3501_reset should acquire spinlock as wl3501_{open, close}.
> One of calls of wl3501_reset has been already protected.
> The others were unprotected and might lead to a race condition.
> The patch adds spinlock into the wl3501_reset and removes it from
> wl3501_tx_timeout.
>
> Found by Linux Driver Verification project (linuxtesting.org)
>
> Signed-off-by: Pavel Andrianov <andrianov@ispras.ru>
> Acked-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
bd6b0242652a wl3501_cs: Add spinlock to wl3501_reset
--
Sent by pwcli
https://patchwork.kernel.org/patch/9255415/
^ permalink raw reply
* Re: [1/1,v2] rtlwifi: remove superfluous condition
From: Kalle Valo @ 2016-09-03 10:03 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel,
Heinrich Schuchardt
In-Reply-To: <1470165981-6241-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> If sta == NULL, the changed line will not be reached.
> So no need to check that sta != NULL here.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks, 1 patch applied to wireless-drivers-next.git:
f898005ff99f rtlwifi: remove superfluous condition
--
Sent by pwcli
https://patchwork.kernel.org/patch/9260253/
^ permalink raw reply
* 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
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