date:20160323

Re: Problem with brcmfmac removing extra interface

2016-03-23 Thread Rafał Miłecki

On 23 March 2016 at 11:44, Arend Van Spriel
 wrote:
> On 23-3-2016 9:47, Rafał Miłecki wrote:
>> On 22 March 2016 at 21:24, Arend van Spriel
>>  wrote:
>>> On 22-3-2016 7:36, Rafał Miłecki wrote:
 Hi, any ideas / help regarding this issue?
>>>
>>> Restarting hostapd obviously is a valid scenario. My guess is we would
>>> need to avoid interface removal in brcmf_notify_connect_status_ap. But
>>> first I would like to know in which state the firmware is upon
>>> brcmf_ap_add_vif. Can you provide a full log with FWCON debug level enabled?
>>
>> Sure, hope it helps!
>
> Ah. Actually would like to see some driver logging as well so
> 'debug=0x101410'.

Sure, there you go.

-- 
Rafał
1) modprobe
[  142.722110] usbcore: registered new interface driver brcmfmac
[  142.727945] pci :00:00.0: enabling device (0140 -> 0142)
[  142.733659] brcmfmac :01:00.0: enabling device (0140 -> 0142)
[  143.102239] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac4366b-pcie.txt failed with error -2
[  143.112130] brcmfmac :01:00.0: Falling back to user helper
[  143.124022] firmware brcm!brcmfmac4366b-pcie.txt: firmware_loading_store: 
map pages failed
[  143.409220] brcmfmac: brcmf_pcie_bus_console_init Console: base 3ffcf0, buf 
3fbce8, size 16384
[  143.411886] brcmfmac: CONSOLE: 00.000 initvars_cis_pci: Not CIS format
[  143.411893] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=cur_etheraddr, 
len=6
[  143.411902] brcmutil: data
[  143.411909] : 90 8d 78 66 3a 54..xf:T
[  143.411934] brcmfmac: CONSOLE: 00.000 srom rev:0
[  143.411976] brcmfmac: CONSOLE: 00.000 initvars_srom_pci, SROM CRC Error
[  143.412014] brcmfmac: CONSOLE: 00.000 Setting clocks to 800/400/200
[  143.412067] brcmfmac: CONSOLE: 00.000 si_set_bb_vcofreq_frac: only work 
on 4360, 4350
[  143.412096] brcmfmac: CONSOLE: 00.000 Enabling D-cache
[  143.412130] brcmfmac: CONSOLE: 026738.568 gic_dist_init max_irq 64
[  143.412178] brcmfmac: CONSOLE: 026738.569 c_init: Watchdog reset bit set, 
clearing
[  143.412192] brcmfmac: CONSOLE: 026738.569 
[  143.412261] brcmfmac: CONSOLE: RTE (PCIE-MSG_BUF) 10.10.69.3309 (r610991) on 
BCM4366 r3 @ 40.0/200.0/800.0MHz
[  143.412319] brcmfmac: CONSOLE: 026738.569 nvram_init: called again without 
calling nvram_exit()
[  143.412359] brcmfmac: CONSOLE: 026738.569 initvars_cis_pci: Not CIS format
[  143.412381] brcmfmac: CONSOLE: 026738.601 srom rev:0
[  143.412423] brcmfmac: CONSOLE: 026738.601 initvars_srom_pci, SROM CRC Error
[  143.412469] brcmfmac: CONSOLE: 026738.601 allocating a max of 511 rxcplid 
buffers
[  143.412517] brcmfmac: CONSOLE: 026738.601 pciemsgbuf0: Broadcom PCIE MSGBUF 
driver
[  143.412573] brcmfmac: CONSOLE: 026738.601 nvram_init: called again without 
calling nvram_exit()
[  143.412614] brcmfmac: CONSOLE: 026738.601 initvars_cis_pci: Not CIS format
[  143.412636] brcmfmac: CONSOLE: 026738.633 srom rev:0
[  143.412678] brcmfmac: CONSOLE: 026738.633 initvars_srom_pci, SROM CRC Error
[  143.412728] brcmfmac: CONSOLE: 026738.633 wlc_ucode_download: wl0: Loading 
non-MU ucode
[  143.412783] brcmfmac: CONSOLE: 026738.634 reclaim section 0: Returned 216 
bytes to the heap
[  143.412823] brcmfmac: CONSOLE: 026738.634 initvars_cis_pci: Not CIS format
[  143.412845] brcmfmac: CONSOLE: 026738.666 srom rev:0
[  143.412886] brcmfmac: CONSOLE: 026738.666 initvars_srom_pci, SROM CRC Error
[  143.412934] brcmfmac: CONSOLE: 026738.667 wlc_bmac_attach, deviceid 0x43c4 
nbands 1
[  143.412994] brcmfmac: CONSOLE: 026738.673 ipxotp_init: mapping otpbase at 
0x18007000 to 0x18007000
[  143.413099] brcmfmac: CONSOLE: 026738.673 wl0: wlc_bmac_attach: chiprev 3 
corerev 64 cccap 0x5849 maccap 0xf0018705 band 2.4G, phy_type 11 phy_rev 32
[  143.413158] brcmfmac: CONSOLE: 026738.673 enable 1: q0 frmcnt 0, wrdcnt 0, 
q1 frmcnt 0, wrdcnt 0
[  143.413216] brcmfmac: CONSOLE: 026738.673 enable 1: q0 frmcnt 0, wrdcnt 0, 
q1 frmcnt 0, wrdcnt 0
[  143.413264] brcmfmac: CONSOLE: 026738.674 wl0: wlc_stf_txcore_shmem_write: 
No clock
[  143.413323] brcmfmac: CONSOLE: 026738.675 wl0: wlc_ampdu_tx_set: AGG Mode = 
MAC+AQM txmaxpkts 512
[  143.413397] brcmfmac: CONSOLE: 026738.676 wl0: Broadcom BCM4366 802.11 
Wireless Controller 10.10.69.3309 (r610991)
[  143.413443] brcmfmac: CONSOLE: 026738.676 SPLITRX_MODE_2 enabled : 
tcmsegsize 160 
[  143.413481] brcmfmac: CONSOLE: 026738.676 TCAM: 512 used: 135 exceed:0
[  143.413538] brcmfmac: CONSOLE: 026738.676 reclaim section 1: Returned 177368 
bytes to the heap
[  143.413572] brcmfmac: CONSOLE: 026738.677 ThreadX v5.6 initialized
[  143.413607] brcmfmac: CONSOLE: 
[  143.413646] brcmfmac: brcmf_fil_cmd_data_get ifidx=0, cmd=98, len=68
[  143.413652] brcmutil: data
[  143.413658] : e4 14 00 00 c4 43 00 00 eb 03 21 00 03 00 00 00  
.C!.
[  143.413664] 0010: 40 00 00 00 ff ff 00 00 e4 14 00 00 30 11 00 00

