Re: wireless-drivers: random cleanup patches piling up

[Sudip Mukherjee]

On Fri, Jan 22, 2016 at 05:54:12PM +0200, Kalle Valo wrote:
> "John W. Linville"  writes:
> 
> > On Fri, Jan 22, 2016 at 02:21:20PM +0200, Kalle Valo wrote:
> >> Joe Perches  writes:
> >> 
> >> > On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote:
> >> >> Hi,
> >> >> 
> >> >> I have quite a lot of random cleanup patches from new developers waiting
> >> >> in my queue:
> >> >> 
> >> >> https://patchwork.kernel.org/project/linux-wireless/list/?state=10=25621=date
> >> >> 
> >> >> (Not all of them are cleanup patches, there are also few patches
> >> >> deferred due to other reasons, but you get the idea.)
> >> >> 
> >> >> These cleanup patches usually take quite a lot of my time and I'm
> >> >> starting to doubt the benefit, compared to the time needed to dig
> >> >> through them and figuring out what to apply. And this is of course time
> >> >> away from other patches, so it's slowing down "real" development.
> >> >> 
> >> >> I really don't know what to do. Part of me is saying that I just should
> >> >> drop them unless it's reviewed by a more experienced developer but on
> >> >> the other hand this is a good way get new developers onboard.
> >> >> 
> >> >> What others think? Are these kind of patches useful?
> >> >
> >> > Some yes, mostly not really.
> >> >
> >> > While whitespace style patches have some small value,
> >> > very few of the new contributors that use tools like
> >> > "scripts/checkpatch.pl -f" on various kernel files 
> >> > actually continue on to submit actual defect fixing
> >> > or optimization or code clarity patches.
> >> 
> >> 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 stuff, and send
> > you a pull request a couple of times per release...?
> 
> Not a bad idea! But I don't think we need a separate tree as applying
> patches from patchwork is easy. It should be doable that we add an
> account to patchwork and whenever I see a this type of trivial cleanup
> patch I'll assign it to the cleanup maintainer and whenever he/she
> thinks it's ready he assigns the patch back to me and I'll apply it.
> 
> The only difficult part is finding a victim/volunteer to
> do that ;)

I can be a volunteer (victim?). Though i donot know much about
wireless-drivers, but I do know a little about cleanup patches.
And maybe, in the process I will start knowing wireless-drivers.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Arend van Spriel]

On 26-01-16 00:41, Julian Calaby wrote:
> Hi Arend,
> 
> On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel  wrote:
>> On 25-01-16 12:06, Julian Calaby wrote:
>>> Hi Sjoerd,
>>>
>>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>>  wrote:
 On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
 the card responds very quickly most of the time, unfortunately during
 initialisation it sometimes seems to take just a bit over 2 seconds to
 respond.

 This results intialization failing with message like:
   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
   brcmf_bus_start: failed: -52
   brcmf_sdio_firmware_callback: dongle is not responding

 Increasing the timeout to allow for a bit more headroom allows the
 card to initialize reliably.

 A quick search online after diagnosing/fixing this showed that Google
 has a similar patch in their ChromeOS tree, so this doesn't seem
 specific to the board I'm using.

 Signed-off-by: Sjoerd Simons 
>>>
>>> Looks sane to me.
>>>
>>> Reviewed-by: Julian Calaby 
>>
>> Not really a cleanup patch :-p , but thanks for the review.
> 
> I'm trying to review any "small" patch from (relatively) new people.

And it is surely appreciated. Just read your reply in "cleanup patch
pile" thread and felt I had to make the stupid remark with just fun
intended.

Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211: fix txq queue related crashes

[Michal Kazior]

On 25 January 2016 at 18:59, Ben Greear  wrote:
> On 01/21/2016 05:23 AM, Michal Kazior wrote:
>>
>> The driver can access the queue simultanously
>> while mac80211 tears down the interface. Without
>> spinlock protection this could lead to corrupting
>> sk_buff_head and subsequently to an invalid
>> pointer dereference.
>
> Hard to know for certain, but this *appears* to fix the unexpectedly large
> amount of CE/AXI ath10k firmware crashes that we saw in the 4.2 kernel (4.0
> previously
> ran much better han 4.2 for us).

That's impossible.

Without wake_tx_queue() txqs aren't even allocated (sdata->vif.txq is NULL).


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] brcmfmac: set WIPHY_FLAG_HAVE_AP_SME

[Rafał Miłecki]

On 25 January 2016 at 10:49, Arend van Spriel  wrote:
> On 20-1-2016 13:47, Rafał Miłecki wrote:
>> Now, the problem with brcmfmac is that it doesn't report support for any
>> management frames in AP mode. It supports sending ACTION (and maybe
>> PROBE_RESP) frames, but it can't pass ACTION to the cfg80211. So even if
>> we report we can send ACTION (as it seems we do), it won't fix the
>> problem.
>>
>> So this patch will trigger another code path in hostapd that due to
>> brcmfmac missing support for receiving & passing ACTION will fail.
>>
>> Do you have any idea how to handle this?
>
> The mgmt_tx callback in brcmfmac was added for P2P functionality. So if
> anything, a check should be added to assure it is only used on P2P
> interfaces.
>
>> Should hostapd drop depndency on ACTION frames? Should brcmfmac fake
>> support for receiving & passing ACTION frames? Or should support for
>> ACTION frames be added indeed?
>
> So why not stick with the current implementation. It may not seem
> optimal to first try one thing and fallback to another, but at least it
> works. I was thinking about trying with use_monitor=0, but looking in
> the code nl80211_setup_ap() that will not resolve it either.

I don't like current implementation as it depends on some failure,
fallback & inconsistent code in hostapd. It seems hacky to me and I
can imagine things going wrong on some simple hostapd change. I beliee
it also doesn't allow brcmfmac to implement monitor mode, because once
it's done, hostapd won't hit the same fallback path.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 00/26] use unified firmware and add ops in cfg

[Kalle Valo]

Glen Lee  writes:

> This patch series contains
>   
> * support suspend and resume functionality
>   
> * use a unified firmware for all mode of operations(station, ap, p2p) 
>   
> * support Station/AP concurrency  
>   
> * increase link speed 
>   
> * add a cfg operation for adjusting the tx power  
>   
> * fix bug on p2p, WEP security and chaning virtual interface
>
> Changes in V2: details in each patch files.
>  - 0004-staging-wilc1000-add-sdio-resume-suspend.patch

It's good practise to also add "staging: wilc1000: " prefix to the cover
letter.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] mac80211: always print a message when disconnecting

[Emmanuel Grumbach]

From: Johannes Berg 

Make sure there's at least a debug message whenever the
connection to the AP is terminated.

Also change one message from wiphy_debug() to the common
mlme_dbg().

Signed-off-by: Johannes Berg 
---
 net/mac80211/mlme.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index e6d198b..857089d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3544,6 +3544,9 @@ static void ieee80211_rx_mgmt_beacon(struct 
ieee80211_sub_if_data *sdata,
elems.ht_cap_elem, elems.ht_operation,
elems.vht_operation, bssid, )) {
mutex_unlock(>sta_mtx);
+   sdata_info(sdata,
+  "failed to follow AP %pM bandwidth change, 
disconnect\n",
+  bssid);
ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH,
   WLAN_REASON_DEAUTH_LEAVING,
   true, deauth_buf);
@@ -3919,11 +3922,9 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data 
*sdata)
 * We actually lost the connection ... or did we?
 * Let's make sure!
 */
-   wiphy_debug(local->hw.wiphy,
-   "%s: No probe response from AP %pM"
-   " after %dms, disconnecting.\n",
-   sdata->name,
-   bssid, probe_wait_ms);
+   mlme_dbg(sdata,
+"No probe response from AP %pM after %dms, 
disconnecting.\n",
+bssid, probe_wait_ms);
 
ieee80211_sta_connection_lost(sdata, bssid,
WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY, false);
@@ -4511,6 +4512,9 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data 
*sdata,
if (ifmgd->associated) {
u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];
 
+   sdata_info(sdata,
+  "disconnect from AP %pM for new auth to %pM\n",
+  ifmgd->associated->bssid, req->bss->bssid);
ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH,
   WLAN_REASON_UNSPECIFIED,
   false, frame_buf);
@@ -4579,6 +4583,9 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data 
*sdata,
if (ifmgd->associated) {
u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];
 
+   sdata_info(sdata,
+  "disconnect from AP %pM for new assoc to %pM\n",
+  ifmgd->associated->bssid, req->bss->bssid);
ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH,
   WLAN_REASON_UNSPECIFIED,
   false, frame_buf);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtlwifi: rtl8821ae: Fix 5G failure when EEPROM is incorrectly encoded

[Kalle Valo]

