Re: [Patch] NFC: trf7970a:

On Thu, Dec 15, 2016 at 09:52:10PM -0700, Mark Greer wrote: > On Wed, Dec 14, 2016 at 03:31:23PM -0700, Mark Greer wrote: > > I'll start on this > > tonight but won't likely get far until tomorrow. In the meantime, > > if you and/or your contractor make progress, please share. > > Geoff, > >

Re: [PATCH 03/14 V2] rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG

On Thu, 2016-12-15 at 12:22 -0600, Larry Finger wrote: > This is a step toward eliminating the RT_TRACE macros. Those calls that > have DBG_EMERG as the level are always logged, and they represent error > conditions, thus they are replaced with pr_err(). OK, > diff --git

Re: [PATCH 02/14 V2] rtlwifi: Remove RT_TRACE messages that use DBG_EMERG

On Thu, 2016-12-15 at 12:22 -0600, Larry Finger wrote: > These messages are always logged and represent error conditions, thus > we can use pr_err(). OK and some trivialities: > diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c > b/drivers/net/wireless/realtek/rtlwifi/base.c [] > @@

"rfkill: Add rfkill-any LED trigger" causes deadlock

On Fri, Dec 16, 2016 at 07:46:06PM +0300, Михаил Кринкин wrote: > Hi, > > with recent i can't load my thinkpad with recent linux-next, bisect points > at the commit 73f4f76a196d7adb ("rfkill: Add rfkill-any LED trigger"). > > Problem occurs because thinkapd_acpi rfkill set_block handler >

"rfkill: Add rfkill-any LED trigger" causes deadlock

Hi, with recent i can't load my thinkpad with recent linux-next, bisect points at the commit 73f4f76a196d7adb ("rfkill: Add rfkill-any LED trigger"). Problem occurs because thinkapd_acpi rfkill set_block handler tpacpi_rfk_hook_set_block calls rfkill_set_sw_state, which in turn calls new

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

On Fri, 2016-12-16 at 13:17 +0100, Arend Van Spriel wrote: > > > I have no problem introducing a common storage for this, if > > necessary with some fields/nl attributes being optional, but I > > suspect this is actually a necessary part of gscan, otherwise > > you're not able to report all the

pull-request: mac80211 2016-12-16

Hi Dave, Since you seem to be updating net, I thought I'd send you a few fixes. These aren't really all that important though, so if you want to let them wait for a bit I can live with that. Please pull and let me know if there's any problem. Thanks, johannes The following changes since

Re: [PATCH] nl80211: better describe field in struct nl80211_bss_select_rssi_adjust

On Fri, 2016-12-16 at 12:15 +, Arend van Spriel wrote: > The two fields in struct nl80211_bss_select_rssi_adjust did not state > their type or unit. Adding documentation. > Applied, thanks :) johannes

Re: [PATCH] nl80211: rework {sched_,}scan event related functions

On Fri, 2016-12-16 at 11:21 +, Arend van Spriel wrote: > A couple of functions used with scan events were named with > term "send" although they were only preparing the the event > message so renamed those. Applied - I added a mention of nl80211_send_sched_scan_results() to the commit log

Re: [RFC V3 03/11] nl80211: add support for gscan

On 16-12-2016 11:13, Johannes Berg wrote: > On Wed, 2016-12-14 at 10:01 +0100, Arend Van Spriel wrote: > >> Had to look for "> 16" ;-) > > Sorry. > >> Here an instance of the tab vs. space issue you mentioned. Will go >> over the patch and fix that. > > There were a few, not really interesting

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

On 16-12-2016 11:02, Johannes Berg wrote: > >> Not sure what is meant by "through the buckets". > > TBH, I was handwaving because I don't understand this part of gscan > well :-) > >> Referring to your >> remark/question in the "Unversal scan proposal" thread: >> >> """ >> I'm much more worried

[PATCH] nl80211: better describe field in struct nl80211_bss_select_rssi_adjust

The two fields in struct nl80211_bss_select_rssi_adjust did not state their type or unit. Adding documentation. Reported-by: Jouni Malinen Signed-off-by: Arend van Spriel --- include/uapi/linux/nl80211.h | 5 +++-- 1 file changed, 3 insertions(+), 2

Re: [RFC v2 11/11] ath10k: Added sdio support

Erik Stromdahl writes: > Initial HIF sdio/mailbox implementation. > > Signed-off-by: Erik Stromdahl I know most of this coming from ath6kl but I think we should still improve the code. Lots of comments will follow, don't get scared :) >

[PATCH] nl80211: rework {sched_,}scan event related functions

A couple of functions used with scan events were named with term "send" although they were only preparing the the event message so renamed those. Signed-off-by: Arend van Spriel --- net/wireless/nl80211.c | 34 --

Re: wl1251 NVS calibration data format