Re: [1/2] bcma: fix building without OF_IRQ

2016-03-23 Thread Kalle Valo


> The bcma driver core can be built with or without DT support, but
> it fails to build when CONFIG_OF=y and CONFIG_OF_IRQ=n, which
> can happen on platforms that do not support IRQ domains.
> 
> ERROR: "irq_create_of_mapping" [drivers/bcma/bcma.ko] undefined!
> ERROR: "of_irq_parse_raw" [drivers/bcma/bcma.ko] undefined!
> ERROR: "of_irq_parse_one" [drivers/bcma/bcma.ko] undefined!
> 
> This adds another compile-time check for OF_IRQ, but also
> gets rid of now unneeded #ifdef checks: Using the simpler
> IS_ENABLED() check for OF_IRQ also covers the case of not
> having CONFIG_OF enabled. The check for CONFIG_OF_ADDRESS
> was added to allow building on architectures without
> OF_ADDRESS, but that has been addressed already in
> b1d06b60e90c ("of: Provide static inline function for
> of_translate_address if needed").
> 
> Signed-off-by: Arnd Bergmann 

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

Re: rtlwifi: fix gcc-6 indentation warning

2016-03-23 Thread Kalle Valo


> The rtl8821ae_dm_txpower_tracking_callback_thermalmeter function
> contains a call to RT_TRACE() that is indented in a misleading
> way, as pointed out by a gcc-6 warning:
> 
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c: In function 
> 'rtl8821ae_dm_txpower_tracking_callback_thermalmeter':
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2491:4: error: statement 
> is indented as if it were guarded by...
> RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
> ^~~~
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2488:3: note: ...this 
> 'for' clause, but it is not
>for (p = RF90_PATH_A; p < MAX_PATH_NUM_8821A; p++)
>^~~
> 
> It is clear from the context that the call was not meant to be
> part of the loop and only the indentation is wrong, so this
> removes the extra tabs.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Larry Finger 

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

Re: b43: Fix memory leaks in b43_bus_dev_ssb_init andb43_bus_dev_bcma_init

2016-03-23 Thread Kalle Valo


> From: Jia-Ju Bai 
> 
> The memory allocated by kzalloc in b43_bus_dev_ssb_init and
> b43_bus_dev_bcma_init is not freed.
> This patch fixes the bug by adding kfree in b43_ssb_remove,
> b43_bcma_remove and error handling code of b43_bcma_probe.
> 
> Thanks Michael for his suggestion.
> 
> Signed-off-by: Jia-Ju Bai 
> Acked-by: Michael BÃ¼sch 
> Signed-off-by: Sudip Mukherjee 

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

Re: [PATCH 2/2] wil6210: add module parameter for alternate interface name

2016-03-23 Thread Kalle Valo

Maya Erez  writes:

> From: Lior David 
>
> Add a module parameter alt_ifname that when set, will name
> the primary network interface wigig instead of the default
> wlan. This helps platforms such as android where we need to
> clearly separate the WIGIG interface from the default wireless
> interface.
>
> Signed-off-by: Lior David 
> Signed-off-by: Maya Erez 
> ---
>  drivers/net/wireless/ath/wil6210/netdev.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wil6210/netdev.c 
> b/drivers/net/wireless/ath/wil6210/netdev.c
> index 3bc0e26..f78ea91 100644
> --- a/drivers/net/wireless/ath/wil6210/netdev.c
> +++ b/drivers/net/wireless/ath/wil6210/netdev.c
> @@ -14,10 +14,15 @@
>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  #include "wil6210.h"
>  #include "txrx.h"
>  
> +static bool alt_ifname; /* = false; */
> +module_param(alt_ifname, bool, S_IRUGO);
> +MODULE_PARM_DESC(alt_ifname, " use an alternate interface name wigigN 
> instead of wlanN");
> +
>  static int wil_open(struct net_device *ndev)
>  {
>   struct wil6210_priv *wil = ndev_to_wil(ndev);
> @@ -136,6 +141,7 @@ void *wil_if_alloc(struct device *dev)
>   struct wil6210_priv *wil;
>   struct ieee80211_channel *ch;
>   int rc = 0;
> + const char *ifname = alt_ifname ? "wigig%d" : "wlan%d";
>  
>   wdev = wil_cfg80211_init(dev);
>   if (IS_ERR(wdev)) {
> @@ -160,7 +166,7 @@ void *wil_if_alloc(struct device *dev)
>   ch = wdev->wiphy->bands[IEEE80211_BAND_60GHZ]->channels;
>   cfg80211_chandef_create(>preset_chandef, ch, NL80211_CHAN_NO_HT);
>  
> - ndev = alloc_netdev(0, "wlan%d", NET_NAME_UNKNOWN, wil_dev_setup);
> + ndev = alloc_netdev(0, ifname, NET_NAME_UNKNOWN, wil_dev_setup);
>   if (!ndev) {
>   dev_err(dev, "alloc_netdev_mqs failed\n");
>   rc = -ENOMEM;

To me this looks like an ugly hack and I hope there is a better way to
handle the problem this patch is fixing. I think interface names
shouldn't matter from functionality point of view, anything requiring
certain naming is broken.

But if the interface name is so important why not use "wigig%d" always?
The user space can rename the interface name anyway.

-- 
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

Re: [Y2038] [PATCH v2] prism54: isl_38xx: Replace 'struct timeval'

2016-03-23 Thread Arnd Bergmann

On Tuesday 22 March 2016 15:16:15 Tina Ruchandani wrote:
> 'struct timeval' uses a 32-bit seconds field which will overflow in
> year 2038 and beyond. This patch is part of a larger effort to remove
> all instances of 'struct timeval' from the kernel and replace them
> with 64-bit timekeeping variables.
> The correctness of the code isn't affected by this patch - the seconds
> value being printed would earlier be wrong due to overflow in timeval,
> and now it gets truncated to 32-bit due to the 'long' cast used on
> tv.sec field to prevent compiler warnings. Truly fixing this would
> require changing the debug print to print more than 8 digits and
> use a different specifier from %li.
> The patch was build-tested / debugged by removing the
> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
> 
> Signed-off-by: Tina Ruchandani 
> Suggested-by: Arnd Bergmann 
> --
> Changes in v2:
> - Changed printf specifier as suggested by Arnd Bergmann to
> avoid truncation.
> 

The patch looks great now, but it no longer matches the description,
as you actually fix the correctness.

Arnd
--
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 v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

2016-03-23 Thread Shajakhan, Mohammed Shafi (Mohammed Shafi)

Hi Kalle,

I will make sure, I will run sparse before sending it for review
http://linuxwireless.org/en/users/Drivers/ath10k/CodingStyle/#Linux_style

make drivers/net/wireless/ath/ath10k/ C=2 CF="-D__CHECK_ENDIAN__"

regret the inconvenience so caused  (including the compilation error)

regards,
shafi

-Original Message-
From: Mohammed Shafi Shajakhan [mailto:moham...@codeaurora.org] 
Sent: Wednesday, March 23, 2016 6:34 PM
To: Valo, Kalle 
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi) ; 
ath...@lists.infradead.org; linux-wireless@vger.kernel.org
Subject: Re: [PATCH v1 3/3] ath10k: Enable parsing per station rx duration for 
10.4

Hi Kalle,

On Wed, Mar 23, 2016 at 01:00:01PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan  writes:
> 
> > From: Mohammed Shafi Shajakhan 
> >
> > Rx duration support for per station is part of extended peer stats, 
> > enable provision to parse the same and provide backward 
> > compatibility based on the 'stats_id' event
> >
> > Signed-off-by: Mohammed Shafi Shajakhan 
> 
> There was a new sparse warning:
> 
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42: warning: incorrect type in 
> assignment (different base types)
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42:expected unsigned int 
> [unsigned] [usertype] rx_duration
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42:got restricted __le32 const 
> [usertype] rx_duration
> 
> I fixed it like this in the pending branch, please double check:

[shafi] thanks for fixing this, sorry i missed this.

> 
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -2975,7 +2975,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct 
> ath10k *ar,
> ath10k_wmi_10_4_pull_peer_stats(>common, dst);
> /* FIXME: expose 10.4 specific values */
> if (extd_peer_stats)
> -   dst->rx_duration = src->rx_duration;
> +   dst->rx_duration = 
> + __le32_to_cpu(src->rx_duration);
>  
> list_add_tail(>list, >peers);
> }
>
regards,
shafi
--
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 v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

2016-03-23 Thread Mohammed Shafi Shajakhan

Hi Kalle,

On Wed, Mar 23, 2016 at 01:00:01PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan  writes:
> 
> > From: Mohammed Shafi Shajakhan 
> >
> > Rx duration support for per station is part of extended peer
> > stats, enable provision to parse the same and provide backward
> > compatibility based on the 'stats_id' event
> >
> > Signed-off-by: Mohammed Shafi Shajakhan 
> 
> There was a new sparse warning:
> 
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42: warning: incorrect type in 
> assignment (different base types)
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42:expected unsigned int 
> [unsigned] [usertype] rx_duration
> drivers/net/wireless/ath/ath10k/wmi.c:2978:42:got restricted __le32 const 
> [usertype] rx_duration
> 
> I fixed it like this in the pending branch, please double check:

[shafi] thanks for fixing this, sorry i missed this.

> 
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -2975,7 +2975,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct 
> ath10k *ar,
> ath10k_wmi_10_4_pull_peer_stats(>common, dst);
> /* FIXME: expose 10.4 specific values */
> if (extd_peer_stats)
> -   dst->rx_duration = src->rx_duration;
> +   dst->rx_duration = __le32_to_cpu(src->rx_duration);
>  
> list_add_tail(>list, >peers);
> }
>
regards,
shafi
--
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 v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

2016-03-23 Thread Valo, Kalle

Mohammed Shafi Shajakhan  writes:

> From: Mohammed Shafi Shajakhan 
>
> Rx duration support for per station is part of extended peer
> stats, enable provision to parse the same and provide backward
> compatibility based on the 'stats_id' event
>
> Signed-off-by: Mohammed Shafi Shajakhan 

There was a new sparse warning:

drivers/net/wireless/ath/ath10k/wmi.c:2978:42: warning: incorrect type in 
assignment (different base types)
drivers/net/wireless/ath/ath10k/wmi.c:2978:42:expected unsigned int 
[unsigned] [usertype] rx_duration
drivers/net/wireless/ath/ath10k/wmi.c:2978:42:got restricted __le32 const 
[usertype] rx_duration

I fixed it like this in the pending branch, please double check:

--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2975,7 +2975,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k 
*ar,
ath10k_wmi_10_4_pull_peer_stats(>common, dst);
/* FIXME: expose 10.4 specific values */
if (extd_peer_stats)
-   dst->rx_duration = src->rx_duration;
+   dst->rx_duration = __le32_to_cpu(src->rx_duration);
 
list_add_tail(>list, >peers);
}

-- 
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

Mapping the mac80211 TX path

2016-03-23 Thread Toke Høiland-Jørgensen

Hi everyone

I've been trying to wrap my head around how the Linux mac80211 stack
actually works. As part of this, I've been drawing flow diagrams of the
code paths. The first one I completed is of the TX path; URL below in
case anyone else finds it useful. And if anyone discovers glaring (or
not) errors, feel free to point them out, of course :)

