>
> Where's the patch?
>
You can see it on mac80211-next.
Commit 4fdbc67a25ce577b79b3af595e874e9ef921329f
Max
>
> Email: julian.cal...@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Mon, Aug 8, 2016 at 5:39 PM, Christophe JAILLET
wrote:
> This patch should be a no-op. It just simplifies code by using the name of
> a variable instead of its type when calling 'sizeof'.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
E
Hi Maxim,
On Thu, Aug 11, 2016 at 8:38 PM, Maxim Altshul wrote:
> The patch is done with respect to the patch that was applied:
> [PATCH v3] mac80211: mesh: Add support for HW RC implementation
>
> 1. Patch adds protection as we discussed
> 2. Patch changes the function call that is made in the m
Hi All,
On Tue, Aug 30, 2016 at 3:05 AM, Joe Perches wrote:
> Correct some trivial comment typos.
> Remove unnecessary parentheses in a long line.
> Convert a return; before the end of a void function definition to just ;
>
> Signed-off-by: Joe Perches
This all looks correct to me. I wish you'd
Hi All,
On Sun, Aug 28, 2016 at 9:28 PM, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/prof
Hi All,
On Sun, Sep 4, 2016 at 2:43 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistakes in dev_dbg message.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/pro
Bjorn Andersson wrote:
> Some firmware versions sends a "print register indication", handle this
> by printing out the content.
>
> Cc: Nicolas Dechesne
> Signed-off-by: Bjorn Andersson
This doesn't apply anymore, please rebase.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9208737/
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
Oleg Drokin wrote:
> %ul was likely meant as %lu to print an unsigned long,
> not an unsigned with a letter l at the end.
> But in fact the value printed is u32 anyway, so just drop
> the l completely.
>
> Signed-off-by: Oleg Drokin
> Acked-by: Larry Finger
Thanks, 1 patch applied to wireless-
Stanislaw Gruszka wrote:
> Printing ret and adapter->winner do not provide any useful information
> as those are always 0 at point where the massage is printed. Print value
> read from reg->fw_status register instead.
>
> Stanislaw Gruszka
Thanks, 3 patches applied to wireless-drivers-next.git:
Guy Mishol wrote:
> Add time sync configuration api.
> The new api allows to configure the synchronization
> mode (STA/AP/MESH) and (in case of Mesh mode) the
> master address of each zone.
>
> Signed-off-by: Guy Mishol
Thanks, 1 patch applied to wireless-drivers-next.git:
c5aa9541818a wl18xx:
Nicolas Iooss wrote:
> The struct cfg80211_pmksa defines its bssid field as:
>
> const u8 *bssid;
>
> contrary to struct brcmf_pmksa, which uses:
>
> u8 bssid[ETH_ALEN];
>
> Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
> of this field (of type u8**), not the
Ismael Luceno wrote:
> The AE1200 comes with different revisions of the BCM43235 chipset,
> but all have the same USB ID. Only revision 3 can be supported.
>
> Signed-off-by: Ismael Luceno
Thanks, 1 patch applied to wireless-drivers-next.git:
bccf3ffc8c6d brcmfmac: Add USB ID for Cisco Linksys
Christian Engelmayer wrote:
> In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
> returns and leaks the already allocated hwinfo memory. Go through the
> correct exit path.
>
> Signed-off-by: Christian Engelmayer
> Acked-by: Larry Finger
Thanks, 1 patch applied to wireless-d
Larry Finger wrote:
> Some RTL8821AE devices sold in Great Britain have the country code of
> 0x25 encoded in their EEPROM. This value is not tested in the routine
> that establishes the regulatory info for the chip. The fix is to set
> this code to have the same capabilities as the EU countries.
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err message.
>
> Signed-off-by: Colin Ian King
> Reviewed-by: Julian Calaby
Thanks, 1 patch applied to wireless-drivers-next.git:
b46b599328e6 zd1211rw: fix spelling mistake "firmeware" -> "firmware"
--
Jes Sorensen wrote:
> From: Jes Sorensen
>
> Successfully tested by Jocelyn Mayer
>
> Reported-by: J. Mayer
> Signed-off-by: Jes Sorensen
Thanks, 20 patches applied to wireless-drivers-next.git:
b81669b9e0b4 rtl8xxxu: Mark 0x20f4:0x648b as tested
76a8e07d49b6 rtl8xxxu: Mark 0x2001:0x3308 as
Maxim Altshul 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 ("mac
Christian Engelmayer 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
> Acked-by: Larry Finger
Thanks, 1 patch applied to wireless-drivers-next.git:
From: Colin Ian King
Trivial fix to spelling mistakes in dev_dbg message.
Signed-off-by: Colin Ian King
---
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/dri
From: Colin Ian King
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
---
drivers/net/wireless/ath/at
On 02/09/16 16:45, Valo, Kalle wrote:
> Colin King writes:
>
>> From: Colin Ian King
>>
>> 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
>> ---
>> drivers/net/wireless/ath/ath10k/pci.c | 1 +
>> 1 fil
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
Amitkumar Karwar 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/
Arvind Yadav 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-exte
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
Arnd Bergmann 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 addr
Kalle Valo writes:
> Baoyou Xie 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'
>> [-Wmi
Jakub Kicinski 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
Javier Martinez Canillas 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
What's the conclusion with this patch? Should I drop it or take it?
Baoyou Xie 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 fa
Maxim Altshul 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_throughpu
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 re
Heinrich Schuchardt 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
> Acked-by: Amitkumar Karwar
Thanks, 1 patch applied to wireless-drivers-next.git:
b0d80f19c14f mwifiex: key_material_v2 remo
Baoyou Xie 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
Colin Ian King wrote:
> From: Colin Ian King
>
> 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.
>
> S
Christophe Jaillet 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
Amitkumar Karwar wrote:
> From: Xinming Hu
>
> 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: Xi
Christophe Jaillet 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 nam
Heinrich Schuchardt 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
> Acked-by: Larry Finger
Thanks, 1 patch applied to wireless-drivers-next.git:
f898005ff99f rtlwifi: remove superfluous condit
Pavel Andrianov 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_t
Heinrich Schuchardt wrote:
> for_each_property_of_node is only executed if the
> property prop is not NULL.
>
> Signed-off-by: Heinrich Schuchardt
> Acked-by: Amitkumar Karwar
Thanks, 1 patch applied to wireless-drivers-next.git:
2f69e67058fb mwifiex: remove superfluous condition
--
Sent by
Sergey Ryazanov wrote:
> EEPROM size calculated in 16-bit words, so we should take into account
> this fact during buffer allocation.
>
> CC: Jiri Slaby
> CC: Nick Kossifidis
> CC: Luis R. Rodriguez
> Signed-off-by: Sergey Ryazanov
Thanks, 1 patch applied to wireless-drivers-next.git:
af8a9
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 totall
Amitkumar Karwar wrote:
> From: Karthik D A
>
> 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
> Signed-off-by: Amitkumar Karw
Rajan Vaja 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
Wei Yongjun 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
Thanks, 1 patch applied to wireless-drivers-next.git:
4ad0579a28c0 wlcore: spi: fix n
47 matches
Mail list logo