> Recently, it has been reported that D-Link DWA-582 cards, which use an
> RTL8812AE chip are not able to scan for 5G networks. The problems started
> with kernel 4.2, which is the first version that had commit d10101a60372
> ("rtlwifi: rtl8821ae: Fix problem with regulatory information"). With this
> patch, the driver went from setting a default channel plan to using
> the value derived from EEPROM.
> 
> Bug reports at https://bugzilla.kernel.org/show_bug.cgi?id=111031 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1279653 are examples of this
> problem.
> 
> The problem was solved once I learned that the internal country code was
> resulting in a regulatory set with only 2.4 GHz channels. With the RTL8821AE
> chips available to me, the country code was such that both 2.4 and 5 GHz
> channels are allowed. The fix is to allow both bands even when the EEPROM
> is incorrectly encoded.
> 
> Fixes: d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory 
> information")
> Signed-off-by: Larry Finger 
> Cc: littlesmart...@gmail.com
> Cc: g...@codehaus.org
> Cc: Stable  [v4.2+]

Thanks, applied to wireless-drivers.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mac80211: Parse legacy and HT rate in injected frames

[Sven Eckelmann]

Drivers/devices without their own rate control algorithm can get the
information what rates they should use from either the radiotap header of
injected frames or from the rate control algorithm. But the parsing of the
legacy rate information from the radiotap header was removed in commit
e6a9854b05c1 ("mac80211/drivers: rewrite the rate control API").

The removal of this feature heavily reduced the usefulness of frame
injection when wanting to simulate specific transmission behavior. Having
rate parsing together with MCS rates and retry support allows a fine
grained selection of the tx behavior of injected frames for these kind of
tests.

Signed-off-by: Sven Eckelmann 
Cc: Simon Wunderlich 
---
v2:
 - resent RFC as v2 because first patch was not correctly marked as RFC
 - removed check from ieee80211_xmit_fast because this one is never called
   for injected frames

 Documentation/networking/mac80211-injection.txt | 17 ++
 include/net/mac80211.h  |  2 +
 net/mac80211/tx.c   | 73 -
 3 files changed, 89 insertions(+), 3 deletions(-)

diff --git a/Documentation/networking/mac80211-injection.txt 
b/Documentation/networking/mac80211-injection.txt
index 3a93007..ec8f934 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -28,6 +28,23 @@ radiotap headers and used to control injection:
IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for
  an ACK even if it is a unicast frame
 
+ * IEEE80211_RADIOTAP_RATE
+
+   legacy rate for the transmission (only for devices without own rate control)
+
+ * IEEE80211_RADIOTAP_MCS
+
+   HT rate for the transmission (only for devices without own rate control).
+   Also some flags are parsed
+
+   IEEE80211_TX_RC_SHORT_GI: use short guard interval
+   IEEE80211_TX_RC_40_MHZ_WIDTH: send in HT40 mode
+
+ * IEEE80211_RADIOTAP_DATA_RETRIES
+
+   number of retries when either IEEE80211_RADIOTAP_RATE or
+   IEEE80211_RADIOTAP_MCS was used
+
 The injection code can also skip all other currently defined radiotap fields
 facilitating replay of captured radiotap headers directly.
 
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 566df20..3c3c1f3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -708,12 +708,14 @@ enum mac80211_tx_info_flags {
  * protocol frame (e.g. EAP)
  * @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
  * frame (PS-Poll or uAPSD).
+ * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
  *
  * These flags are used in tx_info->control.flags.
  */
 enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_PORT_CTRL_PROTO   = BIT(0),
IEEE80211_TX_CTRL_PS_RESPONSE   = BIT(1),
+   IEEE80211_TX_CTRL_RATE_INJECT   = BIT(2),
 };
 
 /*
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3311ce0..4c79f47 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1476,7 +1476,8 @@ static int invoke_tx_handlers(struct ieee80211_tx_data 
*tx)
CALL_TXH(ieee80211_tx_h_ps_buf);
CALL_TXH(ieee80211_tx_h_check_control_port_protocol);
CALL_TXH(ieee80211_tx_h_select_key);
-   if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL))
+   if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL) &&
+   !(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
 
if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
@@ -1665,15 +1666,24 @@ void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
ieee80211_tx(sdata, sta, skb, false);
 }
 
-static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb)
+static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
+   struct ieee80211_local *local)
 {
struct ieee80211_radiotap_iterator iterator;
struct ieee80211_radiotap_header *rthdr =
(struct ieee80211_radiotap_header *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+   struct ieee80211_supported_band *sband =
+   local->hw.wiphy->bands[info->band];
int ret = ieee80211_radiotap_iterator_init(, rthdr, skb->len,
   NULL);
u16 txflags;
+   u16 rate = 0;
+   bool rate_found = false;
+   u8 rate_retries = 0;
+   u16 rate_flags = 0;
+   u8 mcs_known, mcs_flags;
+   int i;
 
info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT |
   IEEE80211_TX_CTL_DONTFRAG;
@@ -1724,6 +1734,35 @@ static bool ieee80211_parse_tx_radiotap(struct sk_buff 
*skb)
info->flags |= IEEE80211_TX_CTL_NO_ACK;
break;
 
+   case IEEE80211_RADIOTAP_RATE:
+

Re: [PATCH] ath9k_hw: ignore eeprom magic mismatch on flash based devices

[Kalle Valo]

Felix Fietkau  writes:

> Many AR913x based devices (maybe others too) do not have a valid EEPROM
> magic in their calibration data partition.
>
> Fixes: 6fa658fd5ab2 ("ath9k: Simplify and fix eeprom endianness swapping")
> Signed-off-by: Felix Fietkau 

Applied to ath-current in ath.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: fix unnecessary frame drops in mesh fwding

[Michal Kazior]

The ieee80211_queue_stopped() expects hw queue
number but it was given raw WMM AC number instead.

This could cause frame drops and problems with
traffic in some cases - most notably if driver
doesn't map AC numbers to queue numbers 1:1 and
uses ieee80211_stop_queues() and
ieee80211_wake_queue() only without ever calling
ieee80211_wake_queues().

On ath10k it was possible to hit this problem in
the following case:

  1. wlan0 uses queue 0
 (ath10k maps queues per vif)
  2. offchannel uses queue 15
  3. queues 1-14 are unused
  4. ieee80211_stop_queues()
  5. ieee80211_wake_queue(q=0)
  6. ieee80211_wake_queue(q=15)
 (other queues are not woken up because both
  driver and mac80211 know other queues are
  unused)
  7. ieee80211_rx_h_mesh_fwding()
  8. ieee80211_select_queue_80211() returns 2
  9. ieee80211_queue_stopped(q=2) returns true
 10. frame is dropped (oops!)

Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping")
Signed-off-by: Michal Kazior 
---
 net/mac80211/rx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index ae993edfdecf..664e8861edbe 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2235,7 +2235,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
struct ieee80211_local *local = rx->local;
struct ieee80211_sub_if_data *sdata = rx->sdata;
struct ieee80211_if_mesh *ifmsh = >u.mesh;
-   u16 q, hdrlen;
+   u16 ac, q, hdrlen;
 
hdr = (struct ieee80211_hdr *) skb->data;
hdrlen = ieee80211_hdrlen(hdr->frame_control);
@@ -2304,7 +2304,8 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
ether_addr_equal(sdata->vif.addr, hdr->addr3))
return RX_CONTINUE;
 
-   q = ieee80211_select_queue_80211(sdata, skb, hdr);
+   ac = ieee80211_select_queue_80211(sdata, skb, hdr);
+   q = sdata->vif.hw_queue[ac];
if (ieee80211_queue_stopped(>hw, q)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_congestion);
return RX_DROP_MONITOR;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames

[Sven Eckelmann]

On Thursday 26 November 2015 18:25:26 Johannes Berg wrote:
> > We have required the support for rate parsing (legacy + HT) for some
> > tests.
> > It is already known that this may not be the best place to set this
> > flag
> > (IEEE80211_TX_CTRL_RATE_INJECT) but the main flags field is already
> > full.
> 
> It seems you could perhaps put that into struct
> ieee80211_tx_data::flags? Or is it required somewhere outside the
> mac80211 processing?

The flag itself has to be set when the radiotap information is
available+parsed and when the actual rate information calculation should
happen. 

Afaik the ieee80211_tx_data is always a local variable on the stack. Either
from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or
ieee80211_get_buffered_bc. But the parsing of the radiotap header happens
before that in ieee80211_monitor_start_xmit. And after that it calls
ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not available when
the radiotap header is parsed.

> Otherwise I think the place is fine? What issue do you have with it?
> 
> > There is also the problem that powersave could overwrite the rate
> > control
> > fields - so either we disable powersave queueing or find a different
> > solution.
> 
> I have no idea what you mean? The flag - as you have it now - should be
> preserved, no? Perhaps if you moved the flag into tx_data then it
> wouldn't be, and that's a good argument for not moving it?

I was under the impression that the PS could write in part of the
ieee80211_tx_info union which would be in conflict with the control part. But
I've just rechecked the source and could not find anything like that.

> > But maybe this feature is also not wanted anymore in the mac80211
> > driver.
> 
> Well, I'm open to adding the code if you need it. Could consider VHT as
> well, I guess.

I personally don't have VHT hardware which would support injected frames with
self chosen rates. So I cannot test VHT rate injection.

> Adding the check to the fast-xmit path seems neither right nor
> necessary though, since that shouldn't get invoked for injection to
> start with?

Ok, will be removed and I resent it as v2.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

[PATCH 2/3] mac80211: fix ibss scan parameters

[Emmanuel Grumbach]

From: Sara Sharon 

When joining IBSS a full scan should be initiated in order to search
for existing cell, unless the fixed_channel parameter was set.
A default channel to create the IBSS on if no cell was found is
provided as well.
However - a scan is initiated only on the default channel provided
regardless of whether ifibss->fixed_channel is set or not, with the
obvious result of the cell not joining existing IBSS cell that is
on another channel.

Fixes: 76bed0f43b27 ("mac80211: IBSS fix scan request")
Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/ibss.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index e5e8a31..9b98378 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -7,6 +7,7 @@
  * Copyright 2007, Michael Wu 
  * Copyright 2009, Johannes Berg 
  * Copyright 2013-2014  Intel Mobile Communications GmbH
+ * Copyright(c) 2016 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -1483,14 +1484,21 @@ static void ieee80211_sta_find_ibss(struct 
ieee80211_sub_if_data *sdata)
 
sdata_info(sdata, "Trigger new scan to find an IBSS to join\n");
 
-   num = ieee80211_ibss_setup_scan_channels(local->hw.wiphy,
->chandef,
-channels,
-ARRAY_SIZE(channels));
scan_width = cfg80211_chandef_to_scan_width(>chandef);
-   ieee80211_request_ibss_scan(sdata, ifibss->ssid,
-   ifibss->ssid_len, channels, num,
-   scan_width);
+
+   if (ifibss->fixed_channel) {
+   num = 
ieee80211_ibss_setup_scan_channels(local->hw.wiphy,
+
>chandef,
+channels,
+
ARRAY_SIZE(channels));
+   ieee80211_request_ibss_scan(sdata, ifibss->ssid,
+   ifibss->ssid_len, channels,
+   num, scan_width);
+   } else {
+   ieee80211_request_ibss_scan(sdata, ifibss->ssid,
+   ifibss->ssid_len, NULL,
+   0, scan_width);
+   }
} else {
int interval = IEEE80211_SCAN_INTERVAL;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Arend van Spriel]

On 25-1-2016 20:23, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel  wrote:
>> On 25-01-16 11:47, Sjoerd Simons wrote:
>>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>>> the card responds very quickly most of the time, unfortunately during
>>> initialisation it sometimes seems to take just a bit over 2 seconds to
>>> respond.
>>>
>>> This results intialization failing with message like:
>>>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>>>   brcmf_bus_start: failed: -52
>>>   brcmf_sdio_firmware_callback: dongle is not responding
>>>
>>> Increasing the timeout to allow for a bit more headroom allows the
>>> card to initialize reliably.
>>
>> I would prefer to know where the 2 second response time comes from.
>> Could be sdio retuning. Maybe the chromeos people can comment whether
>> this has been root caused.

Hi Doug,

Thanks for the elaborate response

> I reviewed Paul's change here
>  but didn't do
> any root causing.
> 
> I think that, like Sjoerd saw, we were seeing this problem at boot
> time.  Certainly at boot time lots of things are happening all at the
> same time in the system and there are often delays, so anything that
> might have been close to timing out in the past may now be actually
> timing out.
> 
> This is the kind of thing that, IMHO, should have a real timeout that
> is 10x what was expected and a non-fatal warning whenever we go over
> the expected time.  ...but maybe that's overdesign.  :-P
> 
> Kinda curious: do we get one or two really slow responses on every
> bootup, or just some bootups?  Do we ever succeed even with a slow
> (like 1.8 or 1.9 seconds) response, or is it always either "fast" or
> "2.1" seconds?

Now these are interesting questions that I should have spilled out in
the first place. Thanks.

> In any case, in my experience the Broadcom firmware is fairly
> complicated and has numerous cases where it stretches SDIO more than
> the other SDIO WiFi chip I've worked with.  It wouldn't terribly
> surprise me if there was a period of time during bootup where it was
> non-responsive for 2 seconds.  As unrelated "evidence" showing some of
> the Broadcom SDIO limitations, you can see
>  and also the
> fact that Broadcom often holds the SDIO "busy" signal whereas the
> other SDIO WiFi chip I've worked never did that.  Also, even with all
> fixes the Broadcom WiFi module will still show periodic SDIO errors
> that the higher level driver just knows to ignore.

The busy signal is in accordance with the SDIO spec. It would be good to
know if that is what is happening. Unfortunately I do have an SDIO
analyzer, but not reproduced it. May retry on veyron device.

> My old debugging from the (sorry, private) bug
> http://crosbug.com/p/36975 showed this periodically even with all
> known fixes:
> 
> [21310.271635] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
> [21550.583598] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
> [21550.616035] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
> [21550.648460] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
> frame, send NAK
> [21550.683502] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
> [21550.691214] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0100
> [22671.121329] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
> [22671.153167] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x01000104
> [22671.184581] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
> [22671.192600] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
> frame, send NAK
> [22671.201929] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0114
> [22671.209536] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0100
> [28463.941736] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
> 
> At the time dekim@ responded:
> 
>> There are several sleep/wake control at different level. The one we're 
>> talking
>> about here is controlled by brcmf_sdio_bus_sleep() in the host driver to turn
>> on/off bus core on the chip. There can be a period of time when chip is not
>> paying attention to the host command (cmd52 to the
>> SBSDIO_FUNC1_SLEEPCSR).
> 
> ...and we decided that the periodic SDIO errors weren't causing any
> huge problems (since they were retried).  As far as I know, they still
> happen today.

Were these true periodic errors or random at interval.

> 
> All of the above may not help you, but it serves as evidence that the
> SDIO communication to Broadcom isn't terribly amazing and apparently
> that's just the way that the module (or perhaps its firmware) is
> designed.  It doesn't seem to affect anything in the real world, so I
> suppose it is just something we need to live with.
> 
> 
> Obviously if you have access to the firmware source code and can debug
> further, that would be awesome.  I'm just not hopeful.

I have, but that does 

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Doug Anderson]

Hi,

On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel  wrote:
> On 25-01-16 11:47, Sjoerd Simons wrote:
>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>> the card responds very quickly most of the time, unfortunately during
>> initialisation it sometimes seems to take just a bit over 2 seconds to
>> respond.
>>
>> This results intialization failing with message like:
>>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>>   brcmf_bus_start: failed: -52
>>   brcmf_sdio_firmware_callback: dongle is not responding
>>
>> Increasing the timeout to allow for a bit more headroom allows the
>> card to initialize reliably.
>
> I would prefer to know where the 2 second response time comes from.
> Could be sdio retuning. Maybe the chromeos people can comment whether
> this has been root caused.

I reviewed Paul's change here
 but didn't do
any root causing.

I think that, like Sjoerd saw, we were seeing this problem at boot
time.  Certainly at boot time lots of things are happening all at the
same time in the system and there are often delays, so anything that
might have been close to timing out in the past may now be actually
timing out.

This is the kind of thing that, IMHO, should have a real timeout that
is 10x what was expected and a non-fatal warning whenever we go over
the expected time.  ...but maybe that's overdesign.  :-P

Kinda curious: do we get one or two really slow responses on every
bootup, or just some bootups?  Do we ever succeed even with a slow
(like 1.8 or 1.9 seconds) response, or is it always either "fast" or
"2.1" seconds?


In any case, in my experience the Broadcom firmware is fairly
complicated and has numerous cases where it stretches SDIO more than
the other SDIO WiFi chip I've worked with.  It wouldn't terribly
surprise me if there was a period of time during bootup where it was
non-responsive for 2 seconds.  As unrelated "evidence" showing some of
the Broadcom SDIO limitations, you can see
 and also the
fact that Broadcom often holds the SDIO "busy" signal whereas the
other SDIO WiFi chip I've worked never did that.  Also, even with all
fixes the Broadcom WiFi module will still show periodic SDIO errors
that the higher level driver just knows to ignore.

My old debugging from the (sorry, private) bug
http://crosbug.com/p/36975 showed this periodically even with all
known fixes:

[21310.271635] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
[21550.583598] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
[21550.616035] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[21550.648460] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
frame, send NAK
[21550.683502] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
[21550.691214] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0100
[22671.121329] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104
[22671.153167] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x01000104
[22671.184581] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[22671.192600] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
frame, send NAK
[22671.201929] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0114
[22671.209536] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0100
[28463.941736] dwmmc_rockchip ff0d.dwmmc: CMD ERR: 0x0104

At the time dekim@ responded:

> There are several sleep/wake control at different level. The one we're talking
> about here is controlled by brcmf_sdio_bus_sleep() in the host driver to turn
> on/off bus core on the chip. There can be a period of time when chip is not
> paying attention to the host command (cmd52 to the
> SBSDIO_FUNC1_SLEEPCSR).

...and we decided that the periodic SDIO errors weren't causing any
huge problems (since they were retried).  As far as I know, they still
happen today.


All of the above may not help you, but it serves as evidence that the
SDIO communication to Broadcom isn't terribly amazing and apparently
that's just the way that the module (or perhaps its firmware) is
designed.  It doesn't seem to affect anything in the real world, so I
suppose it is just something we need to live with.


Obviously if you have access to the firmware source code and can debug
further, that would be awesome.  I'm just not hopeful.


In any case:

Reviewed-by: Douglas Anderson 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Arend van Spriel]

On 25-01-16 12:06, Julian Calaby wrote:
> Hi Sjoerd,
> 
> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>  wrote:
>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>> the card responds very quickly most of the time, unfortunately during
>> initialisation it sometimes seems to take just a bit over 2 seconds to
>> respond.
>>
>> This results intialization failing with message like:
>>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>>   brcmf_bus_start: failed: -52
>>   brcmf_sdio_firmware_callback: dongle is not responding
>>
>> Increasing the timeout to allow for a bit more headroom allows the
>> card to initialize reliably.
>>
>> A quick search online after diagnosing/fixing this showed that Google
>> has a similar patch in their ChromeOS tree, so this doesn't seem
>> specific to the board I'm using.
>>
>> Signed-off-by: Sjoerd Simons 
> 
> Looks sane to me.
> 
> Reviewed-by: Julian Calaby 

Not really a cleanup patch :-p , but thanks for the review.

Regards,
Arend

> 
>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> index dd66143..75ac4bd 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> @@ -45,8 +45,8 @@
>>  #include "chip.h"
>>  #include "firmware.h"
>>
>> -#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2000)
>> -#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2000)
>> +#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
>> +#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
>>
>>  #ifdef DEBUG
>>
>> --
>> 2.7.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Arend van Spriel]

On 25-01-16 11:47, Sjoerd Simons wrote:
> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
> the card responds very quickly most of the time, unfortunately during
> initialisation it sometimes seems to take just a bit over 2 seconds to
> respond.
> 
> This results intialization failing with message like:
>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>   brcmf_bus_start: failed: -52
>   brcmf_sdio_firmware_callback: dongle is not responding
> 
> Increasing the timeout to allow for a bit more headroom allows the
> card to initialize reliably.

I would prefer to know where the 2 second response time comes from.
Could be sdio retuning. Maybe the chromeos people can comment whether
this has been root caused.

There is a mmc patch pending in which retuning procedure can be deferred
by the driver. Using that API may resolve the issue as well and I would
prefer that solution.

> A quick search online after diagnosing/fixing this showed that Google
> has a similar patch in their ChromeOS tree, so this doesn't seem
> specific to the board I'm using.

As the retuning stuff is not in main line I guess we need this fix for
now so...

Acked-by: Arend van Spriel 
> Signed-off-by: Sjoerd Simons 
> 
> ---
Still would like to know whether it is firmware initialization or some
mmc stack procedure. Any suggestions to debug this are welcome.

Regards,
Arend
---
> 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index dd66143..75ac4bd 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -45,8 +45,8 @@
>  #include "chip.h"
>  #include "firmware.h"
>  
> -#define DCMD_RESP_TIMEOUTmsecs_to_jiffies(2000)
> -#define CTL_DONE_TIMEOUT msecs_to_jiffies(2000)
> +#define DCMD_RESP_TIMEOUTmsecs_to_jiffies(2500)
> +#define CTL_DONE_TIMEOUT msecs_to_jiffies(2500)
>  
>  #ifdef DEBUG
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Sjoerd Simons]

On Mon, 2016-01-25 at 16:36 +0100, Arend van Spriel wrote:
> On 25-01-16 11:47, Sjoerd Simons wrote:
> > On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it
> > seems
> > the card responds very quickly most of the time, unfortunately
> > during
> > initialisation it sometimes seems to take just a bit over 2 seconds
> > to
> > respond.
> > 
> > This results intialization failing with message like:
> >   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
> >   brcmf_bus_start: failed: -52
> >   brcmf_sdio_firmware_callback: dongle is not responding
> > 
> > Increasing the timeout to allow for a bit more headroom allows the
> > card to initialize reliably.
> 
> I would prefer to know where the 2 second response time comes from.
> Could be sdio retuning. Maybe the chromeos people can comment whether
> this has been root caused.

The only reference i could find for where the timeout came from was in
the bcmdhd which has:
  #define IOCTL_RESP_TIMEOUT  2000  /* In milli second default value
for Production FW */