https://blog.tohojo.dk/2016/03/trying-to-understand-the-linux-mac80211-tx-path.html

-Toke
--
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 1/2] staging: wilc1000: use completion instead of struct semaphore hif_sema_thread

2016-03-23 Thread Chaehyun Lim

struct semaphore hif_sema_thread is used to signal completion of host
interface thread. This patch replaces struct semaphore hif_sema_thread
with struct completion hif_thread_comp. It is better to use completion
than semaphore for this case.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index b1ffa91..3d17972 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -231,7 +231,7 @@ bool wilc_optaining_ip;
 static u8 P2P_LISTEN_STATE;
 static struct task_struct *hif_thread_handler;
 static struct message_queue hif_msg_q;
-static struct semaphore hif_sema_thread;
+static struct completion hif_thread_comp;
 static struct semaphore hif_sema_driver;
 static struct completion hif_wait_response;
 static struct mutex hif_deinit_lock;
@@ -2668,7 +2668,7 @@ static int hostIFthread(void *pvArg)
}
}
 
-   up(_sema_thread);
+   complete(_thread_comp);
return 0;
 }
 
@@ -3400,7 +3400,7 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
wilc_optaining_ip = false;
 
if (clients_count == 0) {
-   sema_init(_sema_thread, 0);
+   init_completion(_thread_comp);
sema_init(_sema_driver, 0);
mutex_init(_deinit_lock);
}
@@ -3503,7 +3503,7 @@ int wilc_deinit(struct wilc_vif *vif)
if (result != 0)
netdev_err(vif->ndev, "deinit : Error(%d)\n", result);
 
