Re: pull-request: wireless-drivers-next 2016-07-13

Hi, [auto build test ERROR on wireless-drivers-next/master] [cannot apply to v4.7-rc7 next-20160714] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kalle-Valo/pull-request-wireless-drivers-next

Re: pull-request: wireless-drivers-next 2016-07-13

From: Kalle Valo Date: Wed, 13 Jul 2016 21:29:13 +0300 > here's a pull request for net-next. This time there are few conflicts > due to the cfg80211 scan API changes, and one of them is easy to miss, > so please pay extra attention to them. Otherwise there's not nothing >

Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets

2016-07-14 10:57 GMT+02:00 Arend Van Spriel : > On 13-7-2016 20:52, Per Förlin wrote: >> 2016-07-13 13:20 GMT+02:00 Arend Van Spriel : >>> On 12-7-2016 12:23, Per Förlin wrote: 2016-07-12 11:48 GMT+02:00 Arend Van Spriel

Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding

On Monday, July 11, 2016 11:21:26 PM CEST Martin Blumenstingl wrote: > On Mon, Jul 11, 2016 at 12:01 AM, Arnd Bergmann wrote: > >> ath9k reads the data from the EEPROM into memory. With that property > >> disabled ath9k simply assumes that the endianness of the values in the > >>

Re: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for wl8

"Machani, Yaniv" writes: > On Tue, Jun 28, 2016 at 13:41:35, Machani, Yaniv wrote: >> Guy; Johannes Berg; Arik Nemtsov; linux-wireless@vger.kernel.org; >> net...@vger.kernel.org >> Subject: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for >> wl8 >> >> From: Maital

[PATCH] staging: rtl8723au: hal: check BT_Active and BT_State with correct bit pattern

From: Colin Ian King BT_Active and BT_State are being masked with 0x00ff so it the subsequent comparisons with 0x are therefore a buggy check. Instead, check them against 0x00ff. Unfortunately I couldn't find a datasheet or hardware to see if

Re: iwlwifi + wpa2-leap + multiple AP's = call trace

On Wed, Jul 13, 2016 at 9:33 PM, Ismael Farfán wrote: > Hi > > I'm using wicd, so changed from wext to nl80211 and I don't see the > trace anymore... it still refuses to connect though, so I'll check > what's wrong with my configuration. > > Do you want me to collect some

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

> > On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote: > > I guess that works, but it seems wrong to me. Usually, registration > > should happen only upon INIT, and yes, at that time the firmware is > > not ready to provide the information yet. > > > > > > > As can be seen in

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote: > I guess that works, but it seems wrong to me. Usually, registration > should happen only upon INIT, and yes, at that time the firmware is not > ready to provide the information yet. > > > > As can be seen in the current code

Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets

On 13-7-2016 20:52, Per Förlin wrote: > 2016-07-13 13:20 GMT+02:00 Arend Van Spriel : >> On 12-7-2016 12:23, Per Förlin wrote: >>> 2016-07-12 11:48 GMT+02:00 Arend Van Spriel : On 12-7-2016 10:35, Per Förlin wrote: >

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

Prarit Bhargava writes: > On 07/13/2016 03:24 AM, Luca Coelho wrote: > >> I totally agree with Emmanuel and Kalle. We should not change this. >> It is a design decision to return an error when the interface is >> down, this is very common with other subsystems as well. > >

Re: [PATCH 0/4 v1] Refactoring ieee80211_iface_work

On 13-7-2016 22:19, Alex Briskin wrote: > Hi All, > This is my first patch(s). Hi Alex, As these patches are touching mac80211 it would be good to use 'mac80211: ' prefix. > I've decided to refactor ieee80211_iface_work function and break it down > to smaller better defined function. > > I

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

Prarit Bhargava writes: > On 07/13/2016 02:50 AM, Kalle Valo wrote: >> Prarit Bhargava writes: >> We implement thermal zone because we do support it, but the problem is that we need the firmware to be loaded for that. So you can argue that