* Re: [2/2,v2] wlcore: Remove wl pointer from wl_sta structure
From: Kalle Valo @ 2016-09-03 16:56 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 commit
> 4fdbc67a25ce ("mac80211: call get_expected_throughput only after adding
> station") as hw is now sent as a parameter.
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
d8c872b57e0f wlcore: Remove wl pointer from wl_sta structure
--
Sent by pwcli
https://patchwork.kernel.org/patch/9280419/
^ permalink raw reply
* Re: rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
From: Kalle Valo @ 2016-09-03 16:52 UTC (permalink / raw)
To: Christian Engelmayer
Cc: Larry.Finger, chaoming_li, arnd, linux-wireless,
Christian Engelmayer
In-Reply-To: <1470770397-24390-1-git-send-email-cengelma@gmx.at>
Christian Engelmayer <cengelma@gmx.at> wrote:
> In case rtl_get_hwinfo() fails, the function directly returns and leaks the
> already allocated hwinfo memory. Go through the correct exit path.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks, 1 patch applied to wireless-drivers-next.git:
a0c7858e7479 rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9272131/
^ permalink raw reply
* [PATCH] rtl8xxxu: fix spelling mistake "firmare" -> "firmware"
From: Colin King @ 2016-09-03 16:43 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistakes in dev_dbg message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 77048db..9cb1efa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3947,11 +3947,11 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, priv->fops->trxff_boundary);
ret = rtl8xxxu_download_firmware(priv);
- dev_dbg(dev, "%s: download_fiwmare %i\n", __func__, ret);
+ dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
if (ret)
goto exit;
ret = rtl8xxxu_start_firmware(priv);
- dev_dbg(dev, "%s: start_fiwmare %i\n", __func__, ret);
+ dev_dbg(dev, "%s: start_firmware %i\n", __func__, ret);
if (ret)
goto exit;
--
2.9.3
^ permalink raw reply related
* [PATCH][V2] ath10k: fix memory leak on caldata on error exit path
From: Colin King @ 2016-09-03 16:38 UTC (permalink / raw)
To: Kalle Valo, ath10k, linux-wireless, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
caldata is not being free'd on the error exit path, causing
a memory leak and data definitely should not be freed. Free
caldata instead of data.
Thanks to Kalle Valo for spotting that data should not be
free'd.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 9a22c47..afdf0fa 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2725,7 +2725,7 @@ static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k *ar, void **data,
return 0;
err_free:
- kfree(data);
+ kfree(caldata);
return -EINVAL;
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] ath10k: fix memory leak on caldata on error exit path
From: Colin Ian King @ 2016-09-03 16:33 UTC (permalink / raw)
To: Valo, Kalle
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <87r392z4ox.fsf@kamboji.qca.qualcomm.com>
On 02/09/16 16:45, Valo, Kalle wrote:
> Colin King <colin.king@canonical.com> writes:
>
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> caldata is not being free'd on the error exit path, causing
>> a memory leak. kfree it to fix the leak.
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>> drivers/net/wireless/ath/ath10k/pci.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
>> index 9a22c47..886337c 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2725,6 +2725,7 @@ static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k *ar, void **data,
>> return 0;
>>
>> err_free:
>> + kfree(caldata);
>> kfree(data);
>>
>> return -EINVAL;
>
> I don't think we should free data at all:
>
> static int ath10k_download_cal_eeprom(struct ath10k *ar)
> {
> size_t data_len;
> void *data = NULL;
> int ret;
>
> ret = ath10k_hif_fetch_cal_eeprom(ar, &data, &data_len);
>
> Instead we should free only caldata, right?
>
Yep, good catch, I'll send V2 later.
Colin
^ permalink raw reply
* Re: [PATCH] ath9k: bring back direction setting in ath9k_{start_stop}
From: Giedrius Statkevičius @ 2016-09-03 16:08 UTC (permalink / raw)
To: kvalo
Cc: ath9k-devel, linux-wireless, ath9k-devel, netdev, linux-kernel,
Miaoqing Pan, Kalle Valo, stable
In-Reply-To: <20160901174702.8645-1-giedrius.statkevicius@gmail.com>
Some more users complaining about this:
https://bbs.archlinux.org/viewtopic.php?id=215978
On Thu, Sep 01, 2016 at 08:47:02PM +0300, Giedrius Statkevičius wrote:
> A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup
> led_pin initial") that broken the WLAN status led on my laptop with
> AR9287 after suspending and resuming.
>
> Steps to reproduce:
> * Suspend (laptop)
> * Resume (laptop)
> * Observe that the WLAN led no longer turns ON/OFF depending on the
> status and is always red
>
> Even though for my case it only needs to be set to OUT in ath9k_start
> but for consistency bring back the IN direction setting as well.
>
> Cc: Miaoqing Pan <miaoqing@codeaurora.org>
> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
> ---
[...]
^ permalink raw reply
* Re: mwifiex: add PCIe function level reset support
From: Kalle Valo @ 2016-09-03 15:40 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Amitkumar Karwar
In-Reply-To: <1469541704-2880-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> This patch implements pre and post FLR handlers to support PCIe FLR
> functionality. Software cleanup is performed in pre-FLR whereas
> firmware is downloaded and software is re-initialised in
> post-FLR handler.
>
> Following command triggers FLR.
> echo "1" > /sys/bus/pci/devices/$NUMBER/reset
>
> This feature can be used as a recovery mechanism when firmware gets
> hang.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Doesn't apply anymore, please rebase.
Applying: mwifiex: add PCIe function level reset support
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/main.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: add PCIe function level reset support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9248233/
^ permalink raw reply
* Re: [v2] ErrHandling:Make IS_ERR_VALUE_U32 as generic API to avoid IS_ERR_VALUE abuses.
From: Kalle Valo @ 2016-09-03 14:29 UTC (permalink / raw)
To: Arvind Yadav
Cc: zajec5, viresh.kumar, akpm, linux-wireless, linux-kernel,
linville, Arvind Yadav
In-Reply-To: <1468083696-15283-1-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> It can not be used to check if an 'unsigned int' reflects an error.
> As they pass an 'unsigned int' into a function that takes an
> 'unsigned long' argument. This happens to work because the type
> is sign-extended on 64-bit architectures before it gets converted
> into an unsigned type.
>
> However, anything that passes an 'unsigned short' or 'unsigned int'
> argument into IS_ERR_VALUE() is guaranteed to be broken, as are
> 8-bit integers and types that are wider than 'unsigned long'.
>
> It would be nice to any users that are not passing 'unsigned int'
> arguments.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
This touches include/linux/err.h and I'm not very enthusiastic to change
anything in include directory without wider support. I recommend first to just
fix bcma. And separately you can try to improve linux/err.h via some more
approariate tree, not via wireless trees.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9222139/
^ permalink raw reply
* Re: [FIX?] brcmfmac: fix possible overflows in flowrings code by bumping u8 to u16
From: Kalle Valo @ 2016-09-03 14:06 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, Brett Rudley, Arend van Spriel,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <1454198830-13971-1-git-send-email-zajec5@gmail.com>
Rafał Miłecki wrote:
> Some devices may use more than 255 flowings, below is log from BCM4366:
> [ 194.606245] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 264
>
> At various places we were using u8 which could lead to storing wrong
> number or infinite loops when indexing incorrectly. Initially this
> issue was spotted as infinite loop in brcmf_flowring_detach.
>
> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
There has been no activity on this patch so I'll drop this. Please resend if
this is still needed.
--
Sent by pwcli
https://patchwork.kernel.org/patch/8172531/
^ permalink raw reply
* 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
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