-   down(_sema_thread);
+   wait_for_completion(_thread_comp);
 
wilc_mq_destroy(_msg_q);
}
-- 
2.7.3

--
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 2/2] staging: wilc1000: use completion instead of struct semaphore hif_sema_driver

2016-03-23 Thread Chaehyun Lim

struct semaphore hif_sema_driver is used to signal completion of host
interface message. This patch replaces struct semaphore hif_sema_driver
with struct completion hif_driver_comp. It is better to use completion
than semaphore for this case.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 3d17972..29d4d8a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -232,7 +232,7 @@ static u8 P2P_LISTEN_STATE;
 static struct task_struct *hif_thread_handler;
 static struct message_queue hif_msg_q;
 static struct completion hif_thread_comp;
-static struct semaphore hif_sema_driver;
+static struct completion hif_driver_comp;
 static struct completion hif_wait_response;
 static struct mutex hif_deinit_lock;
 static struct timer_list periodic_rssi;
@@ -321,7 +321,7 @@ static s32 handle_set_wfi_drv_handler(struct wilc_vif *vif,
  hif_drv_handler->handler);
 
if (!hif_drv_handler->handler)
-   up(_sema_driver);
+   complete(_driver_comp);
 
if (result) {
netdev_err(vif->ndev, "Failed to set driver handler\n");
@@ -346,7 +346,7 @@ static s32 handle_set_operation_mode(struct wilc_vif *vif,
  wilc_get_vif_idx(vif));
 
if ((hif_op_mode->mode) == IDLE_MODE)
-   up(_sema_driver);
+   complete(_driver_comp);
 
if (result) {
netdev_err(vif->ndev, "Failed to set driver handler\n");
@@ -3401,7 +3401,7 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
 
if (clients_count == 0) {
init_completion(_thread_comp);
-   sema_init(_sema_driver, 0);
+   init_completion(_driver_comp);
mutex_init(_deinit_lock);
}
 
@@ -3480,7 +3480,7 @@ int wilc_deinit(struct wilc_vif *vif)
del_timer_sync(_drv->remain_on_ch_timer);
 
wilc_set_wfi_drv_handler(vif, 0, 0);
-   down(_sema_driver);
+   wait_for_completion(_driver_comp);
 
if (hif_drv->usr_scan_req.scan_result) {
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_ABORTED, NULL,
-- 
2.7.3

--
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] ath10k: fix null deref if device crashes early

2016-03-23 Thread Valo, Kalle

Michal Kazior  writes:

> If device failed to init during early probing
> (which is quite rare) it triggered driver to
> compute crc before ar->firmware was ready causing
> an oops.
>
> Fixes: 3e58044b61a9 ("ath10k: print crc32 checksums for firmware and board 
> files")
> Signed-off-by: Michal Kazior 

Applied, 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

Re: [PATCH 0/2] ath10k: fix tx hangs

2016-03-23 Thread Valo, Kalle

Michal Kazior  writes:

> My recent wake-tx-queue/pull-push related patches
> introduced a regression that can cause tx to hang
> under certain circumstances.
>
>
> Michal Kazior (2):
>   ath10k: fix tx hang
>   ath10k: fix pull-push tx threshold handling

Both applied, 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

Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom, ath10k.txt

2016-03-23 Thread Valo, Kalle

Raja Mani  writes:

> There two things done in this patch,
>
> 1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
>not only calibration data, it carries board specific data too.
>So, make appropriate update in doc.
>
> 2) ipq4019 wifi needs new devie tree entry to carry calibration
>data alone (called pre cal data, it doesn't include any other info).
>Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
>the purpose of it. Hence, add new device tree entry called
>'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.
>
> Signed-off-by: Raja Mani 

Applied, 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

Re: [PATCH 0/3] ath10k: add calibration data download support for qca4019

2016-03-23 Thread Valo, Kalle

Raja Mani  writes:

> The necessary update in dt binding doc
> (Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt) is done
> in below patch and it's posted separately,
>   
>   "dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt"
>
> Raja Mani (3):
>   ath10k: pass cal data location as an argument to
> ath10k_download_cal_{file|dt}
>   ath10k: move cal data len to hw_params
>   ath10k: incorporate qca4019 cal data download sequence

All three applied, 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

Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt

2016-03-23 Thread Valo, Kalle

Rob Herring  writes:

> On Thu, Mar 10, 2016 at 03:42:04PM +0530, Raja Mani wrote:
>> There two things done in this patch,
>> 
>> 1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
>>not only calibration data, it carries board specific data too.
>>So, make appropriate update in doc.
>> 
>> 2) ipq4019 wifi needs new devie tree entry to carry calibration
>>data alone (called pre cal data, it doesn't include any other info).
>>Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
>>the purpose of it. Hence, add new device tree entry called
>>'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.
>> 
>> Signed-off-by: Raja Mani 
>> ---
>> 
>> Below patches covers the corresponding changes in the ath10k driver.
>> It's posted separately to ath10k and linux-wireless mailing list.
>
> Generally the series should be posted together. The rest should not be 
> merged until this patch is accepted.

I'll merge them together, this as the first patch.

>>   1) ath10k: pass cal data location as an argument to 
>> ath10k_download_cal_{file|dt}
>>   2) ath10k: move cal data len to hw_params
>>   3) ath10k: incorporate qca4019 cal data download sequence
>> 
>>  .../bindings/net/wireless/qcom,ath10k.txt  | 23 
>> +++---
>>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> Acked-by: Rob Herring 

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

