p;local->chanctx_mtx){+.+.}, at:
ieee80211_csa_finalize_work+0x51/0x90
Signed-off-by: Thomas Pedersen
---
v2: rcu_read_lock() doesn't make sense. Use rcu_dereference_protected()
(Johannes)
---
net/mac80211/mesh.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ne
On Fri, May 24, 2019 at 1:29 AM Johannes Berg wrote:
>
> On Wed, 2019-05-15 at 15:21 -0700, Thomas Pedersen wrote:
> > ifmsh->csa was being dereferenced without the RCU read
> > lock held.
>
> > +++ b/net/mac80211/mesh.c
> > @@ -1220,10 +1220,12 @@
On Wed, May 15, 2019 at 3:21 PM Thomas Pedersen wrote:
>
> ifmsh->csa was being dereferenced without the RCU read
> lock held.
>
> fixes the following warning:
>
> [ 74.930435] =
> [ 74.932066] WARNING: suspicious RCU usage
> [ 74
k+0x2f/0x90
[ 74.959870] #3: e6855095 (&local->mtx){+.+.}, at:
ieee80211_csa_finalize_work+0x47/0x90
[ 74.962937] #4: bb5e3bca (&local->chanctx_mtx){+.+.}, at:
ieee80211_csa_finalize_work+0x51/0x90
Signed-off-by: Thomas Pedersen
---
net/mac80211/mesh.c | 2 ++
Hello,
I'm working on defining new channels for S1G PHYs in mac80211. These
are in the 900MHz range and center frequency for the 1MHz channels are
on a half MHz, while the existing channel definitions are in units of
MHz.
In order to support the new channels we could change the internal
center fr
t;if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
>netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO)
> return -EINVAL;
>...
> }
>
> Best Regards
> Phan
On Thu, Mar 1, 2018 at 7:27 AM, Phani Siriki wrote:
> Hi All
>
> I am trying to understand the queuing mechanism wireless mesh networks.
>
> As per AP mode is concerned, there are four queues (BK, BE, Vi, VO)
> and traffic is controlled based on CWmin, CWmax, AIFS and TxOP.
>
> Does, mesh mode als
On Tue, Dec 19, 2017 at 2:05 AM, Johannes Berg
wrote:
> On Mon, 2017-12-18 at 03:44 +0100, Gui Iribarren wrote:
>> Steps to reproduce:
>> join a 802.11s mesh with a nodeA, and then join the same 802.11s mesh
>> with another nodeB, so that both nodes MAC addresses are exactly the
>> same (i.e. node
Thanks Chun-Yeow, this is a good change.
On Tue, Nov 14, 2017 at 7:20 AM, Chun-Yeow Yeoh wrote:
> The previous path metric update from RANN frame has not considered
> the own link metric toward the transmitting mesh STA. Fix this.
>
> Reported-by: Michael65535
> Signed-off-by: Chun-Yeow Yeoh
> -
On Mon, Sep 4, 2017 at 6:19 AM, Johannes Berg wrote:
> On Fri, 2017-09-01 at 13:07 -0700, Thomas Pedersen wrote:
>> On Thu, Aug 31, 2017 at 11:30 PM, Greg Maitz
>> wrote:
>> > Hi guys,
>> >
>> > I'm seeing a problem when I work on the wireless mes
On Thu, Aug 31, 2017 at 11:30 PM, Greg Maitz wrote:
> Hi guys,
>
> I'm seeing a problem when I work on the wireless mesh between two
> linux devices. The root node has 3.18 kernel while the next hop
> station runs 2.6.37 kernel. I found the mpath->sn value is incorrect
> most of the time on the de
On Thu, Mar 2, 2017 at 9:41 AM, Jesse Jones wrote:
>> Hi Alexis,
>>
>> > This is loosely based on RFC5148, specifically event-triggered message
>> > generation as described in section 5.2.
>>
>> I'm confused. I see how that generally seems to apply to any mobile
>> network, but it *does* state up-
On Tue, Jan 31, 2017 at 11:33 AM, Rajkumar Manoharan
wrote:
> On 2017-01-31 09:51, Thomas Pedersen wrote:
>>
>> Hi Rajkumar,
>>
>> Thanks this looks good, but..
>>
>> On Fri, Jan 27, 2017 at 4:01 PM, Rajkumar Manoharan
>> wrote:
>>>
>>
Hi Rajkumar,
Thanks this looks good, but..
On Fri, Jan 27, 2017 at 4:01 PM, Rajkumar Manoharan
wrote:
> Mesh moving average should be cleared, whenever mesh paths
> to the given station are deactivated due to bad link. This will
> give enough room to analysis more tx status than retaining the
>
On Fri, Dec 2, 2016 at 10:59 PM, Masashi Honma wrote:
> On 2016/12/03 06:13, Bob Copeland wrote:
>>
>> On Fri, Dec 02, 2016 at 12:07:18PM -0800, Thomas Pedersen wrote:
>
>
> # Rejected by linux wireless ML. This is resubmission.
>
> thomas and Bob, Thanks
On Wed, Nov 30, 2016 at 2:44 PM, Masashi Honma wrote:
> mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
> framework ([1] 13.13.2 Extensible synchronization framework). It shall
> not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
> Capability), since it is us
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't defined. To get more meaningful value
than 0 out of this however, just extrapolate a bitrate
from ratio of MCS 7 and 9 in channels where it is allowed.
Signed-off-by: Thomas Pedersen
---
v2: add MCS 9 bitrate instead of ca
o not mislead the stack and hopefully avoid future
bugs.
Tested on QCA4019 with firmware 10.4-3.2.1-0033. After this change
Toffset remains stable to within 5us.
Thomas Pedersen (4):
mac80211: add offset_tsf driver op
ath10k: implement offset_tsf ieee80211_op
ath10k: remove set/ge
ange max drift adjustment to 0.8ms, so manual TSF
adjustments can be made in 1ms increments, with some
margin.
Signed-off-by: Thomas Pedersen
---
net/mac80211/mesh_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index
l TSF).
The new WMI command is available in firmware
10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
firmware or vice versa shouldn't be a problem since
get/set tsf logic was already broken.
Signed-off-by: Thomas Pedersen
---
drivers/net/wireless/ath/ath10k/
/decrement in the future if get_tsf
is ever supported by FW.
Signed-off-by: Thomas Pedersen
---
drivers/net/wireless/ath/ath10k/mac.c | 38 ---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 -
drivers/net/wireless/ath/ath10k/wmi.c | 4
drivers/net/wireless
Allows ie. mesh sync code to make incremental TSF
adjustments, avoiding any uncertainty introduced by delay
in programming absolute TSF.
Signed-off-by: Thomas Pedersen
---
include/net/mac80211.h| 8
net/mac80211/debugfs_netdev.c | 12 +---
net/mac80211/driver-ops.c
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't defined. To get more meaningful value
than 0 out of this however, just extrapolate a bitrate
from ratio of MCS 7 and 9 in channels where it is allowed.
Signed-off-by: Thomas Pedersen
---
v2: add MCS 9 bitrate instead of ca
don't mind losing out on
peer stats, they can still disable them:
echo 0 > debugfs/ieee80211/phyn/ath10k/peer_stats
Signed-off-by: Thomas Pedersen
---
drivers/net/wireless/ath/ath10k/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/dri
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't allowed. To get more meaningful value
than 0 out of this however, just cap the bitrate for 20MHz
to MCS 8.
Signed-off-by: Thomas Pedersen
---
net/wireless/util.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
mpath. Just assign PATH_FIXED and SN_VALID.
This solves several issues when fixing a mesh path in one
direction. The reverse direction mpath should probably
also be fixed, or root announcements at least be enabled.
Signed-off-by: Thomas Pedersen
---
net/mac80211/mesh_hwmp.c| 3 ++-
net/mac80211
Hi Kenzoh,
Looks like your email is part HTML. Please submit using git-send-email.
Your patch looks ok, just a small comment below.
On 11/12/2014 08:27 PM, Nishikawa, Kenzoh via Devel wrote:
> net/mac80211/mesh_plink.c |6 ++
> 1 file changed, 6 insertions(+)
> diff --git a/net/mac80211/m
On Tue, Sep 9, 2014, at 06:26 AM, John W. Linville wrote:
> On Tue, Sep 09, 2014 at 12:28:54PM +0200, Arend van Spriel wrote:
> > + linux-wireless
> >
> > On 09/09/14 12:22, chandrika parimoo wrote:
> > >Hello,
> > >
> > >I have broadcom bcm4313 card and am using brcmsmac driver which does not
> >
28 matches
Mail list logo
