Delivery notification..(View the attachment for confirmation of your delivery address)

[FedEx Courier Service]

FedEx-Delivery Post.docx
Description: MS-Word 2007 document

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

[Yeoh Chun-Yeow]

>> I just take another look on your patch:
>>
>> @@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct
>> ieee80211_sub_if_data *sdata, }
>>
>> if (!(mpath->flags & MESH_PATH_RESOLVING))
>> - mesh_queue_preq(mpath, PREQ_Q_F_START);
>> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
>>
>> if (skb_queue_len(>frame_queue) >= MESH_FRAME_QUEUE_LEN)
>> skb_to_free = skb_dequeue(>frame_queue);
>>
>> You modification is intended to add this "immediate" PREQ generation
>> whenever the data frame is transmitted. In case the current path is
>> indeed the best one, the PREQ will still generate without waiting for
>> dot11MeshHWMPpreqMinInterval. The network is unnecessary flooded with
>> PREQ.
>
> To my understanding, if you already have a path established, it will not send 
> a new PREQ (as it's not in RESOLVING state)

The mesh path is in resolving state means that the mesh STA has just
triggered the discovery process. It sends out a PREQ and waits for
PREP from your destined mesh STA. After receiving the PREP, the path
is established and in active state. Then, the mesh STA is allowed to
send another PREQ but limited by the dot11MeshHWMPpreqMinInterval.

> So if the current path is the best, no excessive PREQ frames will be sent.

Your patch is indeed allowed the mesh STA with on-going data
transmission to send PREQ immediately no matter whether the path is
already a best path or not.

> In case the path is cleared, due to peer removal as described before.

For your case, it happens to you that the leaving mesh STA is the one
used for constructing the best path. So you want a quick PREQ to
re-construct it back.

>
> The test use case is simple, and from our tests the impact on performance big 
> related to our expectation,
> I assume the question is, what are the performance expectations/requirements 
> from the 802.11s mesh network ?

You specified your test case, nothing wrong. But there is other use
cases that we don't really need the "immediate" PREQ and indeed would
like to limit by dot11MeshHWMPpreqMinInterval.

Moving forward, I would suggest that a patch to turn it on or off with
comments saying that turning this on may consume more airtime due to
the overhead of broadcast PREQ no longer limited by
dot11MeshHWMPpreqMinInterval and this feature is by default off.

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

[GIT] [4.8] NFC update

[Samuel Ortiz]

Hi David,

This is the first NFC pull request for 4.8. We have:

- A fairly large NFC digital stack patchset:
  * RTOX fixes.
  * Proper DEP RWT support.
  * ACK and NACK PDUs handling fixes, in both initiator
and target modes.
  * A few memory leak fixes.

- A conversion of the nfcsim driver to use the digital stack.
  The driver supports the DEP protocol in both NFC-A and NFC-F.

- Error injection through debugfs for the nfcsim driver.

- Improvements to the port100 driver for the Sony USB chipset, in
  particular to the command abort and cancellation code paths.

- A few minor fixes for the pn533, trf7970a and fdp drivers.

The following changes since commit 8186f6e382d8719d0a4bc0ef218c4dd7cf55b496:

  net-next: mediatek: fix compile error inside mtk_poll_controller() 
(2016-07-02 15:22:29 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.8-1

for you to fetch changes up to 2a0fe4fe5bf2a6e2277354e7e8f369a20d881891:

  NFC: nfcsim: Simulate lost frames through debugfs entry (2016-07-19 23:24:49 
+0200)


Colin Ian King (1):
  NFC: set info->ram_patch to NULL when it is released

Dan Carpenter (1):
  NFC: pn533: double free on error in probe()

Denys Vlasenko (1):
  NFC: hci: delete unused nfc_llc_get_rx_head_tail_room()

Geert Uytterhoeven (1):
  NFC: fdp: Detect errors from fdp_nci_create_conn()

Geoff Lansberry (1):
  NFC: trf7970a: add TI recommended write of zero to Register 0x18

Thierry Escande (26):
  NFC: port100: Explicitly set NFC-F framing for NFC-DEP
  NFC: digital: Add a delay between poll cycles
  NFC: llcp: Use dynamic debug for hex dump
  NFC: nfcsim: Make use of the Digital layer
  NFC: llcp: Fix usage of llcp_add_tlv()
  NFC: llcp: Fix 2 memory leaks
  NFC: port100: Don't send a new command if one is still pending
  NFC: port100: Fix the command cancellation process
  NFC: port100: Make port100_abort_cmd() synchronous
  NFC: port100: Abort current command before switching RF off
  NFC: nfcsim: Fix missing dependency on NFC_DIGITAL
  NFC: digital: Fix a memory leak in NFC-F listening mode
  NFC: digital: Rework error handling in DEP_RES response
  NFC: digital: Call pending command callbacks at device unregister
  NFC: digital: Set the command pending flag
  NFC: digital: Abort last command when dep link goes down
  NFC: digital: Fix handling of saved PDU sk_buff pointers
  NFC: digital: Remove useless call to skb_reserve()
  NFC: digital: Fix target DEP_REQ I-PDU handling after ATN PDU
  NFC: digital: Fix ACK & NACK PDUs handling in target mode
  NFC: digital: Rework ACK PDU handling in initiator mode
  NFC: digital: Free supervisor PDUs
  NFC: digital: Add support for NFC DEP Response Waiting Time
  NFC: digital: Fix RTOX supervisor PDU handling
  NFC: nfcsim: Add support for sysfs control entry
  NFC: nfcsim: Simulate lost frames through debugfs entry

 drivers/nfc/Kconfig  |   1 +
 drivers/nfc/fdp/fdp.c|   6 +-
 drivers/nfc/nfcsim.c | 643 ---
 drivers/nfc/pn533/usb.c  |   9 +-
 drivers/nfc/port100.c|  82 +-
 drivers/nfc/trf7970a.c   |   4 +
 include/net/nfc/digital.h|   4 +-
 include/net/nfc/llc.h|   4 -
 net/nfc/digital_core.c   |  28 +-
 net/nfc/digital_dep.c| 316 ++---
 net/nfc/digital_technology.c |  11 +-
 net/nfc/hci/llc.c|  17 +-
 net/nfc/llcp_commands.c  |  23 +-
 net/nfc/llcp_core.c  |   9 +-
 14 files changed, 648 insertions(+), 509 deletions(-)
--
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 connecting to wifi on libertas_cpio (sd8686)

[Christopher Williamson]

I used NetworkManager in the previous test.

This time around I have used wpa_supplicant directly and get the
following results:

http://termbin.com/j8ea

Thought I’d throw them on a pastebin since it’s over 700 lines.

Christopher Williamson




On 20 July 2016 at 22:50:34, Dan Williams
(d...@redhat.com(mailto:d...@redhat.com)) wrote:

> On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > Hi Dan,
> >
> > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now
> > built that and dmesg is a much more lively place!
> >
> > I’ve provided output logs for both when the device is connected and
> > when a connection attempt is made - hopefully this is useful.
>
>
>
> The card is scanning and only finds 'shaunthesheep' 20 seconds after
> you "connect for the first time". The logs stop 3 seconds later. Are
> you connecting with wicd or something else?
>
> Can you run wpa_supplicant with the "-dddtu" option so we can get debug
> log output from it?
>
> Dan
--
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 connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> Hi Dan,
> 
> Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now
> built that and dmesg is a much more lively place!
> 
> I’ve provided output logs for both when the device is connected and
> when a connection attempt is made - hopefully this is useful.



The card is scanning and only finds 'shaunthesheep' 20 seconds after
you "connect for the first time".  The logs stop 3 seconds later.  Are
you connecting with wicd or something else?

Can you run wpa_supplicant with the "-dddtu" option so we can get debug
log output from it?

Dan
--
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 connecting to wifi on libertas_cpio (sd8686)

[Christopher Williamson]

Hi Dan,

Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now
built that and dmesg is a much more lively place!

I’ve provided output logs for both when the device is connected and
when a connection attempt is made - hopefully this is useful.

When I first connect the device:
root@nano:~# dmesg |grep libertas
[ 80.432144] libertas: module verification failed: signature and/or
required key missing - tainting kernel
[ 80.434563] libertas enter: lbs_init_module()
[ 80.434600] libertas leave: lbs_init_module()
[ 80.457044] libertas_sdio: Libertas SDIO driver
[ 80.457062] libertas_sdio: Copyright Pierre Ossman
[ 80.457782] libertas enter: lbs_add_card()
[ 80.457801] libertas enter: lbs_cfg_alloc()
[ 80.457875] libertas leave: lbs_cfg_alloc()
[ 80.457890] libertas enter: lbs_init_adapter()
[ 80.457905] libertas enter: lbs_allocate_cmd_buffer()
[ 80.458005] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458022] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458034] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458047] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458058] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458072] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458083] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458098] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458110] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458124] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458137] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458151] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458164] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458179] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458191] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458205] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458216] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458231] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458244] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 80.458259] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 80.458273] libertas leave: lbs_allocate_cmd_buffer(), ret 0
[ 80.458290] libertas leave: lbs_init_adapter(), ret 0
[ 80.458333] libertas thread: Starting main thread...
[ 80.458766] libertas enter: lbs_thread()
[ 80.458785] libertas thread: 1: currenttxskb (null), dnld_sent 0
[ 80.458802] libertas thread: sleeping, connect_status 1, psmode 0, psstate 0
[ 80.458870] libertas leave: lbs_add_card(), priv f6700420
[ 81.020863] libertas enter: lbs_start_card()
[ 81.020880] libertas enter: lbs_update_hw_spec()
[ 81.020890] libertas enter: __lbs_cmd()
[ 81.020898] libertas enter: __lbs_cmd_async()
[ 81.020906] libertas enter: lbs_get_free_cmd_node()
[ 81.020915] libertas leave: lbs_get_free_cmd_node()
[ 81.020924] libertas host: PREP_CMD: command 0x0003
[ 81.020931] libertas enter: lbs_queue_cmd()
[ 81.020941] libertas host: QUEUE_CMD: inserted command 0x0003 into cmdpendingq
[ 81.020948] libertas leave: lbs_queue_cmd()
[ 81.020976] libertas leave: __lbs_cmd_async(), ret f64fc000
[ 81.021001] libertas thread: 2: currenttxskb (null), dnld_send 0
[ 81.021014] libertas thread: 3: currenttxskb (null), dnld_sent 0
[ 81.021023] libertas thread: 4: currenttxskb (null), dnld_sent 0
[ 81.021032] libertas enter: lbs_execute_next_command()
[ 81.021041] libertas host: EXEC_NEXT_CMD: sending command 0x0003
[ 81.021049] libertas enter: lbs_submit_command()
[ 81.021059] libertas cmd: DNLD_CMD: command 0x0003, seq 1, size 46
[ 81.021089] libertas leave: lbs_submit_command()
[ 81.021098] libertas leave: lbs_execute_next_command()
[ 81.021107] libertas thread: 1: currenttxskb (null), dnld_sent 2
[ 81.021117] libertas thread: sleeping, connect_status 1, psmode 0, psstate 0
[ 81.021443] libertas enter: lbs_host_to_card_done()
[ 81.021454] libertas leave: lbs_host_to_card_done()
[ 81.021763] libertas enter: lbs_notify_command_response()
[ 81.021786] libertas leave: lbs_notify_command_response()
[ 81.021799] libertas thread: 2: currenttxskb (null), dnld_send 0
[ 81.021809] libertas thread: 3: currenttxskb (null), dnld_sent 0
[ 81.021818] libertas thread: 4: currenttxskb (null), dnld_sent 0
[ 81.021830] libertas enter: lbs_process_command_response()
[ 81.021846] libertas cmd: CMD_RESP: response 0x8003, seq 1, size 46
[ 81.021869] libertas leave: lbs_process_command_response(), ret 0
[ 81.021879] libertas enter: __lbs_cleanup_and_insert_cmd()
[ 81.021888] libertas leave: __lbs_cleanup_and_insert_cmd()
[ 81.021897] libertas leave: __lbs_cmd(), ret 0
[ 81.021908] libertas enter: lbs_execute_next_command()
[ 81.021922] libertas_sdio mmc1:0001:1 (unnamed net_device)
(uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x0303
[ 81.021932] libertas cmd: GET_HW_SPEC: hardware interface 0x2,
hardware spec 0x0011
[ 81.021941] libertas leave: lbs_update_hw_spec()
[ 81.021949] libertas enter: lbs_get_tx_power()
[ 81.021957] libertas enter: __lbs_cmd()
[ 81.021965] libertas enter: __lbs_cmd_async()
[ 81.021973] 

Re: linux-next: build warning after merge of the wireless-drivers-next tree

[Kalle Valo]

"Reizer, Eyal"  writes:

>> After merging the wireless-drivers-next tree, today's linux-next build
>> (x86_64 allmodconfig) produced this warning:
>> 
>> drivers/net/wireless/ti/wlcore/spi.c: In function 'wlcore_probe_of':
>> drivers/net/wireless/ti/wlcore/spi.c:457:6: warning: unused variable 'ret' [-
>> Wunused-variable]
>>   int ret;
>>   ^
>> 
>> Introduced by commit
>> 
>>   01efe65aba65 ("wlcore: spi: add wl18xx support")
>
> Of course you are right. It is indeed redundant now. Don't know how I
>have missed it. Don't remember seeing a warning from the tool chain I
>have used. Anyway ,will submit an amended patch soon.
 
I didn't notice it either as I didn't have CONFIG_WLCORE_SPI enabled.
But what's odd is that kbuild didn't report anything, it's usually quite
good to catch warnings like this.

Anyway, I have pushed the fix to wireless-drivers-next:

cb6a11518850 wlcore: spi: fix build warning caused by redundant variable

-- 
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: linux-next: build failure after merge of the wireless-drivers-next tree

[Kalle Valo]

Brian Norris  writes:

> Just to head this off, since I noticed it...
>
> On Tue, Jul 19, 2016 at 05:08:59PM +0300, Kalle Valo wrote:
>> Rafał Miłecki  writes:
>> > I sent a patch seconds ago, you may just take a look at it. If you
>> > still prefer to revert my commit, go ahead.
>> 
>> Ok, let's try your fix. We still have few days. I applied the patch[1]
>> to the pending branch this morning and if I don't see any errors I apply
>> it later tonight and hopefully it will be in tomorrow's linux-next
>> build. Thanks for the quick fix, very much appreciated.
>> 
>> [1] "mtd: add arch dependency for MTD_BCM47XXSFLASH symbol"
>> https://patchwork.kernel.org/patch/9236053/
>
> I applied a trivial change to this same Kconfig entry:
>
> Subject: mtd: update description of MTD_BCM47XXSFLASH symbol
> http://git.infradead.org/l2-mtd.git/commitdiff/0a526341fee054c1e2b9f0e4b2b424ae81707d4c
>
> It's a trivial conflict, so should we just let Linus work it out? I can
> note it my MTD pull request, if wireless lands first.

Sounds good to me. Do note that Linus doesn't pull wireless-drivers-next
directly, it goes through net-next. But I'll let Dave also know about
this when I send him the pull request.

-- 
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] wlcore: spi: fix build warning caused by redundant variable

[Kalle Valo]

"Reizer, Eyal"  writes:

> The ret variable is unused in wlcore_probe_of()
> Remove it for fixing build warning.
>
> Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support")
> Signed-off-by: Eyal Reizer 

Applied to wireless-drivers-next, 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 v2 2/3] mac80211: mesh: improve path resolving time

[Machani, Yaniv]

On Wed, Jul 20, 2016 at 19:40:53, Yeoh Chun-Yeow wrote:
> Johannes Berg
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving 
> time
> 
 >
> 
> In case that you have additional 1 node with 3 paths toward the 
> destination (instead of 2 paths like you illustrated), forcing 
> additional PREQ doesn't guarantee that you will switch to the fixed path in 
> your "next" attempt.
>

I'm not trying to guarantee a specific path, just build a path without waiting 
the MinInterval
  
> I just take another look on your patch:
> 
> @@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct 
> ieee80211_sub_if_data *sdata, }
> 
> if (!(mpath->flags & MESH_PATH_RESOLVING))
> - mesh_queue_preq(mpath, PREQ_Q_F_START);
> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
> 
> if (skb_queue_len(>frame_queue) >= MESH_FRAME_QUEUE_LEN) 
> skb_to_free = skb_dequeue(>frame_queue);
> 
> You modification is intended to add this "immediate" PREQ generation 
> whenever the data frame is transmitted. In case the current path is 
> indeed the best one, the PREQ will still generate without waiting for 
> dot11MeshHWMPpreqMinInterval. The network is unnecessary flooded with 
> PREQ.

To my understanding, if you already have a path established, it will not send a 
new PREQ (as it's not in RESOLVING state)
So if the current path is the best, no excessive PREQ frames will be sent.
In case the path is cleared, due to peer removal as described before.

The test use case is simple, and from our tests the impact on performance big 
related to our expectation,
I assume the question is, what are the performance expectations/requirements 
from the 802.11s mesh network ?

Regards,
Yaniv

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Wed, 2016-07-20 at 02:53 -0700, Christopher Williamson wrote:
> Just following up from my previous email:
> 
> I am actually setting the reg domain using: iw reg set GB
> (copy/pasted
> the IN from elsewhere - oops!)
> 
> As for progress, however, I have tried the following:
> 
> - setting the debug level to 0xfff. This still produces no
> additional output even with 8 set in printk.

Yeah, looks like you'd need to rebuild the libertas driver with
CONFIG_LIBERTAS_DEBUG set.  Or just #define that to 1 in defs.h.  Is
that something you could do?

Dan

> - removing the v9 firmware - same result as before - system fully
> locks up.
> 
> - disabling ipv6 - gets rid of IPv6 interface not up warning but
> that’s not causing any problems and this didn’t make any difference.
> 
> It doesn’t seem to matter what I try at the moment - all attempts to
> connect result in the system crashing which I guess is better than it
> just asking me for a password over and over - it looks like it is
> attempting association at this point which is good but I don’t know
> why the box is crashing out and dmesg -w doesn’t show any additional
> output before the freeze.
> 
> If anyone has any more ideas I would be more than happy to try them!
> Thanks for the help so far Dan!
> 
> Christopher Williamson
> 
> On 19 July 2016 at 18:41:34, Christopher Williamson
> (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> 
> > 
> > So I’ve now disabled IPv6 and have set the GB (Great Britain)
> > regulation code using:
> > 
> > iw reg set IN
> > 
> > Now when I try to connect to the network using wicd the system
> > seems to crash - I guess at least it’s doing something more than
> > just asking for the password again like it did with NetworkManager
> > but so far no further progress on getting this working properly.
> > 
> > Christopher Williamson
> > 
> > 
> > 
> > On 19 July 2016 at 18:03:16, Christopher Williamson (home@chrisaw.c
> > om(mailto:h...@chrisaw.com)) wrote:
> > 
> > > 
> > > Absolutely!
> > > 
> > > With the debug logging enabled I got the following:
> > > 
> > > Connecting the device initially with debug enabled:
> > > 
> > > [ 205.302685] libertas_sdio: Libertas SDIO driver
> > > [ 205.302698] libertas_sdio: Copyright Pierre Ossman
> > > [ 205.503465] cfg80211: World regulatory domain updated:
> > > [ 205.503478] cfg80211: DFS Master region: unset
> > > [ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth),
> > > (max_antenna_gain, max_eirp), (dfs_cac_time)
> > > [ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503513] cfg80211: (517 KHz - 525 KHz @ 8 KHz,
> > > 16 KHz AUTO), (N/A, 2000 mBm), (N/A)
> > > [ 205.503522] cfg80211: (525 KHz - 533 KHz @ 8 KHz,
> > > 16 KHz AUTO), (N/A, 2000 mBm), (0 s)
> > > [ 205.503529] cfg80211: (549 KHz - 573 KHz @ 16 KHz),
> > > (N/A, 2000 mBm), (0 s)
> > > [ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503542] cfg80211: (5724 KHz - 6372 KHz @ 216
> > > KHz), (N/A, 0 mBm), (N/A)
> > > [ 212.249171] gma500 :00:02.0: Backlight lvds set brightness
> > > 7a127a12
> > > [ 212.324898] mmc1: new SDIO card at address 0001
> > > [ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device)
> > > (uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x0303
> > > [ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device)
> > > (uninitialized): PREP_CMD: command 0x00a3 failed: 2
> > > [ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN
> > > 802.11 adapter
> > > [ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > > 
> > > 
> > > Strangely when I attempt to connect to the WiFi network I’m using
> > > the only error I get is:
> > > 
> > > [ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > > 
> > > I was expecting more output and am guessing I’ve missed something
> > > here.
> > > 
> > > Christopher Williamson
> > > 
> > > On 19 July 2016 at 17:38:35, Dan Williams (d...@redhat.com(mailto
> > > :d...@redhat.com)) wrote:
> > > 
> > > > 
> > > > On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson
> > > > wrote:
> > > > > 
> > > > > Hi everyone!
> > > > > 
> > > > > I’ve just got myself a Viliv N5 and am trying to get the
> > > > > integrated
> > > > > Wifi chipset working on it.
> > > > > 
> > > > > I am able to see networks around me but any attempts to
> > > > > connect them
> > > > > appear to time out and fail.
> > > > > 
> > > > > I have filed a linux kernel bug related to this issue:
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=135421goo
> > > > > 
> > > > > I figured here may be a good place to ask about it and
> > > > > hopefully to
> > > > > get to the 

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

[Yeoh Chun-Yeow]

On Wed, Jul 20, 2016 at 8:15 PM, Machani, Yaniv  wrote:
>
> On Wed, Jul 20, 2016 at 09:45:16, Yeoh Chun-Yeow wrote:
> > Johannes Berg
> > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> > time
> >
> > On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv  wrote:
> > > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote:
> > >> Johannes Berg
> > >> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> > >> time
> > >>
> > >> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland 
> > >> wrote:
> > >> > On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv wrote:
> > >> >> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> > >> >
> > >> > This wording seems to indicate that it is not per path.  Perhaps
> > >> > this should be clarified in the standard.  (If the intent turns
> > >> > out to be per path, then I guess we should fix it by storing
> > >> > last_preq per path
> > >> > instead.)
> > >> >
> > >> >
> > >> > Ignoring the standard for a second, let's explore this: can you
> > >> > give some idea on how many stations are in your target network,
> > >> > how frequently a given pair of nodes unpeer, what sort of
> > >> > improvements you see with the patch?  It should then be pretty
> > >> > easy to run some simulations to see the scenarios where this helps and 
> > >> > where it hurts.
> > >> >
> > >>
> > >
> > > Bob, Chun-Yeow,
> > > Thanks for your inputs.
> > >
> > > Let take a simple scenario, where you have a,b,c,d nodes connected
> > > to each
> > other as shown below.
> > >
> > > A~ ~ C- - - D
> > >\  /
> > >   \ /
> > >  B
> > >
> > > A would like to pass data to D.
> > > A-C matric is worse than A-B-C, so path is constructed via B.
> > > We are in idle state, and PREQ are sent every
> > dot11MeshHWMPpreqMinInterval.
> > > Now, node B have been disconnected (ran out of battery/shut
> > > down/suddenly went out of range) As A has a path to D via B, he
> > > cleans up his
> > path table.
> > > Now he needs to build a new path, in the WCS, he have just sent a PREQ.
> > > And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until
> > he can rebuild the path.
> >
> > Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it
> > produces positive impact to your network? Once the path to A - C - D
> > has established, it needs to wait till the active path timer to expire
> > before establishing a new path. This active path time is default to
> > 5000 TUs (or 5s).
> >
>
> We did tried it as well, but again, this will cause us sending PREQ more 
> frequently.
>
> > > As we wouldn't like to flood the network with PREQ, we can assume
> > > that the
> > dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un-
> > acceptable.
> > >
> >
> > But your patch is indeed generating "more" PREQ frame.
> >
> Well, we are sending more, but just in a specific scenario where it's needed 
> ASAP to establish a path.
>
> > > In cases where you need to have a reliable data link, passing
> > > audio/video you
> > usually can't afford few seconds w/o traffic.
> > >
> > >> In addition to Bob's comment, you probably can try to reduce the
> > >> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
> > >> default value 10 TUs. Besides, you can also reduce the
> > >> mesh_path_refresh_time which is currently default to 1000 ms and
> > >> check whether you can improve on your network scenarios.
> > >>
> > >
> > > We did tried to play with these values, but again, we don't want to
> > > flood the
> > network.
> > > We just want to recover ASAP.
> > >
> > >> When you mentioned "next hop peer disconnect", it could also be the
> > >> time taken to re-established the mesh peering before your mesh STA
> > >> can transmit the data to your peer mesh STA.
> > >>
> > >
> > > Link establishment takes no more than few 100s of ms usually, And in
> > > the example above, there is no new link establishment, just path 
> > > generation.
> > >
> >
> > Suggest that you simulate your scenario and validate the improvement first.
> >
>
> We have made many lab tests, with 10s of nodes in open air and in a 
> controlled environment.
> This patch is just one of the improvements we saw necessary for performance, 
> we have multiple others for the metric calculation, and more.
> We understand that the HWMP and the general mesh implementation is more 
> sensor network related, where there is no need for stable high throughput 
> 100% of the time.
> You can also have a look in our white paper, describing small parts of the 
> tests we have made in the last section - 
> http://www.ti.com/lit/wp/swry024/swry024.pdf
>

In case that you have additional 1 node with 3 paths toward the
destination (instead of 2 paths like you illustrated), forcing
additional PREQ doesn't guarantee that you will switch to the fixed
path in your "next" attempt.

I just take another look on your patch:

@@ -1110,7 +1117,7 @@ 

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Arnd Bergmann]

On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> Arnd Bergmann  writes:
> > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> >> Arnd Bergmann  writes:
> >> Well it really all depends on how much time I have and how much others
> >> step up and help contribute to the code. For rtl8xxxu my plans are as
> >> follows:
> >> 
> >> 1) rtl8188eu support, since this is the most widely distributed USB
> >> dongle which isn't currently supported by a non staging driver. I am
> >> currently working on this together with Andrea Merello.
> >
> > Ok, cool.
> >
> >> 2) Beacon support for IBSS and AP mode - hopefully this should make it
> >> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
> >> them in rtlwifi.
> >
> > Do we have any indication that those two actually work in rtlwifi at the
> > moment? My experience seems to match the recommendations for all the
> > raspberry pi users that use yet another (worse looking) driver:
> >
> > https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56
> 
> I am not really authoritative on that one. I tried it in station mode
> and it didn't work well for me. I never played with AP mode - It may
> work better in IBSS or AP mode than it does in station mode. I don't
> like to pull the rug away under people, which is why I haven't pushed
> for this.

Right. Then again, for AP mode, all information on the web indicates
similar problems, recommending the out-of-tree driver and a custom
hostap fork:

https://bogeskov.dk/UsbAccessPoint.html

> > throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets
> > 5mbit/s on the same network, but I guess that doesn't really mean much
> > as long as I have problems with the infrastructure.
> 
>  Note the rtl8xxxu driver doesn't report speeds properly to
> NetworkMangler or 'iw' as the API for this relies on confirmed TX
> speeds, and I only have an easy way of retrieving RX speeds from the RTL
> device. The vendor driver probably fakes it.

This was the rx speed I got from downloading a file from a known server.
With the rtl8192cu driver, I could get no connection at all today,
and when I last tried, it stopped working after a few minutes at best.

> > This one:
> > Bus 001 Device 033: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU
> > 802.11n WLAN Adapter
> >
> > I bought the rtl8188su a while ago, while the rtl8188cus (0bda:8176)
> > is from this year. According to https://wikidevi.com/wiki/Realtek, it
> > seems to be one year older than the rtl8188cus and was almost as common
> > in its day. Apparently everyone that used to make ...su device replaced it
> > with a ...cu or the newer ...eu chips and that is all you can buy these days
> > on the low end.
> 
> Gotcha, 8188su is the 1x1 version of it. I do have a 8192su in the
> drawer somewhere, but the TODO list is a bit long already 

Yes, I was just agreeing here that it's not worth doing that one.
As far as I can see, the evolution of these devices is

RTL81xxU (2008)
RTL81xxSU (2009)
RTL81xxCU (2010)
RTL81xxEU (2013)

Clearly there is no use working on the older ones before the latest
ones work well.

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 2/3] staging/rtl8192e: use s8 instead of char

[Christian Lamparter]

On Wednesday, July 20, 2016 5:06:27 PM CEST Xose Vazquez Perez wrote:
> Arnd Bergmann  wrote:
> 
> > rtlwifi, but I found the older r8712u device to work fine with
> > the staging/rtl8712 driver.
> 
> A replacement for "staging/rtl8712", with MAC80211 support, is
> available at: https://github.com/chunkeey/rtl8192su
> 
> Also a fullmac/cfg80211 driver(r92su) is available at the
> same repository.
> 
Yes, it has its problems. The rtl8712/r92su isn't really
a fullmac device. While the MLME (scan, probe, auth, assoc) is
done by the firmware. The 802.11 frame creation (from 802.3)
frames needs to be done by the driver. The rtl8712 firmware
however has its fair share of issues. Like: no support for
(tx) fragmentation and ERP is a mystery too. monitor 
mode is barely working and limited to 20Mhz wide channels.
There's also limited tx injection support and of course
stability issues (just like with the staging/rtl8712 driver
or FreeBSD's rsu driver).

The rtl8192su driver (based on rtlwifi) in the same repository
has proper fragmentation support. But it uses the firmware from
the windows/mac os x driver, which is similar to rtl8192se softmac
firmware in design. Getting it to work properly in station mode
however either needs "some magic" or help from Realtek's USB group...


--
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 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

[Jes Sorensen]

Arnd Bergmann  writes:
> There is one remaining warning about a type limit check in rtl8192e:
>
> staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true 
> due to limited range of data type [-Werror=type-limits]
>
> This changes a macro into a local function to clarify the types and simplify
> the check while removing the warning.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/rtl8192e/rtl819x_Qos.h| 3 ---
>  drivers/staging/rtl8192e/rtl819x_TSProc.c | 5 +
>  2 files changed, 5 insertions(+), 3 deletions(-)

Looks good to me!

Acked-by: Jes Sorensen 

> diff --git a/drivers/staging/rtl8192e/rtl819x_Qos.h 
> b/drivers/staging/rtl8192e/rtl819x_Qos.h
> index 463122db6d29..61da8f7475bb 100644
> --- a/drivers/staging/rtl8192e/rtl819x_Qos.h
> +++ b/drivers/staging/rtl8192e/rtl819x_Qos.h
> @@ -169,9 +169,6 @@ union qos_tclas {
>   } TYPE2_8021Q;
>  };
>  
> -#define IsACValid(ac)((ac >= 0 && ac <= 7) ? true : false)
> -
> -
>  union aci_aifsn {
>   u8  charData;
>  
> diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c 
> b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> index 2c8a526773ed..a966a8e490ab 100644
> --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> @@ -306,6 +306,11 @@ static void MakeTSEntry(struct ts_common_info 
> *pTsCommonInfo, u8 *Addr,
>   pTsCommonInfo->TClasNum = TCLAS_Num;
>  }
>  
> +static bool IsACValid(unsigned int tid)
> +{
> + return tid < 7;
> +}
> +
>  bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
>  u8 *Addr, u8 TID, enum tr_select TxRxSelect, bool bAddNewTs)
>  {
--
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/3] staging/rtl8192e: use s8 instead of char

[Jes Sorensen]

Arnd Bergmann  writes:
> On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> Arnd Bergmann  writes:
>> Well it really all depends on how much time I have and how much others
>> step up and help contribute to the code. For rtl8xxxu my plans are as
>> follows:
>> 
>> 1) rtl8188eu support, since this is the most widely distributed USB
>> dongle which isn't currently supported by a non staging driver. I am
>> currently working on this together with Andrea Merello.
>
> Ok, cool.
>
>> 2) Beacon support for IBSS and AP mode - hopefully this should make it
>> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
>> them in rtlwifi.
>
> Do we have any indication that those two actually work in rtlwifi at the
> moment? My experience seems to match the recommendations for all the
> raspberry pi users that use yet another (worse looking) driver:
>
> https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56

I am not really authoritative on that one. I tried it in station mode
and it didn't work well for me. I never played with AP mode - It may
work better in IBSS or AP mode than it does in station mode. I don't
like to pull the rug away under people, which is why I haven't pushed
for this.

>> > As one data point that I can provide (but you are probably
>> > aware of), I could never get my rtl8188cus stick to work with
>> > rtlwifi, but I found the older r8712u device to work fine with
>> > the staging/rtl8712 driver.
>> 
>> I'd love to hear if the rtl8188cus works better with rtl8xxxu.
>
> It took me far too long to get the driver running on my machine (all my 
> fault),
> but I've tested it now. Unfortunately there is something very wrong
> with my home wireless network at the moment, so I can only confirm
> that it doesn't work any worse than my Intel Wireless card on 2.4GHz,
> but that isn't any good (5GHz devices are fine, but that doesn't
> help on a 2.4GHz-only device).
>
> This is what I see in the kernel log
>
> [  773.862848] usb 2-1.2: new high-speed USB device number 8 using ehci-pci
> [  773.957415] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8176
> [ 773.957425] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [  773.957430] usb 2-1.2: Manufacturer: Realtek
> [  773.957433] usb 2-1.2: SerialNumber: 00e04c01
> [  774.115182] usb 2-1.2: Vendor: Realtek
> [  774.115192] usb 2-1.2: Product: 
> [  774.115199] usb 2-1.2: rtl8192cu_parse_efuse: dumping efuse (0x80 bytes):
> [  774.115206] usb 2-1.2: 00: 29 81 00 74 ed 00 00 00
> [  774.115212] usb 2-1.2: 08: ff 00 da 0b 76 81 01 41
> [  774.115219] usb 2-1.2: 10: 32 00 85 62 7e ad 5c f3
> [  774.115225] usb 2-1.2: 18: 70 15 9c b1 0a 03 52 65
> [  774.115231] usb 2-1.2: 20: 61 6c 74 65 6b 00 02 03
> [  774.115237] usb 2-1.2: 28: 00 00 00 00 00 00 00 00
> [  774.115242] usb 2-1.2: 30: 00 00 00 00 00 00 00 00
> [  774.115248] usb 2-1.2: 38: 00 00 00 00 00 00 00 00
> [  774.115254] usb 2-1.2: 40: 00 00 00 00 00 00 00 00
> [  774.115260] usb 2-1.2: 48: 00 00 00 00 00 00 00 00
> [  774.115265] usb 2-1.2: 50: 00 00 00 00 00 00 00 00
> [  774.115271] usb 2-1.2: 58: 06 00 2a 2a 2a 00 00 00
> [  774.115277] usb 2-1.2: 60: 2a 2a 2a 00 00 00 00 00
> [  774.115283] usb 2-1.2: 68: 00 00 00 00 04 04 04 00
> [  774.115289] usb 2-1.2: 70: 00 00 00 00 00 00 05 00
> [  774.115295] usb 2-1.2: 78: 10 00 00 00 36 00 00 00
> [ 774.115302] usb 2-1.2: RTL8188CU rev A (TSMC) 1T1R, TX queues 2,
> WiFi=1, BT=0, GPS=0, HI PA=0
> [  774.115308] usb 2-1.2: RTL8188CU MAC: 5c:f3:70:15:9c:b1
> [ 774.115314] usb 2-1.2: rtl8xxxu: Loading firmware
> rtlwifi/rtl8192cufw_TMSC.bin
> [  774.115409] usb 2-1.2: Firmware revision 80.0 (signature 0x88c1)
> [  775.692344] rtl8xxxu 2-1.2:1.0 wlan1: renamed from wlan0
> [  775.721151] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [  775.746653] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [  775.798780] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [  788.414618] wlan2: authenticate with 22:4e:7f:6f:5b:3c
> [  788.452485] wlan2: send auth to 22:4e:7f:6f:5b:3c (try 1/3)
> [  788.457926] wlan2: authenticated
> [  788.462261] wlan2: associate with 22:4e:7f:6f:5b:3c (try 1/3)
> [ 788.475159] wlan2: RX AssocResp from 22:4e:7f:6f:5b:3c (capab=0x431
> status=0 aid=1)
> [  788.504683] wlan2: associated

That all looks reasonable to me.

> throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets
> 5mbit/s on the same network, but I guess that doesn't really mean much
> as long as I have problems with the infrastructure.

:) Note the rtl8xxxu driver doesn't report speeds properly to
NetworkMangler or 'iw' as the API for this relies on confirmed TX
speeds, and I only have an easy way of retrieving RX speeds from the RTL
device. The vendor driver probably fakes it.

> rtl8xxxu  IEEE 802.11  ESSID:"openwrt24-ab"  
>   Mode:Managed  Frequency:2.462 GHz  Access Point: 22:4E:7F:6F:5B:3C  
>  
> 

[PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

[Arnd Bergmann]

There is one remaining warning about a type limit check in rtl8192e:

staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due 
to limited range of data type [-Werror=type-limits]

This changes a macro into a local function to clarify the types and simplify
the check while removing the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/rtl8192e/rtl819x_Qos.h| 3 ---
 drivers/staging/rtl8192e/rtl819x_TSProc.c | 5 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl819x_Qos.h 
b/drivers/staging/rtl8192e/rtl819x_Qos.h
index 463122db6d29..61da8f7475bb 100644
--- a/drivers/staging/rtl8192e/rtl819x_Qos.h
+++ b/drivers/staging/rtl8192e/rtl819x_Qos.h
@@ -169,9 +169,6 @@ union qos_tclas {
} TYPE2_8021Q;
 };
 
-#define IsACValid(ac)  ((ac >= 0 && ac <= 7) ? true : false)
-
-
 union aci_aifsn {
u8  charData;
 
diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c 
b/drivers/staging/rtl8192e/rtl819x_TSProc.c
index 2c8a526773ed..a966a8e490ab 100644
--- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
@@ -306,6 +306,11 @@ static void MakeTSEntry(struct ts_common_info 
*pTsCommonInfo, u8 *Addr,
pTsCommonInfo->TClasNum = TCLAS_Num;
 }
 
+static bool IsACValid(unsigned int tid)
+{
+   return tid < 7;
+}
+
 bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
   u8 *Addr, u8 TID, enum tr_select TxRxSelect, bool bAddNewTs)
 {
-- 
2.9.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

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Arnd Bergmann]

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.

staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always 
false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always 
false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false 
due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false 
due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false 
due to limited range of data type [-Werror=type-limits]

This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.

Signed-off-by: Arnd Bergmann 
Acked-by: Jes Sorensen 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 6 +++---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.h   | 8 
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index ba64a4f1b3a8..8d6bca61e7aa 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -1487,8 +1487,8 @@ static void _rtl92e_query_rxphystatus(
struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
-   char rx_pwr[4], rx_pwr_all = 0;
-   char rx_snrX, rx_evmX;
+   s8 rx_pwr[4], rx_pwr_all = 0;
+   s8 rx_snrX, rx_evmX;
u8 evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8 is_cck_rate = 0;
@@ -1613,7 +1613,7 @@ static void _rtl92e_query_rxphystatus(
 2) - 110;
 
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
-   rx_snrX = (char)(tmp_rxsnr);
+   rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
 
@@ -1643,7 +1643,7 @@ static void _rtl92e_query_rxphystatus(
 
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
-   rx_evmX = (char)(tmp_rxevm);
+   rx_evmX = (s8)(tmp_rxevm);
 
rx_evmX /= 2;
 
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
index 5e3bbe5c3ca4..0698131e4300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
@@ -630,7 +630,7 @@ void rtl92e_set_tx_power(struct net_device *dev, u8 channel)
 {
struct r8192_priv *priv = rtllib_priv(dev);
u8  powerlevel = 0, powerlevelOFDM24G = 0;
-   char ant_pwr_diff;
+   s8  ant_pwr_diff;
u32 u4RegValue;
 
if (priv->epromtype == EEPROM_93C46) {
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 13a5ddc2bea5..41e05f206300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1982,7 +1982,7 @@ void rtl92e_update_rx_statistics(struct r8192_priv *priv,
weighting) / 6;
 }
 
-u8 rtl92e_rx_db_to_percent(char antpower)
+u8 rtl92e_rx_db_to_percent(s8 antpower)
 {
if ((antpower <= -100) || (antpower >= 20))
return  0;
@@ -1993,9 +1993,9 @@ u8 rtl92e_rx_db_to_percent(char antpower)
 
 }  /* QueryRxPwrPercentage */
 
-u8 rtl92e_evm_db_to_percent(char value)
+u8 rtl92e_evm_db_to_percent(s8 value)
 {
-   char ret_val;
+   s8 ret_val;
 
ret_val = value;
 
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
index f627fdc15a58..6921125c9d35 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
@@ -503,8 +503,8 @@ struct r8192_priv {
u32 Pwr_Track;
u8 CCKPresentAttentuation_20Mdefault;
u8 CCKPresentAttentuation_40Mdefault;
-   char CCKPresentAttentuation_difference;
-   char CCKPresentAttentuation;
+   s8 CCKPresentAttentuation_difference;
+   s8 CCKPresentAttentuation;
long undecorated_smoothed_pwdb;
 
u32 MCSTxPowerLevelOriginalOffset[6];
@@ -604,8 +604,8 @@ void rtl92e_update_rx_pkt_timestamp(struct net_device *dev,
 long rtl92e_translate_to_dbm(struct r8192_priv *priv, u8 
signal_strength_index);
 void 

Re: TCP performance regression in mac80211 triggered by the fq code

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen  writes:

> Felix Fietkau  writes:
>
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>
> There's definitely something iffy about the hashing. Here's the output
> relevant line from the aqm debug file after running a single TCP stream
> for 60 seconds to that station:
>
> ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit 
> collisions
> tx-bytes tx-packets
> wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925
>
> (there are two extra fields here; I added per-txq CoDel stats, will send
> a patch later).
>
> This shows that the txq has 146 flows associated from that one TCP flow.
> Looking at this over time, it seems that each time the queue runs empty
> (which happens way too often, which is what I was originally
> investigating), another flow is assigned.
>
> Michal, any idea why? :)

And to answer this: because the flow is being freed to be reassigned
when it runs empty, but the counter is not decremented. Is this
deliberate? I.e. is the 'flows' var supposed to be a total 'new_flows'
counter and not a measure of the current number of assigned flows?

-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/3] staging/rtl8192u: use s8 instead of char

[Arnd Bergmann]

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.

staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due 
to limited range of data type [-Werror=type-limits]
staging/rtl8192u/r8192U_dm.c:646:50: error: comparison is always false due to 
limited range of data type [-Werror=type-limits]

This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.

Signed-off-by: Arnd Bergmann 
Acked-by: Jes Sorensen 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211.h |  4 ++--
 drivers/staging/rtl8192u/r8192U.h  |  4 ++--
 drivers/staging/rtl8192u/r8192U_core.c | 14 +++---
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 09e9499b7f9d..077ea13eb1e7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -746,7 +746,7 @@ struct ieee80211_rx_stats {
bool  bisrxaggrsubframe;
bool  bPacketBeacon;//cosa add for rssi
bool  bToSelfBA;//cosa add for rssi
-   char  cck_adc_pwdb[4];  //cosa add for rx path selection
+   s8cck_adc_pwdb[4];  //cosa add for rx path selection
u16   Seq_Num;
 
 };
@@ -1814,7 +1814,7 @@ struct ieee80211_device {
u32 wpax_type_notify; //{added by David, 2006.9.26}
 
/* QoS related flag */
-   char init_wmmparam_flag;
+   s8  init_wmmparam_flag;
/* set on initialization */
u8  qos_support;
 
diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 5dba6a28dd9b..b28bc7812caa 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -533,7 +533,7 @@ typedef struct _rt_9x_tx_rate_history {
u32 ht_mcs[4][16];
 } rt_tx_rahis_t, *prt_tx_rahis_t;
 typedef struct _RT_SMOOTH_DATA_4RF {
-   charelements[4][100]; /* array to store values */
+   s8elements[4][100]; /* array to store values */
u32 index;/* index to current array to store */
u32 TotalNum; /* num of valid elements */
u32 TotalVal[4];  /* sum of valid elements */
@@ -1031,7 +1031,7 @@ typedef struct r8192_priv {
s8 cck_present_attentuation;
u8 cck_present_attentuation_20Mdefault;
u8 cck_present_attentuation_40Mdefault;
-   char cck_present_attentuation_difference;
+   s8 cck_present_attentuation_difference;
bool btxpower_tracking;
bool bcck_in_ch14;
bool btxpowerdata_readfromEEPORM;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dd0970facdf5..f36b2d3b1ee9 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4209,7 +4209,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
  *
  * Return: 0-100 percentage
  *---*/
-static u8 rtl819x_query_rxpwrpercentage(char antpower)
+static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
 {
if ((antpower <= -100) || (antpower >= 20))
return  0;
@@ -4220,9 +4220,9 @@ static u8 rtl819x_query_rxpwrpercentage(char antpower)
 
 }  /* QueryRxPwrPercentage */
 
-static u8 rtl819x_evm_dbtopercentage(char value)
+static u8 rtl819x_evm_dbtopercentage(s8 value)
 {
-   char ret_val;
+   s8 ret_val;
 
ret_val = value;
 
@@ -4297,8 +4297,8 @@ static void rtl8192_query_rxphystatus(struct r8192_priv 
*priv,
phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8  *prxpkt;
u8  i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
-   charrx_pwr[4], rx_pwr_all = 0;
-   charrx_snrX, rx_evmX;
+   s8  rx_pwr[4], rx_pwr_all = 0;
+   s8  rx_snrX, rx_evmX;
u8  evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8  is_cck_rate = 0;
@@ -4423,7 +4423,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv 
*priv,
 
/* Get Rx snr value in DB */
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
-   rx_snrX = (char)(tmp_rxsnr);
+   rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
 
@@ -4457,7 +4457,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv 
*priv,
 
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
-   rx_evmX = 

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Arnd Bergmann]

On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> Arnd Bergmann  writes:
> >> I'd like to get rid of all the drivers/staging/rtl* drivers eventually 
> >
> > That would be great, yes.
> >
> > Can you clarify what the long-term plan is? I see that
> > drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
> > and one USB device (rtl8192cu/rtl8188cus) while
> > drivers/net/wireless/rtl8xxx has all the USB parts including
> > that one.
> >
> > Does that mean we want the staging drivers for PCIe devices
> > to get merged into rtlwifi, and the remaining USB drivers to get
> > replaced by r8xxxu?
> 
> Well it really all depends on how much time I have and how much others
> step up and help contribute to the code. For rtl8xxxu my plans are as
> follows:
> 
> 1) rtl8188eu support, since this is the most widely distributed USB
> dongle which isn't currently supported by a non staging driver. I am
> currently working on this together with Andrea Merello.

Ok, cool.

> 2) Beacon support for IBSS and AP mode - hopefully this should make it
> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
> them in rtlwifi.

Do we have any indication that those two actually work in rtlwifi at the
moment? My experience seems to match the recommendations for all the
raspberry pi users that use yet another (worse looking) driver:

https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56

> 3) SDIO device support
> 
> 4) PCI device support
> 
> 5) 802.11ac device support
> 
> 3/4/5 not necessarily in that order. There really is no reason why
> rtl8xxxu shouldn't have SDIO and PCI device support added so the core
> code can be shared.

Ok, got it.

> > As one data point that I can provide (but you are probably
> > aware of), I could never get my rtl8188cus stick to work with
> > rtlwifi, but I found the older r8712u device to work fine with
> > the staging/rtl8712 driver.
> 
> I'd love to hear if the rtl8188cus works better with rtl8xxxu.

It took me far too long to get the driver running on my machine (all my fault),
but I've tested it now. Unfortunately there is something very wrong
with my home wireless network at the moment, so I can only confirm
that it doesn't work any worse than my Intel Wireless card on 2.4GHz,
but that isn't any good (5GHz devices are fine, but that doesn't
help on a 2.4GHz-only device).

This is what I see in the kernel log

[  773.862848] usb 2-1.2: new high-speed USB device number 8 using ehci-pci
[  773.957415] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8176
[  773.957425] usb 2-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[  773.957430] usb 2-1.2: Manufacturer: Realtek
[  773.957433] usb 2-1.2: SerialNumber: 00e04c01
[  774.115182] usb 2-1.2: Vendor: Realtek
[  774.115192] usb 2-1.2: Product: 
[  774.115199] usb 2-1.2: rtl8192cu_parse_efuse: dumping efuse (0x80 bytes):
[  774.115206] usb 2-1.2: 00: 29 81 00 74 ed 00 00 00
[  774.115212] usb 2-1.2: 08: ff 00 da 0b 76 81 01 41
[  774.115219] usb 2-1.2: 10: 32 00 85 62 7e ad 5c f3
[  774.115225] usb 2-1.2: 18: 70 15 9c b1 0a 03 52 65
[  774.115231] usb 2-1.2: 20: 61 6c 74 65 6b 00 02 03
[  774.115237] usb 2-1.2: 28: 00 00 00 00 00 00 00 00
[  774.115242] usb 2-1.2: 30: 00 00 00 00 00 00 00 00
[  774.115248] usb 2-1.2: 38: 00 00 00 00 00 00 00 00
[  774.115254] usb 2-1.2: 40: 00 00 00 00 00 00 00 00
[  774.115260] usb 2-1.2: 48: 00 00 00 00 00 00 00 00
[  774.115265] usb 2-1.2: 50: 00 00 00 00 00 00 00 00
[  774.115271] usb 2-1.2: 58: 06 00 2a 2a 2a 00 00 00
[  774.115277] usb 2-1.2: 60: 2a 2a 2a 00 00 00 00 00
[  774.115283] usb 2-1.2: 68: 00 00 00 00 04 04 04 00
[  774.115289] usb 2-1.2: 70: 00 00 00 00 00 00 05 00
[  774.115295] usb 2-1.2: 78: 10 00 00 00 36 00 00 00
[  774.115302] usb 2-1.2: RTL8188CU rev A (TSMC) 1T1R, TX queues 2, WiFi=1, 
BT=0, GPS=0, HI PA=0
[  774.115308] usb 2-1.2: RTL8188CU MAC: 5c:f3:70:15:9c:b1
[  774.115314] usb 2-1.2: rtl8xxxu: Loading firmware 
rtlwifi/rtl8192cufw_TMSC.bin
[  774.115409] usb 2-1.2: Firmware revision 80.0 (signature 0x88c1)
[  775.692344] rtl8xxxu 2-1.2:1.0 wlan1: renamed from wlan0
[  775.721151] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[  775.746653] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[  775.798780] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[  788.414618] wlan2: authenticate with 22:4e:7f:6f:5b:3c
[  788.452485] wlan2: send auth to 22:4e:7f:6f:5b:3c (try 1/3)
[  788.457926] wlan2: authenticated
[  788.462261] wlan2: associate with 22:4e:7f:6f:5b:3c (try 1/3)
[  788.475159] wlan2: RX AssocResp from 22:4e:7f:6f:5b:3c (capab=0x431 status=0 
aid=1)
[  788.504683] wlan2: associated

throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets
5mbit/s on the same network, but I guess that doesn't really mean much
as long as I have problems with the infrastructure.

rtl8xxxu  IEEE 802.11  ESSID:"openwrt24-ab"  
  Mode:Managed  

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Xose Vazquez Perez]

Arnd Bergmann  wrote:

> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.

A replacement for "staging/rtl8712", with MAC80211 support, is
available at: https://github.com/chunkeey/rtl8192su

Also a fullmac/cfg80211 driver(r92su) is available at the
same repository.
--
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: Keep CoDel stats per txq, export them in debugfs.

[Toke Høiland-Jørgensen]

Currently the 'aqm' stats in mac80211 only keeps overlimit drop stats,
not CoDel stats. This moves the CoDel stats into the txqi structure and
adds the drop and mark counts to the debug output.

Cc: Michal Kazior 
Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/debugfs.c | 12 
 net/mac80211/ieee80211_i.h |  2 +-
 net/mac80211/tx.c  |  4 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 27e6fb9..69bf2e5 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct file 
*file)
len += scnprintf(info->buf + len,
 info->size - len,
 "* vif\n"
-"ifname addr ac backlog-bytes backlog-packets flows 
overlimit collisions tx-bytes tx-packets\n");
+"ifname addr ac backlog-bytes backlog-packets flows 
drops marks overlimit collisions tx-bytes tx-packets\n");
 
list_for_each_entry_rcu(sdata, >interfaces, list) {
txqi = to_txq_info(sdata->vif.txq);
len += scnprintf(info->buf + len, info->size - len,
-"%s %pM %u %u %u %u %u %u %u %u\n",
+"%s %pM %u %u %u %u %u %u %u %u %u %u\n",
 sdata->name,
 sdata->vif.addr,
 txqi->txq.ac,
 txqi->tin.backlog_bytes,
 txqi->tin.backlog_packets,
 txqi->tin.flows,
+txqi->cstats.drop_count,
+txqi->cstats.ecn_mark,
 txqi->tin.overlimit,
 txqi->tin.collisions,
 txqi->tin.tx_bytes,
@@ -158,14 +160,14 @@ static int aqm_open(struct inode *inode, struct file 
*file)
len += scnprintf(info->buf + len,
 info->size - len,
 "* sta\n"
-"ifname addr tid ac backlog-bytes backlog-packets 
flows overlimit collisions tx-bytes tx-packets\n");
+"ifname addr tid ac backlog-bytes backlog-packets 
flows drops marks overlimit collisions tx-bytes tx-packets\n");
 
list_for_each_entry_rcu(sta, >sta_list, list) {
sdata = sta->sdata;
for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
txqi = to_txq_info(sta->sta.txq[i]);
len += scnprintf(info->buf + len, info->size - len,
-"%s %pM %d %d %u %u %u %u %u %u %u\n",
+"%s %pM %d %d %u %u %u %u %u %u %u %u 
%u\n",
 sdata->name,
 sta->sta.addr,
 txqi->txq.tid,
@@ -173,6 +175,8 @@ static int aqm_open(struct inode *inode, struct file *file)
 txqi->tin.backlog_bytes,
 txqi->tin.backlog_packets,
 txqi->tin.flows,
+txqi->cstats.drop_count,
+txqi->cstats.ecn_mark,
 txqi->tin.overlimit,
 txqi->tin.collisions,
 txqi->tin.tx_bytes,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c9f8c80..9f11b13 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -812,6 +812,7 @@ struct txq_info {
struct fq_tin tin;
struct fq_flow def_flow;
struct codel_vars def_cvars;
+   struct codel_stats cstats;
unsigned long flags;
 
/* keep last! */
@@ -1106,7 +1107,6 @@ struct ieee80211_local {
struct fq fq;
struct codel_vars *cvars;
struct codel_params cparams;
-   struct codel_stats cstats;
 
const struct ieee80211_ops *ops;
 
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 682011e..201167d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1339,7 +1339,7 @@ static struct sk_buff *fq_tin_dequeue_func(struct fq *fq,
local = container_of(fq, struct ieee80211_local, fq);
txqi = container_of(tin, struct txq_info, tin);
cparams = >cparams;
-   cstats = >cstats;
+   cstats = >cstats;
 
if (flow == >def_flow)
cvars = >def_cvars;
@@ -1399,6 +1399,7 @@ void ieee80211_txq_init(struct ieee80211_sub_if_data 
*sdata,
fq_tin_init(>tin);
fq_flow_init(>def_flow);
codel_vars_init(>def_cvars);
+   codel_stats_init(>cstats);
 

Re: TCP performance regression in mac80211 triggered by the fq code

[Toke Høiland-Jørgensen]

Felix Fietkau  writes:

> - if I put a hack in the fq code to force the hash to a constant value
> (effectively disabling fq without disabling codel), the problem
> disappears and even multiple streams get proper performance.

There's definitely something iffy about the hashing. Here's the output
relevant line from the aqm debug file after running a single TCP stream
for 60 seconds to that station:

ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit 
collisions
tx-bytes tx-packets
wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925

(there are two extra fields here; I added per-txq CoDel stats, will send
a patch later).

This shows that the txq has 146 flows associated from that one TCP flow.
Looking at this over time, it seems that each time the queue runs empty
(which happens way too often, which is what I was originally
investigating), another flow is assigned.

Michal, any idea why? :)

-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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Larry Finger]

On 07/20/2016 06:25 AM, Jes Sorensen wrote:

Arnd Bergmann  writes:

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:

Arnd Bergmann  writes:
I think that would be better, albeit not a big issue.


Ok, and since Kalle applied the first patch to his tree, I'm now sending
a series of three patches that are all for Greg, which also avoids some
possible confusion.


Awesome!


I'd like to get rid of all the drivers/staging/rtl* drivers eventually


That would be great, yes.

Can you clarify what the long-term plan is? I see that
drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
and one USB device (rtl8192cu/rtl8188cus) while
drivers/net/wireless/rtl8xxx has all the USB parts including
that one.

Does that mean we want the staging drivers for PCIe devices
to get merged into rtlwifi, and the remaining USB drivers to get
replaced by r8xxxu?


Well it really all depends on how much time I have and how much others
step up and help contribute to the code. For rtl8xxxu my plans are as
follows:

1) rtl8188eu support, since this is the most widely distributed USB
dongle which isn't currently supported by a non staging driver. I am
currently working on this together with Andrea Merello.

2) Beacon support for IBSS and AP mode - hopefully this should make it
possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
them in rtlwifi.

3) SDIO device support

4) PCI device support

5) 802.11ac device support

3/4/5 not necessarily in that order. There really is no reason why
rtl8xxxu shouldn't have SDIO and PCI device support added so the core
code can be shared.


As one data point that I can provide (but you are probably
aware of), I could never get my rtl8188cus stick to work with
rtlwifi, but I found the older r8712u device to work fine with
the staging/rtl8712 driver.


I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the
rtl8712 device, rtl8192su?, then potentially that could be added to
rtl8xxxu as well, but it's not a top priority on my list right now.


I would be very pleased to eliminate all the rtl* drivers from staging, 
particularly the USB varieties. I have been very disappointed with the USB group 
at Realtek. They dropped rtl8192cu on me, and then have provided no support. As 
I know nothing of the chip internals, there has been little I could do to 
improve the driver. In addition, they have never implemented any of the code 
improvements in any new USB drivers. Jes has done a wonderful job of making 
sense of the crap drivers from Realtek, and rtl8xxxu is a very good start. 
Adding SDIO support for the RTL8723BS would be a plus. At the moment, there is 
only an out-of-tree driver at GitHub, which I refuse to submit to staging. At 
the moment, it appears that every tablet with this chip needs special treatment. 
In addition, the SDIO support seems to be buggy.


The drivers in question and my comments are as follows:

rtl8712u and rtl8188eu - replaced by new code in rtl8xxxu.
rtl8723au - already in rtl8xxxu
rtl8192e - This chip is so rarely used that it does not make much difference 
what we do. If someone wants to integrate it into rtlwifi, I would have no 
objection, but I do not expect to contribute to the effort.

rtl8192u - This one is even rarer. I have no sample, thus I would be unable to 
test.
rtl8192cu - Replace with rtl8xxxu as soon as the new driver supports beacons. 
Good riddance.


Larry

--
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: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

[Luana Borgia]

Hi Amitkumar,
any news about this issue? I've the same problem also..

Security a part, we can't leave the WIFI open or just with WEP because
we get too many not trusted connection that consume a lot of our
bandwidth

Thanks, regards
Luana

2016-07-08 11:15 GMT+02:00 Amitkumar Karwar :
>> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
>> ow...@vger.kernel.org] On Behalf Of Nestor Machno
>> Sent: Thursday, July 07, 2016 6:07 AM
>> To: linux-wireless@vger.kernel.org
>> Subject: Fwd: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
>>
>> Hi All,
>> Amitkumar, can you confirm if this this is a bug or today is fixed?
>
> Yes. This is a bug in our firmware. ADHOC in WPA/WPA2 security is broken. We 
> have asked firmware experts to look into this. As we have a mid-year shutdown 
> this week, they will be able to check the problem next week only. However 
> ADHOC in open mode should work as expected
>
>>
>> Vincent, I had also faced similar issue on Surface Pro 2 with backports
>> from 4.1... So here few question:
>>
>> * I saw in 1st post that you where working to make work the
>> wpa_supplicant with mixed configuration for adhoc (wpa-none + wpa-ibss),
>> but also in recent post that you focus mostly on debugging wpa-ibss. I
>> suggest to focus your test on one wpa mode and I think wpa-none better
>> because it's easier..
>> * Why you are not testing the latest backport from upstream kernel? as
>> you can know Marvell is focus most to fix open issue on current stable
>> release, I saw from commit that recently they fix something about WPA on
>> mixflex, see
>> https://backports.wiki.kernel.org/index.php/Documentation/compat-
>> drivers/hacking
>> * Would be good information to know if you tested also on backport 3.x,
>> did you?  I know mwifiex's WPA stack changed a lot from 3.x kernel.
>> * To support you more, could you enable debug info and provide full log
>> of your setup? .config? patch? anything else?
>> * Can you share us your hacked backport?
>> * Lat question Vincent, are you working for AIRBUS, ACTIA or THALES ?
>> :)
>>
>> Best Regards
>> Nestor
>>
>> On Mon, Jun 13, 2016 at 7:42 AM, Vincent CESSON
>>  wrote:
>> > Hi Amitkumar,
>> >
>> > Here are the wpa_supplicant logs (with CONFIG_IBSS_RSN=y enabled) from
>> > the two devices. Beside wpa_supplicant, I manually set IPs
>> > 192.168.1.xy with command "ifconfig mlan0 192.168.1.xy" and then I try
>> > to ping each other, without success.
>> >
>
> Regards,
> Amitkumar
--
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] cfg80211: Allow differnt beacon interval if driver supports

[Undekari, Sunil Dutt]

>Ah, heh. Yes, I think this is exactly the use case they have in mind.
>Each of the multiple BSSes is represented by its own AP type virtual interface.
Yes . This is the requirement we are targeting . The use case is also to have 
different beacon interval for these VAP's and hence this patch. 
Please let us know if this patch with typo addressed to "different" is 
acceptable. Shall raise another patch set accordingly. 

Regards,
Sunil

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Michal Kazior]

On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi)
 wrote:
> Michal,
>
> Can you please let me know if this change is fine or not ?
> I am waiting infinitely for  your reply long time

Sorry. I was absent for a while and this email slipped by.

Quoting your other email:

> is this patch is good to go (or) should i re-work  ?
> I had replied to Michal's comment of introducing a new firmware
> feature flag will not address the issue in older firmware / code.
> Let me know if i had missed something very obvious.

I couldn't really find any conclusion to this thread in my inbox.

The hw_params approach is definitely wrong. The ACK problem is
firmware-specific, not hardware-specific.

I'm fine with removing the workaround completely if 636 is guaranteed
to not be broken, including AP and P2P GO operation. The client
operation will probably work since wmi-roam event is used for HW
connection monitoring.

Nullfunc tx-status ack/noack reports could be probably fixed up using
sta kickout events (with short timeouts) as a fallback. This would
make it easier for users because otherwise they'd need to enable
disassoc_low_ack in hostapd (which is probably impossible with
wpa_supplicant for p2p, no?).


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: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

[Machani, Yaniv]

On Wed, Jul 20, 2016 at 09:45:16, Yeoh Chun-Yeow wrote:
> Johannes Berg
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving 
> time
> 
> On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv  wrote:
> > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote:
> >> Johannes Berg
> >> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving 
> >> time
> >>
> >> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland 
> >> wrote:
> >> > On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv wrote:
> >> >> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> >> >
> >> > This wording seems to indicate that it is not per path.  Perhaps 
> >> > this should be clarified in the standard.  (If the intent turns 
> >> > out to be per path, then I guess we should fix it by storing 
> >> > last_preq per path
> >> > instead.)
> >> >
> >> >
> >> > Ignoring the standard for a second, let's explore this: can you 
> >> > give some idea on how many stations are in your target network, 
> >> > how frequently a given pair of nodes unpeer, what sort of 
> >> > improvements you see with the patch?  It should then be pretty 
> >> > easy to run some simulations to see the scenarios where this helps and 
> >> > where it hurts.
> >> >
> >>
> >
> > Bob, Chun-Yeow,
> > Thanks for your inputs.
> >
> > Let take a simple scenario, where you have a,b,c,d nodes connected 
> > to each
> other as shown below.
> >
> > A~ ~ C- - - D
> >\  /
> >   \ /
> >  B
> >
> > A would like to pass data to D.
> > A-C matric is worse than A-B-C, so path is constructed via B.
> > We are in idle state, and PREQ are sent every
> dot11MeshHWMPpreqMinInterval.
> > Now, node B have been disconnected (ran out of battery/shut 
> > down/suddenly went out of range) As A has a path to D via B, he 
> > cleans up his
> path table.
> > Now he needs to build a new path, in the WCS, he have just sent a PREQ.
> > And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until
> he can rebuild the path.
> 
> Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it 
> produces positive impact to your network? Once the path to A - C - D 
> has established, it needs to wait till the active path timer to expire 
> before establishing a new path. This active path time is default to
> 5000 TUs (or 5s).
> 

We did tried it as well, but again, this will cause us sending PREQ more 
frequently.

> > As we wouldn't like to flood the network with PREQ, we can assume 
> > that the
> dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un- 
> acceptable.
> >
> 
> But your patch is indeed generating "more" PREQ frame.
>
Well, we are sending more, but just in a specific scenario where it's needed 
ASAP to establish a path.
 
> > In cases where you need to have a reliable data link, passing 
> > audio/video you
> usually can't afford few seconds w/o traffic.
> >
> >> In addition to Bob's comment, you probably can try to reduce the 
> >> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to 
> >> default value 10 TUs. Besides, you can also reduce the 
> >> mesh_path_refresh_time which is currently default to 1000 ms and 
> >> check whether you can improve on your network scenarios.
> >>
> >
> > We did tried to play with these values, but again, we don't want to 
> > flood the
> network.
> > We just want to recover ASAP.
> >
> >> When you mentioned "next hop peer disconnect", it could also be the 
> >> time taken to re-established the mesh peering before your mesh STA 
> >> can transmit the data to your peer mesh STA.
> >>
> >
> > Link establishment takes no more than few 100s of ms usually, And in 
> > the example above, there is no new link establishment, just path generation.
> >
> 
> Suggest that you simulate your scenario and validate the improvement first.
> 

We have made many lab tests, with 10s of nodes in open air and in a controlled 
environment.
This patch is just one of the improvements we saw necessary for performance, we 
have multiple others for the metric calculation, and more. 
We understand that the HWMP and the general mesh implementation is more sensor 
network related, where there is no need for stable high throughput 100% of the 
time.
You can also have a look in our white paper, describing small parts of the 
tests we have made in the last section - 
http://www.ti.com/lit/wp/swry024/swry024.pdf

Thanks,
Yaniv

[RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
NULL func status (always acked/successs !!) when hostapd does a
PROBE_CLIENT via nullfunc frames when the station is powered off
abruptly (inactive timer probes client via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
introduced by the change ("ath10k: fix beacon loss handling ") for
QCA99X0 and later chipsets. The normal tx path provides the proper
status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets

Signed-off-by: Tamizh chelvam 
Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/core.c | 3 +++
 drivers/net/wireless/ath/ath10k/core.h | 1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dcc76b6..8687aaa 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..d3dfda0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,7 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+   bool disable_null_func_workaround;
} fw;
} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
 * mode though because AP don't sleep.
 */
if (ar->htt.target_version_major < 3 &&
+   !ar->hw_params.fw.disable_null_func_workaround &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
  ar->running_fw->fw_file.fw_features))
-- 
1.9.1

--
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: End the MPSP even if EOSP frame was not received

[Bob Copeland]

On Wed, Jul 20, 2016 at 04:11:33PM +0900, Masashi Honma wrote:
> On 2016年07月19日 19:40, Bob Copeland wrote:
> >
> >OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in
> >ieee80211_mps_sta_status_update(), or does the node completely repeer?
> >
> >ISTR running into a problem where rebooted peer (previously in power-save)
> >would send popen but we would buffer the response due to stale PS sta
> >flag.
[...]
>
> So looks no problem.

Ok, thanks for testing that - fwiw original patch

Acked-by: Bob Copeland 

-- 
Bob Copeland %% http://bobcopeland.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: [PATCH] staging: rtl8723au: hal: check BT_Active and BT_State with correct bit pattern

[Jes Sorensen]

Colin King  writes:
> From: Colin Ian King 
>
> BT_Active and BT_State are being masked with 0x00ff so it the subsequent
> comparisons with 0x are therefore a buggy check.  Instead, check them
> against 0x00ff.
>
> Unfortunately I couldn't find a datasheet or hardware to see if 0x
> is an expected invalid bit pattern that should be checked before BT_Active and
> BT_State are masked with 0x00ff, so for now, this fix seems like the least
> risky approach.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I don't really know about the BT parts here, since I never did anything
with that part of the chip. Larry probably knows more.

The only question is whether fixing this bug changes behavior that has
unexpected side effects?

Cheers,
Jes

>
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> index bfcbd7a..6989580 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> @@ -9824,7 +9824,7 @@ void BTDM_CheckBTIdleChange1Ant(struct rtw_adapter 
> *padapter)
>   BT_Polling = rtl8723au_read32(padapter, regBTPolling);
>   RTPRINT(FBT, BT_TRACE, ("[DM][BT], BT_Polling(0x%x) =%x\n", 
> regBTPolling, BT_Polling));
>  
> - if (BT_Active == 0x && BT_State == 0x && BT_Polling == 
> 0x)
> + if (BT_Active == 0x00ff && BT_State == 0x00ff && BT_Polling == 
> 0x)
>   return;
>   if (BT_Polling == 0)
>   return;
--
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/3] staging/rtl8192e: use s8 instead of char

[Jes Sorensen]

Arnd Bergmann  writes:
> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>> Arnd Bergmann  writes:
>> I think that would be better, albeit not a big issue. 
>
> Ok, and since Kalle applied the first patch to his tree, I'm now sending
> a series of three patches that are all for Greg, which also avoids some
> possible confusion.

Awesome!

>> I'd like to get rid of all the drivers/staging/rtl* drivers eventually 
>
> That would be great, yes.
>
> Can you clarify what the long-term plan is? I see that
> drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
> and one USB device (rtl8192cu/rtl8188cus) while
> drivers/net/wireless/rtl8xxx has all the USB parts including
> that one.
>
> Does that mean we want the staging drivers for PCIe devices
> to get merged into rtlwifi, and the remaining USB drivers to get
> replaced by r8xxxu?

Well it really all depends on how much time I have and how much others
step up and help contribute to the code. For rtl8xxxu my plans are as
follows:

1) rtl8188eu support, since this is the most widely distributed USB
dongle which isn't currently supported by a non staging driver. I am
currently working on this together with Andrea Merello.

2) Beacon support for IBSS and AP mode - hopefully this should make it
possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
them in rtlwifi.

3) SDIO device support

4) PCI device support

5) 802.11ac device support

3/4/5 not necessarily in that order. There really is no reason why
rtl8xxxu shouldn't have SDIO and PCI device support added so the core
code can be shared.

> As one data point that I can provide (but you are probably
> aware of), I could never get my rtl8188cus stick to work with
> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.

I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the
rtl8712 device, rtl8192su?, then potentially that could be added to
rtl8xxxu as well, but it's not a top priority on my list right now.

Cheers,
Jes
--
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: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
 wrote:
>
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
>  wrote:
> > On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
> >  wrote:
> >> I think security failures are due to peer unmap & map upon reassoc. Can 
> >> you please try below change?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >> b/drivers/net/wireless/ath/ath10k/mac.c
> >> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct 
> >> work_struct *wk)
> >> sta->addr, smps, err);
> >> }
> >>
> >> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> -   changed & IEEE80211_RC_NSS_CHANGED) {
> >> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> +   changed & IEEE80211_RC_NSS_CHANGED) &&
> >> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> >> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
> >> rates/nss\n",
> >>sta->addr);
> >
> > Bottom posting please. I have tried your change i still see the same issue.
> > Right after connecting i see that packets are encrypted but once it
> > unset/set "bitrates" plain packets are seen in sniffer.
> >
> > BTW, i am not rebooting for each driver update, just re-inserting the 
> > module,
> > do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.



>
>   
> >> From: Krishna Chaitanya 
> >> Sent: Friday, July 8, 2016 5:26 PM
> >> To: Manoharan, Rajkumar
> >> Cc: linux-wireless; ath10k
> >> Subject: Re: ath10k + iw set bitrates is causing FW crash
> >>
> >> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
> >>  wrote:
> > I am using ath10k driver with qca988x hw2.0 and trying to limit it to 
> > use
> > VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
> >
> > But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> > no crash is observed but it still uses MCS9.
> >
> > tree: wireless-drivers-next: 
> > commit#535633a5ba4ea2504fa6c33176633becf0e59339
> >
> > 1) If i disable HW_RATE_CONTROL, will ath10k honor
> > the mac80211 rates?
> >
> 
> >>> Thanks for reporting the issue. Could you please try with below change?
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >>> b/drivers/net/wireless/ath/ath10k/mac.c
> >>> index 5e1cc8f4c43c..cfa7e01a6103 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> >>> return ret;
> >>> }
> >>>
> >>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
> >>> +   peer_arg.peer_reassoc = reassoc;
> >>> +
> >>> ret = ath10k_wmi_peer_assoc(ar, _arg);
> >>> if (ret) {
> >>> ath10k_warn(ar, "failed to run peer assoc for STA %pM 
> >>> vdev %i: %d\n",
> >>
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
Rajkumar,

I am still not able to make mcs9 work, so i have tried to change the Nss to 1
using iw, but that is not taking affect. This command is not taking effect.
--
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 connecting to wifi on libertas_cpio (sd8686)

[Christopher Williamson]

Just following up from my previous email:

I am actually setting the reg domain using: iw reg set GB (copy/pasted
the IN from elsewhere - oops!)

As for progress, however, I have tried the following:

- setting the debug level to 0xfff. This still produces no
additional output even with 8 set in printk.

- removing the v9 firmware - same result as before - system fully locks up.

- disabling ipv6 - gets rid of IPv6 interface not up warning but
that’s not causing any problems and this didn’t make any difference.

It doesn’t seem to matter what I try at the moment - all attempts to
connect result in the system crashing which I guess is better than it
just asking me for a password over and over - it looks like it is
attempting association at this point which is good but I don’t know
why the box is crashing out and dmesg -w doesn’t show any additional
output before the freeze.

If anyone has any more ideas I would be more than happy to try them!
Thanks for the help so far Dan!

Christopher Williamson

On 19 July 2016 at 18:41:34, Christopher Williamson
(h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:

> So I’ve now disabled IPv6 and have set the GB (Great Britain) regulation code 
> using:
>
> iw reg set IN
>
> Now when I try to connect to the network using wicd the system seems to crash 
> - I guess at least it’s doing something more than just asking for the 
> password again like it did with NetworkManager but so far no further progress 
> on getting this working properly.
>
> Christopher Williamson
>
>
>
> On 19 July 2016 at 18:03:16, Christopher Williamson 
> (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
>
> > Absolutely!
> >
> > With the debug logging enabled I got the following:
> >
> > Connecting the device initially with debug enabled:
> >
> > [ 205.302685] libertas_sdio: Libertas SDIO driver
> > [ 205.302698] libertas_sdio: Copyright Pierre Ossman
> > [ 205.503465] cfg80211: World regulatory domain updated:
> > [ 205.503478] cfg80211: DFS Master region: unset
> > [ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth), 
> > (max_antenna_gain, max_eirp), (dfs_cac_time)
> > [ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
> > mBm), (N/A)
> > [ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
> > mBm), (N/A)
> > [ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
> > mBm), (N/A)
> > [ 205.503513] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
> > AUTO), (N/A, 2000 mBm), (N/A)
> > [ 205.503522] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
> > AUTO), (N/A, 2000 mBm), (0 s)
> > [ 205.503529] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 
> > 2000 mBm), (0 s)
> > [ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
> > mBm), (N/A)
> > [ 205.503542] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 
> > 0 mBm), (N/A)
> > [ 212.249171] gma500 :00:02.0: Backlight lvds set brightness 7a127a12
> > [ 212.324898] mmc1: new SDIO card at address 0001
> > [ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device) 
> > (uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x0303
> > [ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device) 
> > (uninitialized): PREP_CMD: command 0x00a3 failed: 2
> > [ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN 802.11 adapter
> > [ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >
> >
> > Strangely when I attempt to connect to the WiFi network I’m using the only 
> > error I get is:
> >
> > [ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >
> > I was expecting more output and am guessing I’ve missed something here.
> >
> > Christopher Williamson
> >
> > On 19 July 2016 at 17:38:35, Dan Williams 
> > (d...@redhat.com(mailto:d...@redhat.com)) wrote:
> >
> > > On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> > > > Hi everyone!
> > > >
> > > > I’ve just got myself a Viliv N5 and am trying to get the integrated
> > > > Wifi chipset working on it.
> > > >
> > > > I am able to see networks around me but any attempts to connect them
> > > > appear to time out and fail.
> > > >
> > > > I have filed a linux kernel bug related to this issue:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=135421goo
> > > >
> > > > I figured here may be a good place to ask about it and hopefully to
> > > > get to the bottom of why it happens and how I can help to fix it.
> > > >
> > > > Happy to provide any information which may be helpful! :)
> > >
> > > Can you reload the driver stack:
> > >
> > > rmmod libertas_sdio
> > > rmmod libertas
> > > modprobe libertas libertas_debug=0x251e7ff
> > > modprobe libertas_sdio
> > >
> > > and then reproduce the issue? The debug info should dump to 'dmesg'
> > > and may tell us what's going on.
> > >
> > > Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to 

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[Arnd Bergmann]

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
> Arnd Bergmann  writes:
> > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote:
> >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c 
> >> > b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > index 2c8a526773ed..e0a2fe5e6148 100644
> >> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct 
> >> > ts_common_info **ppTS,
> >> >   if (ieee->current_network.qos_data.supported == 0) {
> >> >   UP = 0;
> >> >   } else {
> >> > - if (!IsACValid(TID)) {
> >> > + if (!IsACValid((s8)TID)) {
> >> >   netdev_warn(ieee->dev, "%s(): TID(%d) is not 
> >> > valid\n",
> >> >   __func__, TID);
> >> >   return false;
> >> 
> >> TID is a 4-bit field, it should never go negative. The cast to s8 seems
> >> wrong to me, if anything it should be using u8. I do realize the macro
> >> IsACValid checks against negative too, but that just looks silly to me.
> >
> > Ok, I'll remove the extra comparison then to avoid the warning:
> >
> > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always
> > true due to limited range of data type [-Werror=type-limits]
> >
> > I guess it should be a separate patch. I had just stumbled over the
> > same thing before resending the patch but decided not to change it
> > to keep the patch simple.
> 
> I think that would be better, albeit not a big issue. 

Ok, and since Kalle applied the first patch to his tree, I'm now sending
a series of three patches that are all for Greg, which also avoids some
possible confusion.

> I'd like to get rid of all the drivers/staging/rtl* drivers eventually 

That would be great, yes.

Can you clarify what the long-term plan is? I see that
drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
and one USB device (rtl8192cu/rtl8188cus) while
drivers/net/wireless/rtl8xxx has all the USB parts including
that one.

Does that mean we want the staging drivers for PCIe devices
to get merged into rtlwifi, and the remaining USB drivers to get
replaced by r8xxxu?

As one data point that I can provide (but you are probably
aware of), I could never get my rtl8188cus stick to work with
rtlwifi, but I found the older r8712u device to work fine with
the staging/rtl8712 driver.

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

[PATCH] wlcore: spi: fix build warning caused by redundant variable

[Reizer, Eyal]

The ret variable is unused in wlcore_probe_of()
Remove it for fixing build warning.

Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support")
Signed-off-by: Eyal Reizer 
---
 drivers/net/wireless/ti/wlcore/spi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 73fbcf1..6d24040 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -454,7 +454,6 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
   struct wlcore_platdev_data *pdev_data)
 {
struct device_node *dt_node = spi->dev.of_node;
-   int ret;
const struct of_device_id *of_id;
 
of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
-- 
2.7.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: End the MPSP even if EOSP frame was not received

[Masashi Honma]

On 2016年07月19日 19:40, Bob Copeland wrote:


OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in
ieee80211_mps_sta_status_update(), or does the node completely repeer?

ISTR running into a problem where rebooted peer (previously in power-save)
would send popen but we would buffer the response due to stale PS sta
flag.


Thanks. I have tried your scenario.

I have disconnected remote peer by accidental shutdown.
(This means local peer does not recognize remote peer left.)

Then remote peer restarted and started to send Mesh Peering Open frames.

Local peer receives these frames but does not respond to these
because peer_lid mismatch.

After 3 times retrial, remote peer sent Mesh Peering Close frame
with reason code = 56(MESH-MAX-RETRIES).

And then, struct sta_info is freed and allocated.

So looks no 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: [PATCHv8] wlcore: spi: add wl18xx support

[Reizer, Eyal]

> 
> > Add support for using with both wl12xx and wl18xx.
> >
> > - all wilink family needs special init command for entering wspi mode.
> >   extra clock cycles should be sent after the spi init command while the
> >   cs pin is high.
> > - Use inverted chip select for sending a dummy 4 bytes command that
> >   completes the init stage.
> >
> > Signed-off-by: Eyal Reizer 
> > Acked-by: Rob Herring 
> > ---
> > v1->v2:update device tree bindings configuration
> > v2->v3:revert from manual gpio manipulation. use inverted chip select
> instead
> > for sending the extra init cycle which, achieves the same hardware purpose.
> > update device tree bindings docucmentation accordingly
> > v3->v4: Remove redundant data form binding documentation and fix chip
> select
> > number mismatch in wl1271 example
> > v4->v5: Rebase on top of head of wireless-drivers-next
> > v5->v6: Add ACKs
> > v6->v7: Mail format issues
> > v7->v8: Remove redundant varaible from wlcore_probe_of
> 
> I have already applied this patch, it's too late to send a new version.
> Now you need to send a new patch, on top of wireless-drivers-next, which
> removes the redundant variable.
> 
Understood. Will submit shortly

Best Regards,
Eyal
--
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: [PATCHv8] wlcore: spi: add wl18xx support

[Kalle Valo]

"Reizer, Eyal"  writes:

> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
>   extra clock cycles should be sent after the spi init command while the
>   cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
>   completes the init stage.
>
> Signed-off-by: Eyal Reizer 
> Acked-by: Rob Herring 
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle which, achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip select
> number mismatch in wl1271 example
> v4->v5: Rebase on top of head of wireless-drivers-next
> v5->v6: Add ACKs
> v6->v7: Mail format issues
> v7->v8: Remove redundant varaible from wlcore_probe_of

I have already applied this patch, it's too late to send a new version.
Now you need to send a new patch, on top of wireless-drivers-next, which
removes the redundant variable.

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

[PATCHv8] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
Acked-by: Rob Herring 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
v6->v7: Mail format issues
v7->v8: Remove redundant varaible from wlcore_probe_of
 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 124 +
 2 files changed, 137 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
  {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+ {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..6d24040 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = 

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

[Yeoh Chun-Yeow]

On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv  wrote:
> On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote:
>> Johannes Berg
>> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
>> time
>>
>> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland 
>> wrote:
>> > On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv wrote:
>> >> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
>> >
>> > This wording seems to indicate that it is not per path.  Perhaps
>> > this should be clarified in the standard.  (If the intent turns out
>> > to be per path, then I guess we should fix it by storing last_preq
>> > per path
>> > instead.)
>> >
>> >
>> > Ignoring the standard for a second, let's explore this: can you give
>> > some idea on how many stations are in your target network, how
>> > frequently a given pair of nodes unpeer, what sort of improvements
>> > you see with the patch?  It should then be pretty easy to run some
>> > simulations to see the scenarios where this helps and where it hurts.
>> >
>>
>
> Bob, Chun-Yeow,
> Thanks for your inputs.
>
> Let take a simple scenario, where you have a,b,c,d nodes connected to each 
> other as shown below.
>
> A~ ~ C- - - D
>\  /
>   \ /
>  B
>
> A would like to pass data to D.
> A-C matric is worse than A-B-C, so path is constructed via B.
> We are in idle state, and PREQ are sent every dot11MeshHWMPpreqMinInterval.
> Now, node B have been disconnected (ran out of battery/shut down/suddenly 
> went out of range)
> As A has a path to D via B, he cleans up his path table.
> Now he needs to build a new path, in the WCS, he have just sent a PREQ.
> And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until he can 
> rebuild the path.

Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it
produces positive impact to your network? Once the path to A - C - D
has established, it needs to wait till the active path timer to expire
before establishing a new path. This active path time is default to
5000 TUs (or 5s).

> As we wouldn't like to flood the network with PREQ, we can assume that the 
> dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un-acceptable.
>

But your patch is indeed generating "more" PREQ frame.

> In cases where you need to have a reliable data link, passing audio/video you 
> usually can't afford few seconds w/o traffic.
>
>> In addition to Bob's comment, you probably can try to reduce the
>> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
>> default value 10 TUs. Besides, you can also reduce the
>> mesh_path_refresh_time which is currently default to 1000 ms and check
>> whether you can improve on your network scenarios.
>>
>
> We did tried to play with these values, but again, we don't want to flood the 
> network.
> We just want to recover ASAP.
>
>> When you mentioned "next hop peer disconnect", it could also be the
>> time taken to re-established the mesh peering before your mesh STA can
>> transmit the data to your peer mesh STA.
>>
>
> Link establishment takes no more than few 100s of ms usually,
> And in the example above, there is no new link establishment, just path 
> generation.
>

Suggest that you simulate your scenario and validate the improvement first.

---
Chun-Yeow
--
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: linux-next: build warning after merge of the wireless-drivers-next tree

[Reizer, Eyal]

Hi Stephen,

> 
> After merging the wireless-drivers-next tree, today's linux-next build
> (x86_64 allmodconfig) produced this warning:
> 
> drivers/net/wireless/ti/wlcore/spi.c: In function 'wlcore_probe_of':
> drivers/net/wireless/ti/wlcore/spi.c:457:6: warning: unused variable 'ret' [-
> Wunused-variable]
>   int ret;
>   ^
> 
> Introduced by commit
> 
>   01efe65aba65 ("wlcore: spi: add wl18xx support")
> 
Of course you are right. It is indeed redundant now.
Don't know how I have missed it. Don't remember seeing a warning from the tool 
chain I have used.
Anyway ,will submit an amended patch soon.

Best Regards,
Eyal
--
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