But not sure if that's helpful :). 


> There is a mmc patch pending in which retuning procedure can be
> deferred
> by the driver. Using that API may resolve the issue as well and I
> would
> prefer that solution.
> 
> > A quick search online after diagnosing/fixing this showed that
> > Google
> > has a similar patch in their ChromeOS tree, so this doesn't seem
> > specific to the board I'm using.
> 
> As the retuning stuff is not in main line I guess we need this fix
> for
> now so...
> 
> Acked-by: Arend van Spriel 
> > Signed-off-by: Sjoerd Simons 
> > 
> > ---
> Still would like to know whether it is firmware initialization or
> some
> mmc stack procedure. Any suggestions to debug this are welcome.
> 
> Regards,
> Arend
> ---
> > 
> >  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git
> > a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > index dd66143..75ac4bd 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > @@ -45,8 +45,8 @@
> >  #include "chip.h"
> >  #include "firmware.h"
> >  
> > -#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2000)
> > -#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2000)
> > +#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
> > +#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
> >  
> >  #ifdef DEBUG
> >  
> > 

-- 
Sjoerd Simons
Collabora Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/26] libceph: Use skcipher

[Ilya Dryomov]

On Sun, Jan 24, 2016 at 2:18 PM, Herbert Xu  wrote:
> This patch replaces uses of blkcipher with skcipher.
>
> Signed-off-by: Herbert Xu 
> ---
>
>  net/ceph/crypto.c |   97 
> +++---
>  1 file changed, 56 insertions(+), 41 deletions(-)

Could you get rid of ivsize instead of assigning to it - see the
attached diff?

Otherwise:

Acked-by: Ilya Dryomov 

Thanks,

Ilya
diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
index 42e8649c6e79..db2847ac5f12 100644
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -4,7 +4,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -79,9 +80,9 @@ int ceph_crypto_key_unarmor(struct ceph_crypto_key *key, 
const char *inkey)
return 0;
 }
 
-static struct crypto_blkcipher *ceph_crypto_alloc_cipher(void)
+static struct crypto_skcipher *ceph_crypto_alloc_cipher(void)
 {
-   return crypto_alloc_blkcipher("cbc(aes)", 0, CRYPTO_ALG_ASYNC);
+   return crypto_alloc_skcipher("cbc(aes)", 0, CRYPTO_ALG_ASYNC);
 }
 
 static const u8 *aes_iv = (u8 *)CEPH_AES_IV;
