[PATCH v2] cfg80211: Advertise extended capabilities per interface type to userspace

2016-05-15 Thread Kanchanapally, Vidyullatha
From: "Kanchanapally, Vidyullatha" The driver extended capabilities may differ for different interface types which the userspace needs to know (for example the fine timing measurement initiator and responder bits might differ for a station and AP). Add a new nl80211 attribute to provide extended

Re: wifi driver crashes openwrt device

2016-05-15 Thread Bob Copeland
On Tue, May 10, 2016 at 03:17:25PM +, andy wrote: > hello, every body. > I developed an openwrt device based on git clone > git://git.openwrt.org/15.05/openwrt.git. > I found that my device rebooted during wifi initializing sometimes, maybe > one in twenty. > The wifi driver is compat-

[PATCH v2] mac80211: mesh: flush mesh paths unconditionally

2016-05-15 Thread Bob Copeland
Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flu

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-15 Thread Rafał Miłecki
Hi, Unfortunately your patch is malformed and I couldn't apply it locally. It seems your mailer broke lines longer than 80 chars and there are some wrong indents in the description. After fixing up some line break I got following commit in my git log: Author: Adrian Chadd Date: Sun May 15 07:2

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-15 Thread Adrian Chadd
On 15 May 2016 at 07:39, Michael Büsch wrote: > On Sun, 15 May 2016 07:23:25 -0700 > Adrian Chadd wrote: > >> @@ -438,7 +446,7 @@ int b43_generate_txhdr(struct b43_wldev *dev, >> >> rts_rate = rts_cts_rate ? rts_cts_rate->hw_value : >> B43_CCK_RATE_1MB; > > I just noticed that thi

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-15 Thread Michael Büsch
On Sun, 15 May 2016 07:23:25 -0700 Adrian Chadd wrote: > @@ -438,7 +446,7 @@ int b43_generate_txhdr(struct b43_wldev *dev, > > rts_rate = rts_cts_rate ? rts_cts_rate->hw_value : > B43_CCK_RATE_1MB; I just noticed that this is incorrect for 5GHz, too. Maybe there are more such bu

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-15 Thread Michael Büsch
On Sun, 15 May 2016 07:23:25 -0700 Adrian Chadd wrote: > Author: Adrian Chadd > Date: Sun May 15 07:15:54 2016 -0700 > > [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM. > > Check the current PHY operating mode (gmode) to see if we should > fall back from 6MB

[b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-15 Thread Adrian Chadd
Author: Adrian Chadd Date: Sun May 15 07:15:54 2016 -0700 [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM. Check the current PHY operating mode (gmode) to see if we should fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this isn't allowed. Not

Re: [PATCH] mac80211: mesh: flush mesh paths early in sta destroy

2016-05-15 Thread Bob Copeland
On Sat, May 14, 2016 at 08:54:13PM +0200, Felix Fietkau wrote: > > + WLAN_STA_BLOCK_MPATH, > I think this flag needs to be added to sta_flag_names in debugfs_sta.c On further reflection, using a flag for this is racy anyway, even if quite narrow. Maybe I should just flush in part2 unconditional