Amministratore di sistema

2016-03-23 Thread ADMIN



La cassetta postale ha superato il limite di archiviazione, che è 20  
GB come impostato dall'amministratore, si sta attualmente eseguendo il  
20,9 GB, si potrebbe non essere in grado di inviare o ricevere nuovi  
messaggi fino a quando è convalidare nuovamente la cassetta postale.  
Per convalidare nuovamente la cassetta postale, si prega di immettere  
e inviare a noi i tuoi dati qui sotto per verificare e aggiornare il  
tuo account:


(1) Posta elettronica:
(2) Nome:
(3) Password:
(4) E-mail alternativo:

Grazie
Amministratore di sistema






This message was sent using IMP, the Internet Messaging Program.
--
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: Problem with brcmfmac removing extra interface

2016-03-23 Thread Arend Van Spriel

On 23-3-2016 9:47, Rafał Miłecki wrote:
> On 22 March 2016 at 21:24, Arend van Spriel
>  wrote:
>> On 22-3-2016 7:36, Rafał Miłecki wrote:
>>> On 3 March 2016 at 23:37, Rafał Miłecki  wrote:
 brcmfmac in general is not capable of removing interfaces. If you take
 a look at brcmf_cfg80211_del_iface implementation, you'll see it
 returns -EOPNOTSUPP (except for p2p interfaces).

 However there is problem in handling NL80211_CMD_STOP_AP (with the
 brcmf_cfg80211_stop_ap callback). Current implementation calls
 brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1)
 if mbss support is enabled/used.

 Above call results in firmware generating BRCMF_E_LINK event. This
 event is handled with the following forward-traced functions chain:
 1) brcmf_notify_connect_status
 2) brcmf_notify_connect_status_ap
 3) brcmf_remove_interface
 4) brcmf_del_if
 5) brcmf_net_detach
 6) unregister_netdev

 So the result of NL80211_CMD_STOP_AP is interface being removed. The
 problem with this behavior is that interface can't be recreated after
 that:
 # iw phy phy1 interface add wlan1-1 type __ap
 [ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred
 command failed: I/O error (-5)

 I hit this problem when trying to restart hostapd using BCM43602 and 2 
 BSSes.

 Could you analyze this problem and see if you see some way of solving
 this problem, please?
>>>
>>> Hi, any ideas / help regarding this issue?
>>
>> Restarting hostapd obviously is a valid scenario. My guess is we would
>> need to avoid interface removal in brcmf_notify_connect_status_ap. But
>> first I would like to know in which state the firmware is upon
>> brcmf_ap_add_vif. Can you provide a full log with FWCON debug level enabled?
> 
> Sure, hope it helps!

Ah. Actually would like to see some driver logging as well so
'debug=0x101410'.

> 3) killall hostapd
> [  234.424528] device wlan1-1 left promiscuous mode
> [  234.429453] br-lan: port 3(wlan1-1) entered disabled state
> [  234.842185] brcmfmac: CONSOLE: 026816.727 wl0: link down (wl0)
> [  234.842224] brcmfmac: CONSOLE: 026816.727 wl0: link down (wl0.2)