@@ -162,11 +163,10 @@ static int ceph_aes_encrypt(const void *key, int key_len,
 {
struct scatterlist sg_in[2], prealloc_sg;
struct sg_table sg_out;
-   struct crypto_blkcipher *tfm = ceph_crypto_alloc_cipher();
-   struct blkcipher_desc desc = { .tfm = tfm, .flags = 0 };
+   struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
+   SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
-   void *iv;
-   int ivsize;
+   char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - (src_len & 0x0f));
char pad[16];
 
@@ -184,10 +184,13 @@ static int ceph_aes_encrypt(const void *key, int key_len,
if (ret)
goto out_tfm;
 
-   crypto_blkcipher_setkey((void *)tfm, key, key_len);
-   iv = crypto_blkcipher_crt(tfm)->iv;
-   ivsize = crypto_blkcipher_ivsize(tfm);
-   memcpy(iv, aes_iv, ivsize);
+   crypto_skcipher_setkey((void *)tfm, key, key_len);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
+
+   skcipher_request_set_tfm(req, tfm);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, sg_in, sg_out.sgl,
+  src_len + zero_padding, iv);
 
/*
print_hex_dump(KERN_ERR, "enc key: ", DUMP_PREFIX_NONE, 16, 1,
@@ -197,8 +200,8 @@ static int ceph_aes_encrypt(const void *key, int key_len,
print_hex_dump(KERN_ERR, "enc pad: ", DUMP_PREFIX_NONE, 16, 1,
pad, zero_padding, 1);
*/
-   ret = crypto_blkcipher_encrypt(, sg_out.sgl, sg_in,
-src_len + zero_padding);
+   ret = crypto_skcipher_encrypt(req);
+   skcipher_request_zero(req);
if (ret < 0) {
pr_err("ceph_aes_crypt failed %d\n", ret);
goto out_sg;
@@ -211,7 +214,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
 out_sg:
teardown_sgtable(_out);
 out_tfm:
-   crypto_free_blkcipher(tfm);
+   crypto_free_skcipher(tfm);
return ret;
 }
 
@@ -222,11 +225,10 @@ static int ceph_aes_encrypt2(const void *key, int 
key_len, void *dst,
 {
struct scatterlist sg_in[3], prealloc_sg;
struct sg_table sg_out;
-   struct crypto_blkcipher *tfm = ceph_crypto_alloc_cipher();
-   struct blkcipher_desc desc = { .tfm = tfm, .flags = 0 };
+   struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
+   SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
-   void *iv;
-   int ivsize;
+   char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f));
char pad[16];
 
@@ -245,10 +247,13 @@ static int ceph_aes_encrypt2(const void *key, int 
key_len, void *dst,
if (ret)
goto out_tfm;
 
-   crypto_blkcipher_setkey((void *)tfm, key, key_len);
-   iv = crypto_blkcipher_crt(tfm)->iv;
-   ivsize = crypto_blkcipher_ivsize(tfm);
-   memcpy(iv, aes_iv, ivsize);
+   crypto_skcipher_setkey((void *)tfm, key, key_len);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
+
+   skcipher_request_set_tfm(req, tfm);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, sg_in, sg_out.sgl,
+  src1_len + src2_len + zero_padding, iv);
 
/*
print_hex_dump(KERN_ERR, "enc  key: ", DUMP_PREFIX_NONE, 16, 1,
@@ -260,8 +265,8 @@ static int ceph_aes_encrypt2(const void *key, int key_len, 
void *dst,
print_hex_dump(KERN_ERR, "enc  pad: ", DUMP_PREFIX_NONE, 16, 1,
pad, zero_padding, 1);
*/
-   ret = crypto_blkcipher_encrypt(, sg_out.sgl, sg_in,
-src1_len + src2_len + zero_padding);
+   ret = 

Re: [PATCH V2 00/26] use unified firmware and add ops in cfg

[Greg KH]

On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote:
> Glen Lee  writes:
> 
> > This patch series contains  
> > 
> > * support suspend and resume functionality  
> > 
> > * use a unified firmware for all mode of operations(station, ap, p2p)   
> > 
> > * support Station/AP concurrency
> > 
> > * increase link speed   
> > 
> > * add a cfg operation for adjusting the tx power
> > 
> > * fix bug on p2p, WEP security and chaning virtual interface
> >
> > Changes in V2: details in each patch files.
> >  - 0004-staging-wilc1000-add-sdio-resume-suspend.patch
> 
> It's good practise to also add "staging: wilc1000: " prefix to the cover
> letter.

Yes please, otherwise it misses my filters when I go to apply patches
for a subsystem and I have to find it by hand :(
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Bjorn Andersson]

On Tue, Dec 29, 2015 at 11:03 AM, Bjorn Andersson  wrote:
> On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:
>
>> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
>> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
>> > Signed-off-by: Bjorn Andersson 
>> > ---
>> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
>> > ++
>> >  1 file changed, 76 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
>> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
>> > new file mode 100644
>> > index ..7b314b9f30af
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
>> > @@ -0,0 +1,76 @@
>> > +Qualcomm WCN36xx WiFi Binding
>> > +
>> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
>> > block
>> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
>> > variety
>> > +of Qualcomm platforms.
>>
>> Are BT/FM functions completely separate? If so, separate bindings are
>> okay. If not, then we need to describe the full chip.
>>
>
> It's three different hardware blocks (WiFi, BT and FM-radio) with shared
> RF-hardware and an ARM core for control logic.
>
> There seems to be some control commands going towards the BT part that
> controls coexistence properties of the RF-hardware, but other than that
> I see it as logically separate blocks.
>
>
> So I think it's fine to model this as separate pieces in DT.
>

After more testing I've concluded that there is a timing dependency
between the WiFi driver and the wcnss_ctrl driver. If the WiFi driver
starts communicating with the WLAN subsystem in the WCNSS block before
we have finished uploading the NV data to the WCNSS core further
communication will fail.

So looks like I need to remodel this slightly to take this into account :/

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211: fix txq queue related crashes

[Ben Greear]

On 01/21/2016 05:23 AM, Michal Kazior wrote:

The driver can access the queue simultanously
while mac80211 tears down the interface. Without
spinlock protection this could lead to corrupting
sk_buff_head and subsequently to an invalid
pointer dereference.


Hard to know for certain, but this *appears* to fix the unexpectedly large
amount of CE/AXI ath10k firmware crashes that we saw in the 4.2 kernel (4.0 
previously
ran much better han 4.2 for us).

We'll continue testing, in case we are just getting lucky so far.

Thanks,
Ben



Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue 
implementation")
Signed-off-by: Michal Kazior 
---
  net/mac80211/iface.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 33ae3c81bfc5..0451f120746e 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -977,7 +977,10 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data 
*sdata,
if (sdata->vif.txq) {
struct txq_info *txqi = to_txq_info(sdata->vif.txq);

+   spin_lock_bh(>queue.lock);
ieee80211_purge_tx_queue(>hw, >queue);
+   spin_unlock_bh(>queue.lock);
+
atomic_set(>txqs_len[txqi->txq.ac], 0);
}





--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

[Marc Dietrich]

Am Montag 25 Januar 2016, 13:18:40 schrieb Thierry Reding:
> On Mon, Jan 25, 2016 at 12:03:48PM +0300, Heikki Krogerus wrote:
> > Pass the rfkill name and type to the device with properties
> > instead of driver specific platform data.
> > 
> > Signed-off-by: Heikki Krogerus 
> > CC: Alexandre Courbot 
> > CC: Thierry Reding 
> > CC: Stephen Warren 
> > ---
> > 
> >  arch/arm/mach-tegra/board-paz00.c | 17 ++---
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> Looks fine to me. We might want to wait for Marc (Cc'ed) to give this a
> spin, since I don't have the hardware. For reference, the series can be
> found here:
> 
>   http://patchwork.ozlabs.org/patch/572640/
>   http://patchwork.ozlabs.org/patch/572644/
>   http://patchwork.ozlabs.org/patch/572643/
>   http://patchwork.ozlabs.org/patch/572642/
> 
> Johannes, I assume that you'll want to take this through your tree
> because of the dependency? In that case:
> 
> Acked-by: Thierry Reding 

seems to work fine. I wish we could instantiate this from device-tree so we 
can finially get rid of this file.

Tested-by: Marc Dietrich 


signature.asc
Description: This is a digitally signed message part.

[PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Nikolay Martynov]

It looks like sometimes firmware returns zero for chain noise and signal
during calibration period. This seems to be a known problem and current
implementation accounts for this by ignoring invalid data when all chains
return zero signal and noise.

The problem is that sometimes firmware returns zero for only one chain for
some (not all) beacons used for calibration. This leads to perfectly valid
chains be disabled and may cause invalid gain settings.
For example this is calibration data taken on laptop with Intel 6300 card
with all three antennas attached:

active_chains:   3
chain_noise_a:   312
chain_noise_b:   297
chain_noise_c:   0
chain_signal_a:  549
chain_signal_b:  513
chain_signal_c:  0
beacon_count:16
disconn_array:   0 0 1
delta_gain_code: 4 0 0
radio_write: 1
state:   3

This patch changes statistics gathering to make sure that zero noise
results are ignored for valid rx chains. The rationale being that even if
anntenna is not connected we should be able to see non zero noise if rx
chain is present.

This patch fixes the problem of disabling working chains on hardware I
have (6300 and 5300). With three connected antennas statistics in
chain_noise looks like this (6300):

active_chains:   7
chain_noise_a:   321
chain_noise_b:   243
chain_noise_c:   311
chain_signal_a:  559
chain_signal_b:  452
chain_signal_c:  512
beacon_count:16
disconn_array:   0 0 0
delta_gain_code: 4 3 0
radio_write: 1
state:   3

It also works fine in case one 3-chain hardware has only two antennas
attached (tested in 5300):

active_chains:   3
chain_noise_a:   238
chain_noise_b:   234
chain_noise_c:   219
chain_signal_a:  533
chain_signal_b:  514
chain_signal_c:  206
beacon_count:16
disconn_array:   0 0 1
delta_gain_code: 4 0 0
radio_write: 1
state:   3

Signed-off-by: Nikolay Martynov 
---
 drivers/net/wireless/iwlwifi/dvm/calib.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/wireless/iwlwifi/dvm/calib.c 
b/drivers/net/wireless/iwlwifi/dvm/calib.c
index 20e6aa9..cdaa88d 100644
--- a/drivers/net/wireless/iwlwifi/dvm/calib.c
+++ b/drivers/net/wireless/iwlwifi/dvm/calib.c
@@ -1026,6 +1026,18 @@ void iwl_chain_noise_calibration(struct iwl_priv *priv)
 
spin_unlock_bh(>statistics.lock);
 
+   /* Sometimes firmware returns zero for chain noise and signal
+* even if chain is present and antenna is connected. This
+* often results in perfectly valid chains being disabled.
+* Ignore statistics if it contains zero noise for valid rx
+* chain: even with antenna disconnected we should hear some noise.
+*/
+   if ((priv->nvm_data->valid_rx_ant & ANT_A && chain_noise_a == 0) ||
+   (priv->nvm_data->valid_rx_ant & ANT_B && chain_noise_b == 0) ||
+   (priv->nvm_data->valid_rx_ant & ANT_C && chain_noise_c == 0)) {
+   return;
+   }
+
data->beacon_count++;
 
data->chain_noise_a = (chain_noise_a + data->chain_noise_a);
-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcm: add firmware for bcm4366 device

[Rafał Miłecki]

On 25 January 2016 at 10:06, Arend van Spriel  wrote:
> This patch adds firmware for the bcm4366 11ac wlan device which
> is supported by the brcmfmac driver since commit 55acca90da52
> ("brcmfmac: Add support for the BCM4365 and BCM4366 PCIE devices").

Thanks a lot for releasing it so quickly since my report!

Unfrotunately there is some problem with this firmware or brcmfmac
driver. I tried the latest brcmfmac + added 14e4:4365 support on my
D-Link DIR-885L and got this:
[   52.853422] brcmfmac: brcmf_pcie_download_fw_nvram: FW failed to initialize
any hint what could cause this problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcm: add firmware for bcm4366 device

[Kyle McMartin]

On Mon, Jan 25, 2016 at 10:06:56AM +0100, Arend van Spriel wrote:
> This patch adds firmware for the bcm4366 11ac wlan device which
> is supported by the brcmfmac driver since commit 55acca90da52
> ("brcmfmac: Add support for the BCM4365 and BCM4366 PCIE devices").
> 
> Cc: Rafal Milecki 
> Signed-off-by: Arend van Spriel 

applied, thanks.

regards, --kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Julian Calaby]

Hi Arend,

On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel  wrote:
> On 25-01-16 12:06, Julian Calaby wrote:
>> Hi Sjoerd,
>>
>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>  wrote:
>>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>>> the card responds very quickly most of the time, unfortunately during
>>> initialisation it sometimes seems to take just a bit over 2 seconds to
>>> respond.
>>>
>>> This results intialization failing with message like:
>>>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>>>   brcmf_bus_start: failed: -52
>>>   brcmf_sdio_firmware_callback: dongle is not responding
>>>
>>> Increasing the timeout to allow for a bit more headroom allows the
>>> card to initialize reliably.
>>>
>>> A quick search online after diagnosing/fixing this showed that Google
>>> has a similar patch in their ChromeOS tree, so this doesn't seem
>>> specific to the board I'm using.
>>>
>>> Signed-off-by: Sjoerd Simons 
>>
>> Looks sane to me.
>>
>> Reviewed-by: Julian Calaby 
>
> Not really a cleanup patch :-p , but thanks for the review.

I'm trying to review any "small" patch from (relatively) new people.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [PATCH 22/26] iscsi_tcp: Use ahash

[Mike Christie]

On 01/24/2016 07:19 AM, Herbert Xu wrote:
> This patch replaces uses of the long obsolete hash interface with
> ahash.
> 
> Signed-off-by: Herbert Xu 
> ---
> 
>  drivers/scsi/iscsi_tcp.c|   54 
> ++--
>  drivers/scsi/iscsi_tcp.h|4 +--
>  drivers/scsi/libiscsi_tcp.c |   29 +--
>  include/scsi/libiscsi_tcp.h |   13 +-
>  4 files changed, 58 insertions(+), 42 deletions(-)
> 

iSCSI parts look ok.

Reviewed-by: Mike Christie 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

[Heikki Krogerus]

Pass the rfkill name and type to the device with properties
instead of driver specific platform data.

Signed-off-by: Heikki Krogerus 
CC: Alexandre Courbot 
CC: Thierry Reding 
CC: Stephen Warren 
---
 arch/arm/mach-tegra/board-paz00.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-tegra/board-paz00.c 
b/arch/arm/mach-tegra/board-paz00.c
index 49d1110..52db8bf 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -17,23 +17,25 @@
  *
  */
 
+#include 
 #include 
 #include 
-#include 
 
 #include "board.h"
 
-static struct rfkill_gpio_platform_data wifi_rfkill_platform_data = {
-   .name   = "wifi_rfkill",
-   .type   = RFKILL_TYPE_WLAN,
+static struct property_entry __initdata wifi_rfkill_prop[] = {
+   PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
+   PROPERTY_ENTRY_STRING("type", "wlan"),
+   { },
+};
+
+static struct property_set __initdata wifi_rfkill_pset = {
+   .properties = wifi_rfkill_prop,
 };
 
 static struct platform_device wifi_rfkill_device = {
.name   = "rfkill_gpio",
.id = -1,
-   .dev= {
-   .platform_data = _rfkill_platform_data,
-   },
 };
 
 static struct gpiod_lookup_table wifi_gpio_lookup = {
@@ -47,6 +49,7 @@ static struct gpiod_lookup_table wifi_gpio_lookup = {
 
 void __init tegra_paz00_wifikill_init(void)
 {
+   platform_device_add_properties(_rfkill_device, _rfkill_pset);
gpiod_add_lookup_table(_gpio_lookup);
platform_device_register(_rfkill_device);
 }
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 2/4] net: rfkill: gpio: get the name and type from device property

[Heikki Krogerus]

This prepares the driver for removal of platform data.

Signed-off-by: Heikki Krogerus 
---
 net/rfkill/rfkill-gpio.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 4b1e3f3..1a9c031 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -81,7 +81,6 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
if (!id)
return -ENODEV;
 
-   rfkill->name = dev_name(dev);
rfkill->type = (unsigned)id->driver_data;
 
return acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
@@ -93,12 +92,21 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
struct rfkill_gpio_data *rfkill;
struct gpio_desc *gpio;
+   const char *type_name;
int ret;
 
rfkill = devm_kzalloc(>dev, sizeof(*rfkill), GFP_KERNEL);
if (!rfkill)
return -ENOMEM;
 
+   device_property_read_string(>dev, "name", >name);
+   device_property_read_string(>dev, "type", _name);
+
+   if (!rfkill->name)
+   rfkill->name = dev_name(>dev);
+
+   rfkill->type = rfkill_find_type(type_name);
+
if (ACPI_HANDLE(>dev)) {
ret = rfkill_gpio_acpi_probe(>dev, rfkill);
if (ret)
@@ -124,10 +132,8 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
 
rfkill->shutdown_gpio = gpio;
 
-   /* Make sure at-least one of the GPIO is defined and that
-* a name is specified for this instance
-*/
-   if ((!rfkill->reset_gpio && !rfkill->shutdown_gpio) || !rfkill->name) {
+   /* Make sure at-least one GPIO is defined for this instance */
+   if (!rfkill->reset_gpio && !rfkill->shutdown_gpio) {
dev_err(>dev, "invalid platform data\n");
return -EINVAL;
}
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 4/4] net: rfkill: gpio: remove rfkill_gpio_platform_data

[Heikki Krogerus]

No more users for it.

Signed-off-by: Heikki Krogerus 
---
 include/linux/rfkill-gpio.h | 37 -
 net/rfkill/Kconfig  |  3 +--
 net/rfkill/rfkill-gpio.c|  8 
 3 files changed, 1 insertion(+), 47 deletions(-)
 delete mode 100644 include/linux/rfkill-gpio.h

diff --git a/include/linux/rfkill-gpio.h b/include/linux/rfkill-gpio.h
deleted file mode 100644
index 20bcb55..000
--- a/include/linux/rfkill-gpio.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright (c) 2011, NVIDIA Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- */
-
-
-#ifndef __RFKILL_GPIO_H
-#define __RFKILL_GPIO_H
-
-#include 
-#include 
-
-/**
- * struct rfkill_gpio_platform_data - platform data for rfkill gpio device.
- * for unused gpio's, the expected value is -1.
- * @name:  name for the gpio rf kill instance
- */
-
-struct rfkill_gpio_platform_data {
-   char*name;
-   enum rfkill_typetype;
-};
-
-#endif /* __RFKILL_GPIO_H */
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 598d374..868f1ad 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -41,5 +41,4 @@ config RFKILL_GPIO
default n
help
  If you say yes here you get support of a generic gpio RFKILL
- driver. The platform should fill in the appropriate fields in the
- rfkill_gpio_platform_data structure and pass that to the driver.
+ driver.
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 1a9c031..76c01cb 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -27,8 +27,6 @@
 #include 
 #include 
 
-#include 
-
 struct rfkill_gpio_data {
const char  *name;
enum rfkill_typetype;
@@ -89,7 +87,6 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
 
 static int rfkill_gpio_probe(struct platform_device *pdev)
 {
-   struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
struct rfkill_gpio_data *rfkill;
struct gpio_desc *gpio;
const char *type_name;
@@ -111,11 +108,6 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
ret = rfkill_gpio_acpi_probe(>dev, rfkill);
if (ret)
return ret;
-   } else if (pdata) {
-   rfkill->name = pdata->name;
-   rfkill->type = pdata->type;
-   } else {
-   return -ENODEV;
}
 
rfkill->clk = devm_clk_get(>dev, NULL);
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 1/4] net: rfkill: add rfkill_find_type function

[Heikki Krogerus]

Helper for finding the type based on name. Useful if the
type needs to be determined based on device property.

Signed-off-by: Heikki Krogerus 
---
 include/linux/rfkill.h | 15 +
 net/rfkill/core.c  | 57 +-
 2 files changed, 44 insertions(+), 28 deletions(-)

diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index d901078..522ccbc 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -212,6 +212,15 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, 
bool hw);
  * @rfkill: rfkill struct to query
  */
 bool rfkill_blocked(struct rfkill *rfkill);
+
+/**
+ * rfkill_find_type - Helpper for finding rfkill type by name
+ * @name: the name of the type
+ *
+ * Returns enum rfkill_type that conrresponds the name.
+ */
+enum rfkill_type rfkill_find_type(const char *name);
+
 #else /* !RFKILL */
 static inline struct rfkill * __must_check
 rfkill_alloc(const char *name,
@@ -268,6 +277,12 @@ static inline bool rfkill_blocked(struct rfkill *rfkill)
 {
return false;
 }
+
+static inline enum rfkill_type rfkill_find_type(const char *name)
+{
+   return RFKILL_TYPE_ALL;
+}
+
 #endif /* RFKILL || RFKILL_MODULE */
 
 
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f53bf3b6..e9a5cdf 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -582,6 +582,33 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, 
bool hw)
 }
 EXPORT_SYMBOL(rfkill_set_states);
 
+static const char *rfkill_types[NUM_RFKILL_TYPES] = {
+   [RFKILL_TYPE_WLAN]  = "wlan",
+   [RFKILL_TYPE_BLUETOOTH] = "bluetooth",
+   [RFKILL_TYPE_UWB]   = "ultrawideband",
+   [RFKILL_TYPE_WIMAX] = "wimax",
+   [RFKILL_TYPE_WWAN]  = "wwan",
+   [RFKILL_TYPE_GPS]   = "gps",
+   [RFKILL_TYPE_FM]= "fm",
+   [RFKILL_TYPE_NFC]   = "nfc",
+};
+
+enum rfkill_type rfkill_find_type(const char *name)
+{
+   int i;
+
+   BUILD_BUG_ON(!rfkill_types[NUM_RFKILL_TYPES - 1]);
+
+   if (!name)
+   return RFKILL_TYPE_ALL;
+
+   for (i = 1; i < NUM_RFKILL_TYPES; i++)
+   if (!strcmp(name, rfkill_types[i]))
+   return i;
+   return RFKILL_TYPE_ALL;
+}
+EXPORT_SYMBOL(rfkill_find_type);
+
 static ssize_t name_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -591,38 +618,12 @@ static ssize_t name_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(name);
 
-static const char *rfkill_get_type_str(enum rfkill_type type)
-{
-   BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_NFC + 1);
-
-   switch (type) {
-   case RFKILL_TYPE_WLAN:
-   return "wlan";
-   case RFKILL_TYPE_BLUETOOTH:
-   return "bluetooth";
-   case RFKILL_TYPE_UWB:
-   return "ultrawideband";
-   case RFKILL_TYPE_WIMAX:
-   return "wimax";
-   case RFKILL_TYPE_WWAN:
-   return "wwan";
-   case RFKILL_TYPE_GPS:
-   return "gps";
-   case RFKILL_TYPE_FM:
-   return "fm";
-   case RFKILL_TYPE_NFC:
-   return "nfc";
-   default:
-   BUG();
-   }
-}
-
 static ssize_t type_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
struct rfkill *rfkill = to_rfkill(dev);
 
-   return sprintf(buf, "%s\n", rfkill_get_type_str(rfkill->type));
+   return sprintf(buf, "%s\n", rfkill_types[rfkill->type]);
 }
 static DEVICE_ATTR_RO(type);
 
