On Sat, 2016-01-30 at 12:23 +0530, Bhakti Priya wrote:
> I will be happy to extend checkpatch.pl. As suggested by you, I am
> trying to detect such blank lines in a line removal patch by checking
> if the line above the deleted line was a blank line and the line
> following the deleted line had a c
Hi,
Thank you for your reply. I've just sent version 2 of the patch with
the blank lines removed.
I will be happy to extend checkpatch.pl. As suggested by you, I am
trying to detect such blank lines in a line removal patch by checking
if the line above the deleted line was a blank line and the lin
This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
WARNING: void function return statements are not generally useful
Signed-off-by: Bhaktipriya Shridhar
---
Changes in v2:
- Removed the unnecessary blank lines.
drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 20 --
From: Kalle Valo
Date: Fri, 29 Jan 2016 10:47:19 +0200
> few fixes for 4.5. Nothing really standing out, see the tag for
> more info. Please let me know if you have any problems.
Pulled, thanks Kalle.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a
On Sat, 2016-01-30 at 14:09 +1100, Julian Calaby wrote:
> Hi Joe,
Hello Julian.
> On Sat, Jan 30, 2016 at 12:28 PM, Joe Perches
> wrote:
> > On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote:
> > > On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen > > t.com> wrote:
> > > > Bhaktipriya Shridhar
Hi Joe,
On Sat, Jan 30, 2016 at 12:28 PM, Joe Perches wrote:
> On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote:
>> On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen
>> wrote:
>> > Bhaktipriya Shridhar writes:
>> > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
>> > > WARNI
On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote:
> On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen wrote:
> > Bhaktipriya Shridhar writes:
> > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
> > > WARNING: void function return statements are not generally useful
[]
> > > dif
Hi Bhaktipriya,
On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen wrote:
> Bhaktipriya Shridhar writes:
>> This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
>> WARNING: void function return statements are not generally useful
>>
>> Signed-off-by: Bhaktipriya Shridhar
>> ---
>> drivers
Hi Cong
On Sat, Jan 30, 2016 at 6:46 AM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 11:24 -0800, Cong Wang wrote:
>> These two functions are called in sendmsg path, and the
>> 'len' is passed from user-space, so we should not allow
>> malicious users to OOM kernel on purpose.
>>
>> Reported-by:
On 01/27/16 17:09, André Vitor wrote:
> Hi all,
>
> I'm having trouble with driver r8xxxu. My device has a realtek usb wifi+bt
> combo (0bda:0724) built-in.
> I can connect to a wifi network but if I open something that uses
> connections the driver stops working with a mac80211 crash message.
>
On Fri, Jan 29, 2016 at 11:42 AM, Larry Finger
wrote:
>
> Thanks for testing.
>
> Upon reflection, it really should check the other WIRELESS_MODE_AC_x bits.
> Johannes' patch was indeed correct.
I just retested with this incremental (and whitespace-damaged) patch:
@@ -139,7 +139,9 @@ static vo
On Fri, Jan 29, 2016 at 05:11:04PM +0100, Xose Vazquez Perez wrote:
> >> I'm helping Greg do a bit of cleanup in the staging tree, I noticed that
> >> wlan-ng driver is maybe ready to be moved out of staging. Are there
> >> any TODO tasks left to do beside checkpatch.pl clean-up?
> >
> > Its FAQ w
On Fri, 2016-01-29 at 11:24 -0800, Cong Wang wrote:
> These two functions are called in sendmsg path, and the
> 'len' is passed from user-space, so we should not allow
> malicious users to OOM kernel on purpose.
>
> Reported-by: Dmitry Vyukov
> Cc: Lauro Ramos Venancio
> Cc: Aloisio Almeida Jr
On 01/29/2016 12:39 PM, Linus Torvalds wrote:
On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote:
The test patch that Johannes sent earlier was close. The section needed to
add VHT rates is:
Hmm. This looks pretty much exactly like what I already tried (I had
fixed Johannes' patch to use "v
llcp_sock_getname() checks llcp_sock->dev to make sure
llcp_sock is already connected or bound, however, we could
be in the middle of llcp_sock_bind() where llcp_sock->dev
is bound and llcp_sock->service_name_len is set,
but llcp_sock->service_name is not, in this case we would
lead to copy some by
These two functions are called in sendmsg path, and the
'len' is passed from user-space, so we should not allow
malicious users to OOM kernel on purpose.
Reported-by: Dmitry Vyukov
Cc: Lauro Ramos Venancio
Cc: Aloisio Almeida Jr
Cc: Samuel Ortiz
Signed-off-by: Cong Wang
---
net/nfc/llcp_comm
On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote:
>
> The test patch that Johannes sent earlier was close. The section needed to
> add VHT rates is:
Hmm. This looks pretty much exactly like what I already tried (I had
fixed Johannes' patch to use "vht_cap" already, since it didn't
compile othe
On Wed, Jan 27, 2016 at 1:05 PM, Eric Dumazet wrote:
> On Wed, 2016-01-27 at 11:50 -0800, Cong Wang wrote:
>
>> Hmm? I think nfc_llcp_send_ui_frame() needs to do some fragmention
>> with this temporary memory, or you are saying msg_iter has some
>> API available to seek the pointer? Even if so, it
Bhaktipriya Shridhar writes:
> This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
> WARNING: void function return statements are not generally useful
>
> Signed-off-by: Bhaktipriya Shridhar
> ---
> drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 10 --
> 1 file changed, 10 de
Linus,
Attached is a trial patch that fixes the problem on my system. As I told
Johannes earlier, my AP was not configured to use VHT, thus I did not see the
problem.
The test patch that Johannes sent earlier was close. The section needed to add
VHT rates is:
--- a/drivers/net/wireless/rea
This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
WARNING: void function return statements are not generally useful
Signed-off-by: Bhaktipriya Shridhar
---
drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/rt
On 2016-01-25 10:29:33, Herbert Xu wrote:
> On Sun, Jan 24, 2016 at 07:10:50PM +0100, Julia Lawall wrote:
> > Maybe the goto on line 1726 needs a preceding mutex_unlock?
>
> Good catch! Thanks.
>
> ---8<---
> This patch replaces uses of ablkcipher and blkcipher with skcipher,
> and the long obsol
On 01/29/2016 10:15 AM, Johannes Berg wrote:
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
Upon further inspection, my log has the line "rtl8821ae :02:00.0
wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
first.
Likely TKIP; enable only WPA2 (CCMP) on the AP.
I
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
>
> Upon further inspection, my log has the line "rtl8821ae :02:00.0
> wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
> first.
>
Likely TKIP; enable only WPA2 (CCMP) on the AP.
johannes
--
To unsubscribe from this list
On Fri, Jan 29, 2016 at 05:00:16PM +0100, Xose Vazquez Perez wrote:
> Ksenija wrote:
>
> > I'm helping Greg do a bit of cleanup in the staging tree, I noticed that
> > wlan-ng driver is maybe ready to be moved out of staging. Are there
> > any TODO tasks left to do beside checkpatch.pl clean-up?
>
On 01/29/2016 05:00 PM, Xose Vazquez Perez wrote:
> Ksenija wrote:
>
>> I'm helping Greg do a bit of cleanup in the staging tree, I noticed that
>> wlan-ng driver is maybe ready to be moved out of staging. Are there
>> any TODO tasks left to do beside checkpatch.pl clean-up?
>
> Its FAQ was very
Ksenija wrote:
> I'm helping Greg do a bit of cleanup in the staging tree, I noticed that
> wlan-ng driver is maybe ready to be moved out of staging. Are there
> any TODO tasks left to do beside checkpatch.pl clean-up?
Its FAQ was very clear: ftp://ftp.linux-wlan.org/pub/linux-wlan-ng/FAQ
[archiv
It should be called up(&mq->sem) to release semaphore before returning
error codes as -EFAULT when list is empty.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_msgqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c
b/drivers/stagi
This patch uses standard struct list_head in struct message and
message_queue instead of custom linked list.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_msgqueue.c | 32
drivers/staging/wilc1000/wilc_msgqueue.h | 5 +++--
2 files changed, 15 in
Hi Dear,
I am Mrs Machiko Kumiko, from Japan, I Have Been Diagnosed with esophageal
Cancer.
I Have Chosen you to distribute my Funds to Charities homes in your Country,
so if you wish to Carry out this humanitarian Work kindly Get back to me for
FURTHER details.
Yours Truely Mrs Machiko Kum
On 2016-01-29 09:35, Konstantin Khlebnikov wrote:
> Patch fixes this splat
>
> BUG: KASAN: slab-out-of-bounds in minstrel_ht_update_stats.isra.7+0x6e1/0x9e0
> [mac80211] at addr 8800cee640f4 Read of size 4 by task swapper/3/0
>
> Signed-off-by: Konstantin Khlebnikov
> Link:
> http://lkml.ke
Hi Henning,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Henning-Rogge/mac80211-add
Some of the parameter like tx/rx chain mask, number of htt tx desc,
qcache active peer count, etc goes via wmi init cmd to qca4019 firmware
are different.
To make use of 10.4 gen_init function for qca4019, change wmi service
ready handler and 10.4 wmi init functions to adapt qca4019 specific
init
This patch series includes hw param and wmi changes needed for qca4019.
Raja Mani (2):
ath10k: add qca4019 hw params
ath10k: populate qca4019 fw specific wmi init params
drivers/net/wireless/ath/ath10k/core.c | 34 +++--
drivers/net/wireless/ath/ath10k/core.h
From: Raja Mani
Add a new entry in hw_params_list for qca4019 with list of
it's own details.
Signed-off-by: Raja Mani
---
drivers/net/wireless/ath/ath10k/core.c | 20
drivers/net/wireless/ath/ath10k/hw.h| 8
drivers/net/wireless/ath/ath10k/targaddrs.
Make the mesh_path_del() function remove all mpp table entries
that are proxied by the removed mesh path.
Signed-off-by: Henning Rogge
---
net/mac80211/mesh_pathtbl.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_p
Currently MPP table entries are only removed from memory when their
802.11s mesh interface goes down. This can make the kernel to remember
a growing list of proxied mac addresses which are not relevant or even
reachable anymore.
This patchset adds two additional cleanup paths for MPP table entries
mpp_path_del() and mesh_path_del() are mostly the same function.
Move common code into a new static function.
Signed-off-by: Henning Rogge
---
net/mac80211/mesh_pathtbl.c | 110 ++--
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/net/mac80
Remember the last time when a mpp table entry is used for
rx or tx and remove them after MESH_PATH_EXPIRE time.
Signed-off-by: Henning Rogge
---
net/mac80211/mesh_pathtbl.c | 54 +
net/mac80211/rx.c | 1 +
net/mac80211/tx.c | 6 ++
On error we jumped to the error label and returned the error code but we
missed releasing sinfo.
Signed-off-by: Sudip Mukherjee
---
net/mac80211/sta_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6c198e6..36e75c4 100644
--- a/ne
> From: Xinming Hu
>
> This patch add sched scan support for mwifiex, include cfg80211
> sched_scan_start/sched_scan_stop handler, corresponding bgscan
> command path and event handler.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: chunfan chen
> Signed-off-by: Cathy Luo
> Signed-off-by: Am
> From: Shengzhen Li
>
> It's been observed that driver's power state goes out
> of sync with firmware in some corner cases. When this
> happens, driver tries to download the data to firmware
> assuming it's awake which causes Tx data timeout.
>
> Main thread will process interrupt as soon as i
> From: Xinming Hu
>
> Newer pcie chipsets (8997 onwards) support MSIx. This
> patch enables it.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wirele
> wlcore_read/wlcore_write can return negative values so it should
> be assigned to signed variable.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2120705
>
>
> From: chunfan chen
>
> Same chip is being used by WLAN as well as bluetooth
> drivers. Each driver needs to check during initialisation
> if firmware is already active or it needs to be freshly
> downloaded. If one driver has started downloading the
> firmware, other finds the winner flag as f
> The power function uses a consumer regulator access to update the WiFi
> enable GPIO value.
>
> Signed-off-by: Uri Mashiach
> Tested-By: Sebastian Reichel
> Reviewed-by: Grygorii Strashko
> Acked-by: Igor Grinberg
Thanks, 2 patches applied to wireless-drivers-next.git:
4c1ce07bcf62 wlcore
Joe Qiao writes:
> Now I setup AP and want to find a way to kick off a special wifi user
> from the AP. I know “iw dev station del”, but it seems it only remove
> the station data from driver inside, but cannot trigger a
> disassociation frame wireless client. Would you please give some
> guidanc
Hi Dave,
few fixes for 4.5. Nothing really standing out, see the tag for
more info. Please let me know if you have any problems.
Kalle
The following changes since commit a200dcb34693084e56496960d855afdeaaf9578f:
Merge tag 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Patch fixes this splat
BUG: KASAN: slab-out-of-bounds in minstrel_ht_update_stats.isra.7+0x6e1/0x9e0
[mac80211] at addr 8800cee640f4 Read of size 4 by task swapper/3/0
Signed-off-by: Konstantin Khlebnikov
Link:
http://lkml.kernel.org/r/calygninyjhsavne35qs6ucgasb2dx1_i5hcravuox14otz2...@mai
On Thu, 2016-01-28 at 19:54 -0600, Larry Finger wrote:
>
> I have been running an RTL8821AE since kernel 3.18 without hitting
> this problem
> using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the
> driver is not expecting.
Are you quite sure you're actually using VH
Sudip Mukherjee writes:
>> >> That's also my experience from maintaining wireless-drivers for a year,
>> >> this seems to be a "hit and run" type of phenomenon.
>> >
>> > Should we be looking for someone to run a "wireless-driver-cleanups"
>> > tree? They could handle the cleanups and trivial st
51 matches
Mail list logo