[PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

The two members min_scan_time and max_scan_time of structure "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values are assigned directtly from firmware without endian conversion handling. So, wrong datas will get saved in big-endian systems. This patch converts the values into

[PATCH v2] rtlwifi: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited range of data type [-Werror=type-limits]

Re: [PATCH] rtlwifi: use s8 instead of char

On Wednesday, June 15, 2016 5:10:51 PM CEST Jes Sorensen wrote: > > Arnd, > > rtlwifi and rtl8xxxu are two distinct drivers managed by different > people. I'd be really nice if you could split this into a per driver > patch. > > That said, the use of char in rtl8xxxu is all as a flag indicator,

Re: [PATCH] rtlwifi: use s8 instead of char

Arnd Bergmann writes: > Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of > incorrect code that results from 'char' being unsigned here, e.g. > > realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited > range of data type

[PATCH] rtlwifi: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited range of data type [-Werror=type-limits]

[PATCH] nl80211: improve nl80211_parse_mesh_config type checking

When building a kernel with W=1, the nl80211.c file causes a number of warnings, all about the same problem: net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config': net/wireless/nl80211.c:5287:103: error: comparison is always false due to limited range of data type [-Werror=type-limits]

[PATCH] mac80211: ensure info->control.vif is set for queued pkts.

From: Ben Greear When driving ath10k with a modified pktgen, we see excessive amounts of these warnings: Jun 6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at /home/greearb/git/linux-4.4.dev.y/net/mac80211/tx.c:3 125 ieee80211_tx_pending+0x9d/0x19e

Re: mac80211 splat with pktgen on hacked 4.4 kernel.

On 06/15/2016 10:38 AM, Ben Greear wrote: On 4.4.11 + local hacks, including fairly extensive pktgen changes When I overdrive transmit on a station with pktgen, I see this splat hit below repeatedly. Any ideas on what kinds of things might cause this? while

Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

I'm not sure what to tell you. Did you look into the GTK installation failure? For WPA-PSK, there's 1 4-way handshake and the STA installs 1 PTK and 1 GTK. For WPA2-PSK for IBSS, there are 2 4-way handshakes and the STA installs 1 PTK and 2 GTKs. If the peer's GTK isn't installed, the STA

[PATCH] ath9k: return false when reading wrong eeprom offset

Just setting the proper return for reading beyond the eeprom data. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/pci.c

Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

I set a successful AP network with WPA-PSK (see conf and log attached). As you can see on log, the message "Could not set station 48:45:20:3b:31:75 flags for kernel driver" appears too, but the connection is OK. Le 2016-06-15 13:35, Raymond Hayes a écrit : The logs were from wpa_supplicant

RE: Problems with mwifiex_pcie firmware activation

Hi Stanislaw, > From: Stanislaw Gruszka [mailto:sgrus...@redhat.com] > Sent: Tuesday, June 14, 2016 7:20 PM > To: Amitkumar Karwar > Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org > Subject: Problems with mwifiex_pcie firmware activation > > I have two systems with this device: > >

Re: [PATCH] libertas: Add spinlock to avoid race condition

On Wednesday 15 June 2016 05:04 PM, Pavel Andrianov wrote: > lbs_mac_event_disconnected may free priv->currenttxskb > while lbs_hard_start_xmit accesses to it. > The patch adds a spinlock for mutual exclusion. > > Tested on OLPC XO-1 (usb8388) and XO-1.5 (sd8686) with v4.7-rc3. > > Confirmed

Re: [PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

On Wed, 2016-06-15 at 14:37 +0200, Martin Willi wrote: > > > > > > >  printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink" > > >         " socket, switching to perfect channel medium\n"); > > > I wonder if we can do something better about them? Or perhaps if we > > should remove them,

Re: [PATCH] hsi: Build hsi_boardinfo.c into hsi core if enabled

Hi Andrew, On Tue, Jun 14, 2016 at 11:13:04AM -0500, Andrew F. Davis wrote: > If the HSI core is built as a module hsi_boardinfo may still > be built-in as its Kconfig type is bool, which can cause build > issues. Fix this by building this code into the HSI core when > enabled. > > Reported-by:

[PATCH] libertas: Add spinlock to avoid race condition

lbs_mac_event_disconnected may free priv->currenttxskb while lbs_hard_start_xmit accesses to it. The patch adds a spinlock for mutual exclusion. Tested on OLPC XO-1 (usb8388) and XO-1.5 (sd8686) with v4.7-rc3. Confirmed that lbs_mac_event_disconnected is being called on the station when hostapd

Re: [PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

> > >  printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink" > >         " socket, switching to perfect channel medium\n"); > I wonder if we can do something better about them? Or perhaps if we > should remove them, so other namespaces won't mess up the kernel log This is in fact not

Re: [PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

I was about to apply this (with a typo fix for "responsile"), but noticed these messages: >   printk(KERN_DEBUG "mac80211_hwsim: received a REGISTER, " >      "switching to wmediumd mode with pid %d\n", info- > >snd_portid); > + if (notify->portid ==

Re: Problems with mwifiex_pcie firmware activation

On Tue, Jun 14, 2016 at 05:12:50PM +0300, Kalle Valo wrote: > Stanislaw Gruszka writes: > > > Hence looks like forcing firmware upload somehow changed device, now it > > is capable to initialize. On my second system device is on pristine state > > and original problem is

Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

Hi Raymond, Who is trying to mark the peer authorized? Should I look into mwifiex driver? cfg80211.ko? libnl? wpa_supplicant? I am a bit lost among all these elements. Vincent Le 2016-06-14 02:30, Raymond Hayes a écrit : From the RSN log, the dual 4-way handshakes succeeded, but the GTK

Re: [PATCH 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set

Hi Andrew, Thanks for the patch. Please address the issue [1] raised by test bot and resubmit. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2016/6/13/1091 On 06/13/2016 10:02 PM, Andrew F. Davis wrote: When CONFIG_NEW_LEDS is not set make will still descend into the leds directory but