@@ -768,7 +769,7 @@ static int rfkill_dev_uevent(struct device *dev, struct 
kobj_uevent_env *env)
if (error)
return error;
error = add_uevent_var(env, "RFKILL_TYPE=%s",
-  rfkill_get_type_str(rfkill->type));
+  rfkill_types[rfkill->type]);
if (error)
return error;
spin_lock_irqsave(>lock, flags);
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] brcmfmac: set WIPHY_FLAG_HAVE_AP_SME

[Arend van Spriel]

On 20-1-2016 13:47, Rafał Miłecki wrote:
> This allows user space check NL80211_ATTR_DEVICE_AP_SME and realize it's
> dealing with a FullMAC device. It's important for a proper AP setup.
> So far user space was only able to guess it's AP_SME after failing to
> create monitor interface.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> While this patch makes sense to me, it's breaking user space (hostapd).
> 
> There are two similar code paths in hostapd for FullMAC devices. For
> details see nl80211_setup_ap, below is my summary:
> 
> 1) hostapd doesn't get AP_SME
> It tries to create monitor interface and after failing to it fallbacks
> to the AP_SME:
>> nl80211: Setup AP(wlan0) - device_ap_sme=0 use_monitor=1
>> Failed to create interface mon.wlan0: -95 (Not supported)
>> nl80211: Driver does not support monitor interface type - try to run without 
>> it
> After that it tries to register for PROBE_REQ management frames but it's
> not required to succeed.
> 
> 2) hostapd knows about AP_SME
> It tries to register for ACTION management frames requiring it to
> succeed. If it fails it goes like this:
>> nl80211: Subscribe to mgmt frames with AP handle 0x99f50 (device SME)
>> nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0x99f50 
>> match=
>> nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)
>> nl80211: Register frame match - hexdump(len=0): [NULL]
>> nl80211: Could not configure driver mode
> 
> Now, the problem with brcmfmac is that it doesn't report support for any
> management frames in AP mode. It supports sending ACTION (and maybe
> PROBE_RESP) frames, but it can't pass ACTION to the cfg80211. So even if
> we report we can send ACTION (as it seems we do), it won't fix the
> problem.
> 
> So this patch will trigger another code path in hostapd that due to
> brcmfmac missing support for receiving & passing ACTION will fail.
> 
> Do you have any idea how to handle this?