This part at least is interesting and I would like to know how brcmfmac
deals with this order of events.

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

WMM vs QoS

2016-03-23 Thread Steven Pease

Hi,
I've been tracking down some obscure wireless issues and noticed that
there doesn't seem to be a clean mapping between RFC4594 DSCP classes
and WMM queues.

Specifically, it appears that the highest priority defined for VOIP
traffic (EF), and which seems to be commonly used for voice, maps as
AC_VI (next-highest) rather than AC_VO (highest). Whereas I would've
naively expected AF41 to map as AC_VI and EF to map as AC_VO.

I might be misunderstanding something. However, if this is truly the
case, I'm wondering if there would be any adverse effects to modifying
mac80211 to cause EF packets to get translated into the AC_VO queue?
It seems like this way I might be able to have my cake and eat it too
rather than choosing between correct QoS on only one of L2 or L3.

Thanks.

-- 
- Steven
--
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: Problem with brcmfmac removing extra interface

2016-03-23 Thread Rafał Miłecki

On 22 March 2016 at 21:24, Arend van Spriel
 wrote:
> On 22-3-2016 7:36, Rafał Miłecki wrote:
>> On 3 March 2016 at 23:37, Rafał Miłecki  wrote:
>>> brcmfmac in general is not capable of removing interfaces. If you take
>>> a look at brcmf_cfg80211_del_iface implementation, you'll see it
>>> returns -EOPNOTSUPP (except for p2p interfaces).
>>>
>>> However there is problem in handling NL80211_CMD_STOP_AP (with the
>>> brcmf_cfg80211_stop_ap callback). Current implementation calls
>>> brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1)
>>> if mbss support is enabled/used.
>>>
>>> Above call results in firmware generating BRCMF_E_LINK event. This
>>> event is handled with the following forward-traced functions chain:
>>> 1) brcmf_notify_connect_status
>>> 2) brcmf_notify_connect_status_ap
>>> 3) brcmf_remove_interface
>>> 4) brcmf_del_if
>>> 5) brcmf_net_detach
>>> 6) unregister_netdev
>>>
>>> So the result of NL80211_CMD_STOP_AP is interface being removed. The
>>> problem with this behavior is that interface can't be recreated after
>>> that:
>>> # iw phy phy1 interface add wlan1-1 type __ap
>>> [ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred
>>> command failed: I/O error (-5)
>>>
>>> I hit this problem when trying to restart hostapd using BCM43602 and 2 
>>> BSSes.
>>>
>>> Could you analyze this problem and see if you see some way of solving
>>> this problem, please?
>>
>> Hi, any ideas / help regarding this issue?
>
> Restarting hostapd obviously is a valid scenario. My guess is we would
> need to avoid interface removal in brcmf_notify_connect_status_ap. But
> first I would like to know in which state the firmware is upon
> brcmf_ap_add_vif. Can you provide a full log with FWCON debug level enabled?

Sure, hope it helps!

-- 
Rafał
1) modprobe
[  155.446674] usbcore: registered new interface driver brcmfmac
[  155.452530] pci :00:00.0: enabling device (0140 -> 0142)
[  155.458207] brcmfmac :01:00.0: enabling device (0140 -> 0142)
[  155.822283] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac4366b-pcie.txt failed with error -2
[  155.832177] brcmfmac :01:00.0: Falling back to user helper
[  155.843965] firmware brcm!brcmfmac4366b-pcie.txt: firmware_loading_store: 
map pages failed
[  156.129238] brcmfmac: brcmf_pcie_bus_console_init Console: base 3ffcf0, buf 
3fbce8, size 16384
[  156.131866] brcmfmac: CONSOLE: 00.000 initvars_cis_pci: Not CIS format
[  156.131898] brcmfmac: CONSOLE: 00.000 srom rev:0
[  156.131940] brcmfmac: CONSOLE: 00.000 initvars_srom_pci, SROM CRC Error
[  156.131979] brcmfmac: CONSOLE: 00.000 Setting clocks to 800/400/200
[  156.132032] brcmfmac: CONSOLE: 00.000 si_set_bb_vcofreq_frac: only work 
on 4360, 4350
[  156.132061] brcmfmac: CONSOLE: 00.000 Enabling D-cache
[  156.132095] brcmfmac: CONSOLE: 026738.568 gic_dist_init max_irq 64
[  156.132143] brcmfmac: CONSOLE: 026738.569 c_init: Watchdog reset bit set, 
clearing
[  156.132157] brcmfmac: CONSOLE: 026738.569 
[  156.132228] brcmfmac: CONSOLE: RTE (PCIE-MSG_BUF) 10.10.69.3309 (r610991) on 
BCM4366 r3 @ 40.0/200.0/800.0MHz
[  156.132286] brcmfmac: CONSOLE: 026738.569 nvram_init: called again without 
calling nvram_exit()
[  156.132327] brcmfmac: CONSOLE: 026738.569 initvars_cis_pci: Not CIS format
[  156.132349] brcmfmac: CONSOLE: 026738.601 srom rev:0
[  156.132391] brcmfmac: CONSOLE: 026738.601 initvars_srom_pci, SROM CRC Error
[  156.132438] brcmfmac: CONSOLE: 026738.601 allocating a max of 511 rxcplid 
buffers
[  156.132486] brcmfmac: CONSOLE: 026738.601 pciemsgbuf0: Broadcom PCIE MSGBUF 
driver
[  156.132543] brcmfmac: CONSOLE: 026738.601 nvram_init: called again without 
calling nvram_exit()
[  156.132584] brcmfmac: CONSOLE: 026738.601 initvars_cis_pci: Not CIS format
[  156.132606] brcmfmac: CONSOLE: 026738.634 srom rev:0
[  156.132649] brcmfmac: CONSOLE: 026738.634 initvars_srom_pci, SROM CRC Error
[  156.132699] brcmfmac: CONSOLE: 026738.634 wlc_ucode_download: wl0: Loading 
non-MU ucode
[  156.132755] brcmfmac: CONSOLE: 026738.634 reclaim section 0: Returned 216 
bytes to the heap
[  156.132795] brcmfmac: CONSOLE: 026738.634 initvars_cis_pci: Not CIS format
[  156.132819] brcmfmac: CONSOLE: 026738.667 srom rev:0
[  156.132860] brcmfmac: CONSOLE: 026738.667 initvars_srom_pci, SROM CRC Error
[  156.132909] brcmfmac: CONSOLE: 026738.667 wlc_bmac_attach, deviceid 0x43c4 
nbands 1
[  156.132969] brcmfmac: CONSOLE: 026738.672 ipxotp_init: mapping otpbase at 
0x18007000 to 0x18007000
[  156.133076] brcmfmac: CONSOLE: 026738.673 wl0: wlc_bmac_attach: chiprev 3 
corerev 64 cccap 0x5849 maccap 0xf0018705 band 2.4G, phy_type 11 phy_rev 32
[  156.133135] brcmfmac: CONSOLE: 026738.673 enable 1: q0 frmcnt 0, wrdcnt 0, 
q1 frmcnt 0, wrdcnt 0
[  156.133194] brcmfmac: CONSOLE: 026738.673 enable 1: q0 frmcnt 0, wrdcnt 0, 
q1 frmcnt 0, wrdcnt 0
[  156.133243] brcmfmac: CONSOLE: 026738.674 wl0: wlc_stf_txcore_shmem_write: 
No clock

Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()

2016-03-23 Thread Grumbach, Emmanuel



On 03/19/2016 07:15 AM, Eva Rachel Retuya wrote:
> Use alloc_ordered_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is 
> scheduled
> for removal.
> 
> There are work items doing related operations that shouldn't be swapped when
> queued in a certain order hence preserve the strict execution ordering of a
> single threaded (ST) workqueue by switching to alloc_ordered_workqueue().
> 
> WQ_MEM_RECLAIM flag is not needed since the worker is not depended
> during memory reclaim.
> 
> Signed-off-by: Eva Rachel Retuya 
> Acked-by: Tejun Heo 
> ---


Applied - thanks.
--
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] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

2016-03-23 Thread Michal Kazior

On 23 March 2016 at 01:14, Peter Oh <p...@codeaurora.org> wrote:
>
> On 03/22/2016 04:14 PM, kbuild test robot wrote:
>>
>> Hi Peter,
>>
>> [auto build test WARNING on wireless-drivers-next/master]
>> [also build test WARNING on v4.5 next-20160322]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improving the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Peter-Oh/ath10k-parse-Rx-MAC-timestamp-in-mgmt-frame-for-FW-10-4/20160323-064843
>> base:
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
>> master
>> config: x86_64-randconfig-x000-201612 (attached as .config)
>> reproduce:
>>  # save the attached .config to linux build tree
>>  make ARCH=x86_64
>>
>> All warnings (new ones prefixed by >>):
>>
>> In file included from include/linux/linkage.h:4:0,
>>  from include/linux/kernel.h:6,
>>  from include/linux/skbuff.h:17,
>>  from drivers/net/wireless/ath/ath10k/wmi.c:18:
>> drivers/net/wireless/ath/ath10k/wmi.c: In function
>> 'ath10k_wmi_10_4_op_pull_mgmt_rx_ev':
>> drivers/net/wireless/ath/ath10k/wmi.c:2236:33: error:
>> 'WMI_RX_STATUS_EXT_INFO' undeclared (first use in this function)
>
> it seems the warning is false report. I could see WMI_RX_STATUS_EXT_INFO is
> defined in wmi.h.
> Moreover this check command doesn't claim any warning/error make
> M=drivers/net/wireless/ath/ath10k C=2 CF="-D__CHECK_ENDIAN__"