Resending email to new Gery's address... On Friday 16 December 2016 12:01:48 Pali Rohár wrote: > Hi! Do you know format of wl1251 NVS calibration data file? > > I found that there is tool for changing NVS file for wl1271 and newer > chips (so not for wl1251!) at: https://github.com/gxk/ti-utils

wl1251 NVS calibration data format

Hi! Do you know format of wl1251 NVS calibration data file? I found that there is tool for changing NVS file for wl1271 and newer chips (so not for wl1251!) at: https://github.com/gxk/ti-utils And wl1271 has in NVS data already place for MAC address. And in wlcore (for wl1271 and newer) there

Re: wl1251 & mac address & calibration data

On Friday 16 December 2016 08:25:44 Daniel Wagner wrote: > On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote: > > For the new API a solution for "fallback mechanisms" should be > > clean though and I am looking to stay as far as possible from the > > existing mess. A solution to help both the old

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

> Not sure what is meant by "through the buckets". TBH, I was handwaving because I don't understand this part of gscan well :-) > Referring to your > remark/question in the "Unversal scan proposal" thread: > > """ > I'm much more worried about the "bucket reporting" since that doesn't > fit

Re: wl1251 & mac address & calibration data

On Friday 16 December 2016 03:03:19 Luis R. Rodriguez wrote: > On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel > > wrote: > > On 15-12-2016 16:33, Pali Rohár wrote: > >> On Thu Dec 15 09:18:44 2016 Kalle Valo > >> wrote: > >>> (Adding Luis

Re: wl1251 & mac address & calibration data

On Thursday 15 December 2016 21:12:47 Arend Van Spriel wrote: > On 15-12-2016 16:33, Pali Rohár wrote: > > On Thu Dec 15 09:18:44 2016 Kalle Valo wrote: > >> (Adding Luis because he has been working on request_firmware() > >> lately) > >> > >> Pali Rohár

Re: [RFC v2 06/11] ath10k: htc: Added ATH10K_HTC_FLAG_BUNDLE_LSB

Erik Stromdahl writes: > Signed-off-by: Erik Stromdahl > --- > drivers/net/wireless/ath/ath10k/htc.h |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/wireless/ath/ath10k/htc.h >

Re: [RFC V3 03/11] nl80211: add support for gscan

On Wed, 2016-12-14 at 10:01 +0100, Arend Van Spriel wrote: > Had to look for "> 16" ;-) Sorry. > Here an instance of the tab vs. space issue you mentioned. Will go > over the patch and fix that. There were a few, not really interesting though - git would probably flag it anyway, or checkpatch

Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

On Thu, 2016-12-15 at 11:06 +, Malinen, Jouni wrote: > On Tue, Dec 13, 2016 at 04:56:55PM +0100, Johannes Berg wrote: > > Regarding reusing attributes, we have (for the BSS selection thing) > > the attribute NL80211_BSS_SELECT_ATTR_RSSI_ADJUST, which is really > > quite similar to your > > new 

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

> > > > + return; > > > > + > > > > +mic_fail: > > > > + cfg80211_michael_mic_failure(sdata->dev, sta->addr, > > > > +  (status->flag & > > > > RX_FLAG_MCAST) > > > > ? > > > > +  NL80211_KEYTYPE_GROUP : > > > > +

Re: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX

> > > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ? > > > > It's not really clear to me what you intend to do this - if it's > > really support flags then you really should name those better. > > > > This is support flags and it used by the driver to intimate driver  > supported frame type

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

On Thu, 2016-12-15 at 10:43 +, Thiagarajan, Vasanthakumar wrote: > On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote: > > > > > Drivers advertising this capability should also implement other > > > functionalities which deal with 802.11 frame format like below > > > - ADDBA/DELBA

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Fri, 2016-12-16 at 05:37 +, Thiagarajan, Vasanthakumar wrote: > QCA988X does not have capability to configure vif specific decap > mode. Encap mode is configurable per packet for all the ath10k based > chips so this part should be fine to support per vif configuration. Ok, that's good.

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

> Ok. So it is mainly for encap there needs to be some capability > advertisement from driver Obviously, since mac80211 needs to pick the ndo struct to use. > because for decap driver would use appropriate mac80211 Rx function > to indicate? That should be sufficient, no? In fact, for RX,

Re: [PATCH mac80211-next] rfkill: hide unused goto label

On Fri, 2016-12-16 at 09:44 +0100, Arnd Bergmann wrote: > A cleanup introduced a harmless warning in some configurations: > > net/rfkill/core.c: In function 'rfkill_init': > net/rfkill/core.c:1350:1: warning: label 'error_input' defined but > not used [-Wunused-label] > > This adds another

[PATCH mac80211-next] rfkill: hide unused goto label

A cleanup introduced a harmless warning in some configurations: net/rfkill/core.c: In function 'rfkill_init': net/rfkill/core.c:1350:1: warning: label 'error_input' defined but not used [-Wunused-label] This adds another #ifdef around the label to match that around the caller. Fixes: