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

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

2016-07-20 Thread 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 <yani...@ti.com> 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 <m...@bobcopeland.com>
> >> 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

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

2016-07-19 Thread Machani, Yaniv 
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 <m...@bobcopeland.com>
> 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.
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.

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.


Thanks,
Yaniv

RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template

2016-07-19 Thread Machani, Yaniv 
On Mon, Jul 18, 2016 at 21:52:22, Johannes Berg wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon 
> template
> 
> On Mon, 2016-07-18 at 09:38 -0400, Bob Copeland wrote:
> > On Wed, Jul 13, 2016 at 02:45:40PM +0300, Yaniv Machani wrote:
> > > The HT capab info field inside the HT capab IE of the mesh beacon 
> > > is incorrect (in the case of 20MHz channel width).
> > > To fix this driver will check configuration from cfg and will 
> > > build it accordingly.
> >
> > > +/* determine capability flags */
> > > + cap = sband->ht_cap.cap;
> > > +
> > > +/* if channel width is 20MHz - configure HT capab
> > > accordingly*/
> > > + if (sdata->vif.bss_conf.chandef.width ==
> > > NL80211_CHAN_WIDTH_20) {
> > > + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> > > + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> > > + }
> >
> > Is it required that HT capability match the HT operation in this case?
> >
> 
> Is there ever a case that HT *capability* should be restricted 
> artificially like that? I can't remember any cases - we do something 
> like that to work around broken APs in some cases, but here?
> 

It was done to overcome another mismatch with the defaults of the hostap 
configuration,
We'll have another look on it.

There is an IOP question here, how to handle a case where you have mixed 
capabilities of peers.
is it possible to dynamically change the channel bandwidth to allow new peers 
to join ?

Yaniv

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

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

2016-07-19 Thread Machani, Yaniv 
On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> Chun-Yeow Yeoh
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving 
> time
> 
> On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote:
> > > To improve that, added an 'immediate' flag to be used when the 
> > > path needs
> to be resolved.
> > > Once set, a PREQ frame will be send w/o considering the 
> > > MinInterval
> parameter.
> >
> > Suggest that you try to reduce the mesh_hwmp_preq_min_interval to 
> > your desired value instead of introducing a new patch specific to 
> > your use case.
> >
> > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute 
> > to specify the minimum interval of time during which a mesh STA can 
> > send only one Action frame containing a PREQ element. This is to 
> > avoid flooding of broadcast PREQ frame especially when the number of 
> > mesh STA is increased.
> 
> Good point, according to 13.10.9.3, conditions for sending PREQ include:
> 
> "The mesh STA has not sent a PREQ element for the target mesh STAs 
> less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case, 
> the transmission of the PREQ has to be postponed until this condition becomes 
> true."
> 

As I see it, the key point here is "for the target meh STA", 
Today, the code will not send a PREQ to ANY target if 
dot11MeshHWMPpreqMinInterval didn't passed.
The information is saved in the 'ifmsh->last_preq', and not per path.

Another point is, that this is a case where we had a valid path, but lost it 
due to our next hop peer disconnect.
Reducing the dot11MeshHWMPpreqMinInterval will just flood the network, 
Our goal is to improve the healing time, it's not a specific use case, it will 
improve network performance.

Thanks,
Yaniv

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

RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Machani, Yaniv 
On Wed, Jul 13, 2016 at 16:33:38, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Wed, Jul 13, 2016 at 10:11:25AM +, Machani, Yaniv wrote:
> > > > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > > > de-initialization process will be stopping the beacons, similar to ap.
> > > > Update ieee80211_stop_mesh() flow accordingly.
> > > >
> > > How well have you tested that with other drivers?
> > >
> >
> > Sorry for the delayed response (I've been out) and thanks for your 
> > comments, I have tested it with RT3572 as well, and didn't see any issue.
> > I'll update the comment to reflect that.
> 
> I'll give this a test on ath10k and wcn36xx as they are the ones most 
> likely to care about ordering.
> 

Thank you,
Yaniv
> --
> 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 3/4] mac80211: mesh: fixed HT ies in beacon template

2016-07-13 Thread Machani, Yaniv 
On Wed, Jun 29, 2016 at 10:17:35, Johannes Berg wrote:
> Cc: Kama, Meirav
> Subject: Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon 
> template
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> >
> >  net/mac80211/mesh.c | 33 -
> >  net/mac80211/util.c |  3 ---
> >  net/wireless/mesh.c |  2 +-
> 
> That's not a good patch - one change is mac80211 and the other cfg80211.
> 
> > -   .ht_opmode =
> IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED,
> > +   .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONE,
> >
> How are you planning to comply with 802.11 now?

Good point, this changed should be removed.
The reason for this change was that we've noticed a difference between mesh 
beacon (built by the mac80211) and mesh actions (built by the supplicant) in 
the HT information IE.
In beacons the HT operational mode is Mixed Mode (0x11)  while in actions it is 
None (0x00). 
After a second look, it seems that it's the Supplicant that doesn't set the 
default value correctly.

We'll send an updated patch for it.
Thanks,
Yaniv

> 
> The HT Protection field in a mesh STA may be set to no protection mode 
> only if — All STAs detected in the primary or the secondary channel 
> are HT
>   STAs, and
> — All mesh STA members of this MBSS that are one-hop neighbors of the
>   transmitting mesh STA are either:
>   — 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or
>   — 20 MHz HT mesh STAs in a 20 MHz MBSS.
> 
> johannes

RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Machani, Yaniv 
On Wed, Jun 29, 2016 at 10:14:19, Johannes Berg wrote:
> Cc: Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> > From: Maital Hahn 
> >
> > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > de-initialization process will be stopping the beacons, similar to ap.
> > Update ieee80211_stop_mesh() flow accordingly.
> >
> How well have you tested that with other drivers?
> 

Sorry for the delayed response (I've been out) and thanks for your comments,
I have tested it with RT3572 as well, and didn't see any issue.
I'll update the comment to reflect that.

Thanks,
Yaniv

> Changing behaviour to something a single driver desires isn't 
> necessarily the best thing to do, since there always are multiple drivers.
> 
> If you're able to demonstrate that it works with the other drivers I'm 
> willing to take that - the change makes sense after all, and it seems 
> drivers must support this ordering since peers are also removed 
> dynamically... But still. Don't just make a change like that without 
> even giving any indication why you think it's fine for other drivers!
> 
> johannes


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

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

2016-07-13 Thread Machani, Yaniv 
On Tue, Jun 28, 2016 at 13:41:35, Machani, Yaniv wrote:
> Guy; Johannes Berg; Arik Nemtsov; linux-wireless@vger.kernel.org; 
> net...@vger.kernel.org
> Subject: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for 
> wl8
> 
> From: Maital Hahn <mait...@ti.com>
> 
> 1. Added support for interface and role of mesh type.
> 2. Enabled enable/start of mesh-point role,
>and opening and closing a connection with a mesh peer.
> 3. Added multirole combination of mesh and ap
>under the same limits of dual ap mode.
> 4. Add support for 'sta_rc_update' opcode for mesh IF.
>The 'sta_rc_update' opcode is being used in mesh_plink.c.
> Add support in wlcore to handle this opcode correctly for mesh (as 
> opposed to current implementation that handles STA only).
> 5. Bumped the firmware version to support new Mesh functionality
> 
> Signed-off-by: Maital Hahn <mait...@ti.com>
> Signed-off-by: Yaniv Machani <yani...@ti.com>
> ---

Any comments on this patch ?
Can this be pulled ?

Thanks,
Yaniv
--
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/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting

2016-06-28 Thread Machani, Yaniv 
On Tue, Jun 28, 2016 at 15:27:47, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Hahn, Maital
> Subject: Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a 
> mesh peer is disconnecting
> 
> On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote:
> > From: Maital Hahn 
> >
> > Once receiving a CLOSE action frame from the disconnecting peer, 
> > flush all entries in the path table which has this peer as the next hop.
> 
> Please address the user-visible behavior in your commit messages.
> Does it crash?  Does it send frames to an invalid peer?  Do frames get 
> dropped?
> 

Hi Bob,
It was a crash, apparently already fixed by your patches some time ago.
I'll remove that part and resend the 2nd part (with some more 'why', and less 
typos..)

> > In addition, upon receiving a packet, if next hop is not found, 
> > trigger PERQ immidiatly, instead of just putting it in the queue.
> 
> "PREQ"
> 
> Please split this into a separate patch that we can review separately 
> (and also give the "why" in the commit log).
> 
> > @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct
> ieee80211_local *local,
> > if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> > changed =
> mesh_plink_dec_estab_count(sdata);
> > sta->mesh->plink_state = params->plink_state;
> > +   mesh_path_flush_by_nexthop(sta);
> 
> This isn't necessary, caller should already be doing
> mesh_path_flush_by_nexthop() in every case I could see.  Besides it 
> cannot be done under plink lock.
> 

I believe this was fixed in your patch "mac80211: mesh: flush paths outside of 
plink lock"
There is probably no need in that on the latest as well.

Thanks,
Yaniv
 


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

RE: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely

2016-06-28 Thread Machani, Yaniv 
On Tue, Jun 28, 2016 at 15:56:21, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Kama, Meirav
> Subject: Re: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely
> 
> On Tue, Jun 28, 2016 at 02:13:07PM +0300, Yaniv Machani wrote:
> > From: Meirav Kama 
> >
> > Issue happened when receiving delete_sta command without changing 
> > plink_state from ESTAB to HOLDING before.
> > When receiving delete_sta command for mesh interface verify 
> > plink_state is not ESTAB and if so, decrease plink count and update 
> > beacon.
> 
> This should be fixed already (and properly) by the patch
> "mac80211: Fix mesh estab links counting" -- please let us know if you 
> have a case that's still broken with that fix.
> 

Thanks Bob,
Will be dropped.

Yaniv
> --
> 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] wlcore: time sync : add support for 64 bit clock

2016-06-23 Thread Machani, Yaniv 
On Thu, Jun 23, 2016 at 14:18:00, Johannes Berg wrote:
> linux-wireless@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH] wlcore: time sync : add support for 64 bit clock
> 
> On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote:
> > Changed the configuration to support 64bit instead of 32bit this in 
> > order to offload the driver from handling a wraparound.
> 
> [...]
> 
> Since you Cc'ed me, and presumably want me to review it, I'll say that 
> this looks like a terrible idea:
> 
> > @@ -74,10 +74,16 @@ struct wl18xx_event_mailbox {
> 
> This struct is evidently used for firmware/host communication.
> 
> >     __le16 bss_loss_bitmap;
> >
> >     /* bitmap of stations (by HLID) which exceeded max tx retries */
> > -   __le32 tx_retry_exceeded_bitmap;
> > +   __le16 tx_retry_exceeded_bitmap;
> > +
> > +   /* time sync high msb*/
> > +   u16 time_sync_tsf_high_msb;
> 
> So first of all, just using u16 instead of __le16 seems wrong.

Agree, should be changed.

> 
> Additionally, this looks like it changes the firmware API, so that 
> older firmware images will no longer work?

It is backwards compatible, 
although it changes a API structure, older firmware are using only u16 for the 
field so there is no impact on that.
Of course that for actually using the 64bit information, you will have to 
upgrade the firmware.

Yaniv

RE: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

2016-06-21 Thread Machani, Yaniv 
Yes,
TI driver have added support in our latest release (TI git).
http://software-dl.ti.com/ecs/WiLink8/R8_7/exports/release_notes_R8_7.html

Patches will be shared with mainline in the near future.

Thanks,
Yaniv Machani

-Original Message-
From: Bob Copeland [mailto:m...@bobcopeland.com] 
Sent: Tuesday, June 21, 2016 15:19
To: Altshul, Maxim
Cc: johan...@sipsolutions.net; kv...@codeaurora.org; el...@wizery.com; Machani, 
Yaniv; Mishol, Guy; a...@wizery.com; linux-wireless@vger.kernel.org; 
net...@vger.kernel.org; da...@davemloft.net
Subject: Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates in 
> TI driver.

Does this mean TI driver will support mesh at some point?

--
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: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

2016-04-11 Thread Machani, Yaniv 
On Mon, Apr 11, 2016 at 14:41:18, Pali Rohár wrote:
> Mishol, Guy; Arik Nemtsov; Gery Kahn; Felipe Balbi; David Woodhouse; 
> Aaro Koskinen; Ben Hutchings; David Gnedt; Ivaylo Dimitrov; Sebastian 
> Reichel; Tony Lindgren; Menon, Nishanth; 
> linux-wireless@vger.kernel.org; net...@vger.kernel.org; 
> linux-ker...@vger.kernel.org
> Subject: Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
> 
> On Sunday 10 April 2016 13:51:41 Pavel Machek wrote:
> > Is it "hardware can't do AP", "firmware can't do AP" or "current 
> > drivers do not support AP"?
> 

As both Firmware and HW are not in a stage where they can be modified, there is 
no support for AP mode in both.

Regards,
Yaniv Machani


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

RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

2016-04-06 Thread Machani, Yaniv 
On Wed, Apr 06, 2016 at 22:07:39, Kalle Valo wrote:
> 
> > More than that, wl1251 family is not officially supported via the 
> > mainline Linux.
> 
> I guess you mean not officially supported by TI? Because wl1251 driver 
> has been in mainline for ages and reportedly working.
>   
Correct.

Yaniv 
> --
> 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: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

2016-04-06 Thread Machani, Yaniv 
On Wed, Apr 06, 2016 at 15:12:43, Pali Rohár wrote:
> > > > For other TI wilink chips there are -ap.bin firmware files 
> > > > (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode.
> > > > But for
> > > > wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is 
> > > > missing.
> > > >
> > > > Do you have any idea what happened with AP firmware for ti
> > > > wilink4 wl1251 wifi chip? Or where can be found? Guys from TI, 
> > > > can you help?
> > > >
> > > > I see that STA firmware was added into linux-firmware tree in 
> > > > year
> > > > 2013 by this pull request [2].
> > > >
> > > > [1] -
> > > > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firm
> > > > w
> > > > are .g
> > > > it/tree/ti-connectivity
> > > >
> > > > [2] -
> > > > http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
> > >
> > > Hi! Anybody has some idea about that AP firmware?
> >
> > Hi,
> > wl1251 does not support AP mode, so there is no firmware for it in 
> > the tree.
> >
> > Regards,
> > Yaniv
> 
> Hi Yaniv! I read on some TI whitepaper, that wl1251 hardware supports 
> some Soft-AP mode. So I expect that either special FW is needed for it 
> or somehow it is possible to use current released. Do you have any 
> information about it?
> 
> --
> Pali Rohár
> pali.ro...@gmail.com

Hi Pali,
This must be some typo, the device does not support Soft-AP.
More than that, wl1251 family is not officially supported via the mainline 
Linux.
For Soft-AP, and other new features based on Linux you should use WiLink8 chip 
family.

Regards,
Yaniv

RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

2016-04-06 Thread Machani, Yaniv 
On Mon, Apr 04, 2016 at 15:39:44, Pali Rohár wrote:

> > In linux-firmware repository [1] is missing AP firmware for TI 
> > wl1251 chip. There is only STA firmware wl1251-fw.bin which supports 
> > managed and ad-hoc modes.
> >
> > For other TI wilink chips there are -ap.bin firmware files 
> > (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode. But 
> > for
> > wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is missing.
> >
> > Do you have any idea what happened with AP firmware for ti wilink4
> > wl1251 wifi chip? Or where can be found? Guys from TI, can you help?
> >
> > I see that STA firmware was added into linux-firmware tree in year
> > 2013 by this pull request [2].
> >
> > [1] -
> > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware
> > .g
> > it/tree/ti-connectivity
> >
> > [2] - 
> > http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
> >
> 
> Hi! Anybody has some idea about that AP firmware?
> 

Hi,
wl1251 does not support AP mode, so there is no firmware for it in the tree.

Regards,
Yaniv

> --
> Pali Rohár
> pali.ro...@gmail.com

RE: wl18xx: wlconf kernel compatibility

2015-06-07 Thread Machani, Yaniv 
Hi,
As the configuration file is HW depended it should be created per platform,
we have set this wiki page and script to help with initial setup :
http://processors.wiki.ti.com/index.php/Open_Source_Wireless_Connectivity_wlconf

We have also pushed a patch that makes sure the driver will not crash if there 
is a file size mismatch, 
and will fall back to default.

Regards,
Yaniv

 -Original Message-
 From: Yegor Yefremov [mailto:yegorsli...@googlemail.com]
 Sent: Saturday, June 06, 2015 6:19 PM
 To: Kalle Valo
 Cc: linux-wireless@vger.kernel.org; Machani, Yaniv; Eliad Peller; Marc Kleine-
 Budde
 Subject: Re: wl18xx: wlconf kernel compatibility
 
 Hi Kalle,
 
 On Sat, Jun 6, 2015 at 3:27 PM, Kalle Valo kv...@codeaurora.org wrote:
  Yegor Yefremov yegorsli...@googlemail.com writes:
 
  How do I know, which wlconf version is compatible with which kernel
  version? I have following problem:
 
  I have *.INI file for my particular WLAN chip. This file will be used
  to produce wl18xx-conf.bin. The size of this file will be check
  during device initialization. Depending on which kernel version is
  used the size of the required file differs. For example kernel 3.18
  requires wl18xx-conf.bin to have 1221 bytes, 4.1 expects 1226 bytes.
  Recent wlconf (git://git.ti.com/wilink8-wlan/18xx-ti-utils.git)
  produces 1229 bytes files.
 
  How should I determine correct wlconf version?
 
  I also complained about something along these lines earlier, this is
  not how upstream drivers are supposed to work. Users should not be
  forced to find correct files from somewhere, instead everything should
  just work out of box.
 
  Can anyone help Yegor to solve his problem? But in the long run wl18xx
  really should manage this better.
 
 I could solve the problem, though for the future it should be clear, what 
 wlconf
 version to use.
 
 See my post here:
 http://e2e.ti.com/support/wireless_connectivity/f/307/p/426229/1523235#152
 3235
 
 Yegor
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i