The mgmt_tx callback in brcmfmac was added for P2P functionality. So if
anything, a check should be added to assure it is only used on P2P
interfaces.

> Should hostapd drop depndency on ACTION frames? Should brcmfmac fake
> support for receiving & passing ACTION frames? Or should support for
> ACTION frames be added indeed?

So why not stick with the current implementation. It may not seem
optimal to first try one thing and fallback to another, but at least it
works. I was thinking about trying with use_monitor=0, but looking in
the code nl80211_setup_ap() that will not resolve it either.

Regards,
Arend

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 7b01e4d..ab431e5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6180,6 +6180,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, 
> struct brcmf_if *ifp)
>   wiphy->cipher_suites = __wl_cipher_suites;
>   wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites);
>   wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
> + WIPHY_FLAG_HAVE_AP_SME |
>   WIPHY_FLAG_OFFCHAN_TX |
>   WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
>   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_TDLS))
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: fix setting primary channel for 80 MHz width

[Arend van Spriel]

On 20-1-2016 16:46, Rafał Miłecki wrote:
> First of all it changes the way we calculate primary channel offset. If
> we use e.g. 80 MHz channel with primary frequency 5180 MHz (which means
> center frequency is 5210 MHz) it makes sense to calculate primary offset
> as -30 MHz.
> Then it fixes values we compare primary_offset with. We were comparing
> offset in MHz against -2 or 2 which was resulting in picking a wrong
> primary channel.

Not sure about comparing explicit values here, but it looks fine by me.

Acked-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 23 
> ++
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 8d9cff4..2b335de 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -247,7 +247,7 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf 
> *d11inf,
>   brcmf_dbg(TRACE, "chandef: control %d center %d width %d\n",
> ch->chan->center_freq, ch->center_freq1, ch->width);
>   ch_inf.chnum = ieee80211_frequency_to_channel(ch->center_freq1);
> - primary_offset = ch->center_freq1 - ch->chan->center_freq;
> + primary_offset = ch->chan->center_freq - ch->center_freq1;
>   switch (ch->width) {
>   case NL80211_CHAN_WIDTH_20:
>   case NL80211_CHAN_WIDTH_20_NOHT:
> @@ -256,24 +256,21 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf 
> *d11inf,
>   break;
>   case NL80211_CHAN_WIDTH_40:
>   ch_inf.bw = BRCMU_CHAN_BW_40;
> - if (primary_offset < 0)
> + if (primary_offset > 0)
>   ch_inf.sb = BRCMU_CHAN_SB_U;
>   else
>   ch_inf.sb = BRCMU_CHAN_SB_L;
>   break;
>   case NL80211_CHAN_WIDTH_80:
>   ch_inf.bw = BRCMU_CHAN_BW_80;
> - if (primary_offset < 0) {
> - if (primary_offset < -CH_10MHZ_APART)
> - ch_inf.sb = BRCMU_CHAN_SB_UU;
> - else
> - ch_inf.sb = BRCMU_CHAN_SB_UL;
> - } else {
> - if (primary_offset > CH_10MHZ_APART)
> - ch_inf.sb = BRCMU_CHAN_SB_LL;
> - else
> - ch_inf.sb = BRCMU_CHAN_SB_LU;
> - }
> + if (primary_offset == -30)
> + ch_inf.sb = BRCMU_CHAN_SB_LL;
> + else if (primary_offset == -10)
> + ch_inf.sb = BRCMU_CHAN_SB_LU;
> + else if (primary_offset == 10)
> + ch_inf.sb = BRCMU_CHAN_SB_UL;
> + else
> + ch_inf.sb = BRCMU_CHAN_SB_UU;
>   break;
>   case NL80211_CHAN_WIDTH_80P80:
>   case NL80211_CHAN_WIDTH_160:
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: advertise frames supported for TX in AP mode

[Arend van Spriel]

On 20-1-2016 14:06, Rafał Miłecki wrote:
> Callback mgmt_tx implementation supports both: PROBE_RESP and ACTION.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> This matches code I can see in brcmf_cfg80211_mgmt_tx, hope it makes
> sense.

As said in another response [1] this function was added for P2P
functionality. Hence I do not feel comfortable adding this patch without
subsequent testing.

Regards,
Arend

[1] http://mid.gmane.org/56a5efbd.5070...@broadcom.com

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index ab431e5..8d9cff4 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5948,6 +5948,10 @@ brcmf_txrx_stypes[NUM_NL80211_IFTYPES] = {
>   .rx = BIT(IEEE80211_STYPE_ACTION >> 4) |
> BIT(IEEE80211_STYPE_PROBE_REQ >> 4)
>   },
> + [NL80211_IFTYPE_AP] = {
> + .tx = BIT(IEEE80211_STYPE_ACTION >> 4) |
> +   BIT(IEEE80211_STYPE_PROBE_RESP >> 4)
> + },
>   [NL80211_IFTYPE_P2P_CLIENT] = {
>   .tx = 0x,
>   .rx = BIT(IEEE80211_STYPE_ACTION >> 4) |
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Sjoerd Simons]

On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
the card responds very quickly most of the time, unfortunately during
initialisation it sometimes seems to take just a bit over 2 seconds to
respond.

This results intialization failing with message like:
  brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
  brcmf_bus_start: failed: -52
  brcmf_sdio_firmware_callback: dongle is not responding

Increasing the timeout to allow for a bit more headroom allows the
card to initialize reliably.

A quick search online after diagnosing/fixing this showed that Google
has a similar patch in their ChromeOS tree, so this doesn't seem
specific to the board I'm using.

Signed-off-by: Sjoerd Simons 

---

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dd66143..75ac4bd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -45,8 +45,8 @@
 #include "chip.h"
 #include "firmware.h"
 
-#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2000)
-#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2000)
+#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
+#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
 
 #ifdef DEBUG
 
-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Julian Calaby]

Hi Sjoerd,

On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
 wrote:
> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
> the card responds very quickly most of the time, unfortunately during
> initialisation it sometimes seems to take just a bit over 2 seconds to
> respond.
>
> This results intialization failing with message like:
>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>   brcmf_bus_start: failed: -52
>   brcmf_sdio_firmware_callback: dongle is not responding
>
> Increasing the timeout to allow for a bit more headroom allows the
> card to initialize reliably.
>
> A quick search online after diagnosing/fixing this showed that Google
> has a similar patch in their ChromeOS tree, so this doesn't seem
> specific to the board I'm using.
>
> Signed-off-by: Sjoerd Simons 

Looks sane to me.

Reviewed-by: Julian Calaby 

>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index dd66143..75ac4bd 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -45,8 +45,8 @@
>  #include "chip.h"
>  #include "firmware.h"
>
> -#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2000)
> -#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2000)
> +#define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
> +#define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
>
>  #ifdef DEBUG
>
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

[Thierry Reding]

On Mon, Jan 25, 2016 at 12:03:48PM +0300, Heikki Krogerus wrote:
> Pass the rfkill name and type to the device with properties
> instead of driver specific platform data.
> 
> Signed-off-by: Heikki Krogerus 
> CC: Alexandre Courbot 
> CC: Thierry Reding 
> CC: Stephen Warren 
> ---
>  arch/arm/mach-tegra/board-paz00.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)

Looks fine to me. We might want to wait for Marc (Cc'ed) to give this a
spin, since I don't have the hardware. For reference, the series can be
found here:

http://patchwork.ozlabs.org/patch/572640/
http://patchwork.ozlabs.org/patch/572644/
http://patchwork.ozlabs.org/patch/572643/
http://patchwork.ozlabs.org/patch/572642/

Johannes, I assume that you'll want to take this through your tree
because of the dependency? In that case:

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH V2 00/26] use unified firmware and add ops in cfg

[glen lee]

On 2016년 01월 26일 02:21, Greg KH wrote:

On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote:

Glen Lee  writes:


This patch series contains
* support suspend and resume functionality
* use a unified firmware for all mode of operations(station, ap, p2p)
* support Station/AP concurrency
* increase link speed
* add a cfg operation for adjusting the tx power
* fix bug on p2p, WEP security and chaning virtual interface

Changes in V2: details in each patch files.
  - 0004-staging-wilc1000-add-sdio-resume-suspend.patch

It's good practise to also add "staging: wilc1000: " prefix to the cover
letter.

Yes please, otherwise it misses my filters when I go to apply patches
for a subsystem and I have to find it by hand :(


Oh, I see it helps to filter. I will add prefix also.
Do I need to resend V3 patch series with adding prefix to cover letter?

regards,
glen lee.


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 00/26] use unified firmware and add ops in cfg

[Greg KH]

On Tue, Jan 26, 2016 at 11:44:30AM +0900, glen lee wrote:
> 
> 
> On 2016년 01월 26일 02:21, Greg KH wrote:
> >On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote:
> >>Glen Lee  writes:
> >>
> >>>This patch series contains
> >>>* support suspend and resume functionality
> >>>* use a unified firmware for all mode of operations(station, ap, p2p)
> >>>* support Station/AP concurrency
> >>>* increase link speed
> >>>* add a cfg operation for adjusting the tx power
> >>>* fix bug on p2p, WEP security and chaning virtual interface
> >>>
> >>>Changes in V2: details in each patch files.
> >>>  - 0004-staging-wilc1000-add-sdio-resume-suspend.patch
> >>It's good practise to also add "staging: wilc1000: " prefix to the cover
> >>letter.
> >Yes please, otherwise it misses my filters when I go to apply patches
> >for a subsystem and I have to find it by hand :(
> 
> Oh, I see it helps to filter. I will add prefix also.
> Do I need to resend V3 patch series with adding prefix to cover letter?

No, I'll take it this time...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html