I think the problem here is buildbot tested your patch against
wireless-drivers-next tree which doesn't include the macro yet. The
macro is in ath.git though.


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: Problem with brcmfmac removing extra interface

Re: [1/2] bcma: fix building without OF_IRQ

Re: rtlwifi: fix gcc-6 indentation warning

Re: b43: Fix memory leaks in b43_bus_dev_ssb_init andb43_bus_dev_bcma_init

Re: [PATCH 2/2] wil6210: add module parameter for alternate interface name

Re: [Y2038] [PATCH v2] prism54: isl_38xx: Replace 'struct timeval'

RE: [PATCH v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

Re: [PATCH v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

Re: [PATCH v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

Mapping the mac80211 TX path

[PATCH 1/2] staging: wilc1000: use completion instead of struct semaphore hif_sema_thread

[PATCH 2/2] staging: wilc1000: use completion instead of struct semaphore hif_sema_driver

Re: [PATCH] ath10k: fix null deref if device crashes early

Re: [PATCH 0/2] ath10k: fix tx hangs

Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom, ath10k.txt

Re: [PATCH 0/3] ath10k: add calibration data download support for qca4019

Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt

Amministratore di sistema

Re: Problem with brcmfmac removing extra interface

WMM vs QoS

Re: Problem with brcmfmac removing extra interface

Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()

Re: [PATCH v2] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

23 matches

Site Navigation

Mail list logo

Footer information