* [PATCH 0/3] ath10k mesh support
@ 2015-08-16 15:25 Bob Copeland
2015-08-16 15:25 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Bob Copeland @ 2015-08-16 15:25 UTC (permalink / raw)
To: ath10k; +Cc: Bob Copeland
Hi,
This patchset implements mesh support for ath10k. In the end there aren't
too many changes required now that raw mode is upstream.
When the module is loaded with (newly implemented) modparam rawmode=1, it
will enable operating an open mesh STA via something like the following:
if=wlan0
meship=10.10.1.10
ip link set $if down
ip addr flush $if
iw dev $if set type mp
ip link set $if up
ip addr add $meship/24 dev $if
iw dev $if set freq 5745 80 5775
iw dev $if mesh join mesh-vht
Prerequisites:
* latest mac80211-next is needed to ensure that a valid AID is supplied with
stations, without which firmware will crash.
* another mac80211 patch is needed to enable VHT mesh; I'll be sending this
separately to linux-wireless, but you can find it here:
http://bobcopeland.com/kernel/wl/20150816/
Notes:
* Even with 80 MHz VHT enabled, performance is not great: I get about 65 Mbps
OTA. It looks like we only send 1 frame per a-mpdu; any thoughts on how
to fix would be welcome.
* I'm not crazy about requiring a modparam and advertising mesh interfaces
that are only really usable when the modparam is set, but I'm not sure how
to set rx decap mode on the fly and whether we can do that on a per-vif
basis.
* monitor vdev for getting all multicasts is a bit heavy handed, would
be nice if there was something like ath9k's all mcast filter flag.
Bob Copeland (3):
ath10k: enable monitor when OTHER_BSS requested
ath10k: check for encryption before adding MIC_LEN
ath10k: implement mesh support
drivers/net/wireless/ath/ath10k/core.c | 6 ++++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 3 ++-
drivers/net/wireless/ath/ath10k/mac.c | 34 +++++++++++++++++++++++++++-----
3 files changed, 37 insertions(+), 6 deletions(-)
--
2.1.4
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested 2015-08-16 15:25 [PATCH 0/3] ath10k mesh support Bob Copeland @ 2015-08-16 15:25 ` Bob Copeland 2015-08-16 15:25 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland ` (2 subsequent siblings) 3 siblings, 0 replies; 10+ messages in thread From: Bob Copeland @ 2015-08-16 15:25 UTC (permalink / raw) To: ath10k; +Cc: Bob Copeland By default, ath10k restricts received frames to those matching BSSID. When other BSS frames are requested (e.g. in mesh mode), add an internal monitor device so those frames are not filtered. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 96f4285..5c85896 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1050,6 +1050,7 @@ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar) return false; return ar->monitor || + ar->filter_flags & FIF_OTHER_BSS || test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags); } -- 2.1.4 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN 2015-08-16 15:25 [PATCH 0/3] ath10k mesh support Bob Copeland 2015-08-16 15:25 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland @ 2015-08-16 15:25 ` Bob Copeland 2015-08-16 15:25 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2015-08-18 11:50 ` [PATCH 0/3] ath10k mesh support Kalle Valo 3 siblings, 0 replies; 10+ messages in thread From: Bob Copeland @ 2015-08-16 15:25 UTC (permalink / raw) To: ath10k; +Cc: Bob Copeland In the case of raw mode without nohwcrypt parameter, we should still make sure the frame is protected before adding MIC_LEN to avoid skb_under_panic errors. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/htt_tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c index 704bb5e..e0075cf 100644 --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -526,7 +526,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu) ieee80211_has_protected(hdr->frame_control)) { skb_put(msdu, IEEE80211_CCMP_MIC_LEN); } else if (!skb_cb->htt.nohwcrypt && - skb_cb->txmode == ATH10K_HW_TXRX_RAW) { + skb_cb->txmode == ATH10K_HW_TXRX_RAW && + ieee80211_has_protected(hdr->frame_control)) { skb_put(msdu, IEEE80211_CCMP_MIC_LEN); } -- 2.1.4 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 3/3] ath10k: implement mesh support 2015-08-16 15:25 [PATCH 0/3] ath10k mesh support Bob Copeland 2015-08-16 15:25 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland 2015-08-16 15:25 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland @ 2015-08-16 15:25 ` Bob Copeland 2015-08-17 11:06 ` Unable to set channel above 100 with latest CT Kernel and Firmware Harms, Hannes 2015-08-18 11:50 ` [PATCH 0/3] ath10k mesh support Kalle Valo 3 siblings, 1 reply; 10+ messages in thread From: Bob Copeland @ 2015-08-16 15:25 UTC (permalink / raw) To: ath10k; +Cc: Bob Copeland Add support for mesh to ath10k. We simply use an AP virtual interface in the firmware in order to enable beaconing without TSF adoption, and use the raw (802.11) transmit mode. Due to firmware limitations, the firmware must operate in raw (non-native 802.11) mode. As this is configured at firmware init time, a new "rawmode" modparam is added, and mesh interfaces are available only if rawmode=true. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/core.c | 6 ++++++ drivers/net/wireless/ath/ath10k/mac.c | 33 ++++++++++++++++++++++++++++----- 2 files changed, 34 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 2551067..e176bb4 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -34,16 +34,19 @@ unsigned int ath10k_debug_mask; static unsigned int ath10k_cryptmode_param; static bool uart_print; static bool skip_otp; +static bool rawmode; module_param_named(debug_mask, ath10k_debug_mask, uint, 0644); module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644); module_param(uart_print, bool, 0644); module_param(skip_otp, bool, 0644); +module_param(rawmode, bool, 0644); MODULE_PARM_DESC(debug_mask, "Debugging mask"); MODULE_PARM_DESC(uart_print, "Uart target debugging"); MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode"); MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software"); +MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath"); static const struct ath10k_hw_params ath10k_hw_params_list[] = { { @@ -1101,6 +1104,9 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar) ar->htt.max_num_amsdu = ATH10K_HTT_MAX_NUM_AMSDU_DEFAULT; ar->htt.max_num_ampdu = ATH10K_HTT_MAX_NUM_AMPDU_DEFAULT; + if (rawmode) + set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags); + if (test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) { ar->wmi.rx_decap_mode = ATH10K_HW_TXRX_RAW; diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 5c85896..72b0589 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4153,6 +4153,14 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, case NL80211_IFTYPE_ADHOC: arvif->vdev_type = WMI_VDEV_TYPE_IBSS; break; + case NL80211_IFTYPE_MESH_POINT: + if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) { + ret = -EINVAL; + ath10k_warn(ar, "must load driver with rawmode=1 to add mesh interfaces\n"); + goto err; + } + arvif->vdev_type = WMI_VDEV_TYPE_AP; + break; case NL80211_IFTYPE_AP: arvif->vdev_type = WMI_VDEV_TYPE_AP; @@ -4193,6 +4201,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, * become corrupted, e.g. have garbled IEs or out-of-date TIM bitmap. */ if (vif->type == NL80211_IFTYPE_ADHOC || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_AP) { arvif->beacon_buf = dma_zalloc_coherent(ar->dev, IEEE80211_MAX_FRAME_LEN, @@ -4527,6 +4536,13 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw, if (ret) ath10k_warn(ar, "failed to update beacon template: %d\n", ret); + + if (ieee80211_vif_is_mesh(vif)) { + /* mesh doesn't use SSID but firmware needs it */ + strncpy(arvif->u.ap.ssid, "mesh", + sizeof(arvif->u.ap.ssid)); + arvif->u.ap.ssid_len = 4; + } } if (changed & BSS_CHANGED_AP_PROBE_RESP) { @@ -5266,6 +5282,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_AUTH && new_state == IEEE80211_STA_ASSOC && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * New association. @@ -5301,6 +5318,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_ASSOC && new_state == IEEE80211_STA_AUTH && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * Disassociation. @@ -6614,14 +6632,16 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = { }, { .max = 7, - .types = BIT(NL80211_IFTYPE_AP) + .types = BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT) }, }; static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = { { .max = 8, - .types = BIT(NL80211_IFTYPE_AP) + .types = BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT) }, }; @@ -6660,7 +6680,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = { .max = 2, .types = BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_P2P_CLIENT) | - BIT(NL80211_IFTYPE_P2P_GO), + BIT(NL80211_IFTYPE_P2P_GO) | + BIT(NL80211_IFTYPE_MESH_POINT) }, { .max = 1, @@ -6680,7 +6701,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = { { .max = 1, .types = BIT(NL80211_IFTYPE_AP) | - BIT(NL80211_IFTYPE_P2P_GO), + BIT(NL80211_IFTYPE_P2P_GO) | + BIT(NL80211_IFTYPE_MESH_POINT), }, { .max = 1, @@ -6970,7 +6992,8 @@ int ath10k_mac_register(struct ath10k *ar) ar->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) | - BIT(NL80211_IFTYPE_AP); + BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT); ar->hw->wiphy->available_antennas_rx = ar->supp_rx_chainmask; ar->hw->wiphy->available_antennas_tx = ar->supp_tx_chainmask; -- 2.1.4 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Unable to set channel above 100 with latest CT Kernel and Firmware 2015-08-16 15:25 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland @ 2015-08-17 11:06 ` Harms, Hannes 2015-08-18 11:54 ` Kalle Valo 0 siblings, 1 reply; 10+ messages in thread From: Harms, Hannes @ 2015-08-17 11:06 UTC (permalink / raw) To: ath10k Hi, I am trying to set up the latest Kernel (4.2rc6) and firmware (10.1.467-ct-14) form Candela for a 5Ghz network. Unfortunately I am not able to set channels above 100, although regulatory domain is set to DE. Maybe someone has an advice what is going wrong? Regards Hannes My configuration: Debian with Kernel 4.2-rc6 form Candela (self compiled) Firmware: 10.1.467-ct-14 iw reg get country DE: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20), (N/A) (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS (57000 - 66000 @ 2160), (N/A, 40), (N/A) iw list Frequencies: * 5180 MHz [36] (17.0 dBm) * 5200 MHz [40] (17.0 dBm) * 5220 MHz [44] (17.0 dBm) * 5240 MHz [48] (17.0 dBm) * 5260 MHz [52] (20.0 dBm) (no IR, radar detection) DFS state: usable (for 550 sec) DFS CAC time: 60000 ms * 5280 MHz [56] (20.0 dBm) (no IR, radar detection) DFS state: usable (for 550 sec) DFS CAC time: 60000 ms * 5300 MHz [60] (20.0 dBm) (no IR, radar detection) DFS state: usable (for 550 sec) DFS CAC time: 60000 ms * 5320 MHz [64] (20.0 dBm) (no IR, radar detection) DFS state: usable (for 550 sec) DFS CAC time: 60000 ms * 5500 MHz [100] (disabled) * 5520 MHz [104] (disabled) * 5540 MHz [108] (disabled) * 5560 MHz [112] (disabled) * 5580 MHz [116] (disabled) * 5600 MHz [120] (disabled) * 5620 MHz [124] (disabled) * 5640 MHz [128] (disabled) * 5660 MHz [132] (disabled) * 5680 MHz [136] (disabled) * 5700 MHz [140] (disabled) * 5720 MHz [144] (disabled) * 5745 MHz [149] (disabled) * 5765 MHz [153] (disabled) * 5785 MHz [157] (disabled) * 5805 MHz [161] (disabled) * 5825 MHz [165] (disabled) _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unable to set channel above 100 with latest CT Kernel and Firmware 2015-08-17 11:06 ` Unable to set channel above 100 with latest CT Kernel and Firmware Harms, Hannes @ 2015-08-18 11:54 ` Kalle Valo 2015-08-18 14:52 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Kalle Valo @ 2015-08-18 11:54 UTC (permalink / raw) To: Harms, Hannes; +Cc: ath10k "Harms, Hannes" <hannes.harms@tu-bs.de> writes: > I am trying to set up the latest Kernel (4.2rc6) and firmware > (10.1.467-ct-14) form Candela for a 5Ghz network. > Unfortunately I am not able to set channels above 100, although > regulatory domain is set to DE. > Maybe someone has an advice what is going wrong? Btw, please don't hijack threads (ie. reply to an existing thread and change subject) as it confuses patchwork[1]. Instead start a new thread. [1] https://patchwork.kernel.org/patch/7023511/ -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unable to set channel above 100 with latest CT Kernel and Firmware 2015-08-18 11:54 ` Kalle Valo @ 2015-08-18 14:52 ` Ben Greear 0 siblings, 0 replies; 10+ messages in thread From: Ben Greear @ 2015-08-18 14:52 UTC (permalink / raw) To: Kalle Valo, Harms, Hannes; +Cc: ath10k On 08/18/2015 04:54 AM, Kalle Valo wrote: > "Harms, Hannes" <hannes.harms@tu-bs.de> writes: > >> I am trying to set up the latest Kernel (4.2rc6) and firmware >> (10.1.467-ct-14) form Candela for a 5Ghz network. >> Unfortunately I am not able to set channels above 100, although >> regulatory domain is set to DE. >> Maybe someone has an advice what is going wrong? This is unlikely to be a firmware issue, as we routinely run on channel 149. Have you tried an older kernel to see if it is a regression somewhere in the stack/driver? Thanks, Ben > > Btw, please don't hijack threads (ie. reply to an existing thread and > change subject) as it confuses patchwork[1]. Instead start a new thread. > > [1] https://patchwork.kernel.org/patch/7023511/ > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] ath10k mesh support 2015-08-16 15:25 [PATCH 0/3] ath10k mesh support Bob Copeland ` (2 preceding siblings ...) 2015-08-16 15:25 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland @ 2015-08-18 11:50 ` Kalle Valo 2015-08-18 12:42 ` Bob Copeland 3 siblings, 1 reply; 10+ messages in thread From: Kalle Valo @ 2015-08-18 11:50 UTC (permalink / raw) To: Bob Copeland; +Cc: ath10k Bob Copeland <me@bobcopeland.com> writes: > This patchset implements mesh support for ath10k. In the end there aren't > too many changes required now that raw mode is upstream. > > When the module is loaded with (newly implemented) modparam rawmode=1, it > will enable operating an open mesh STA via something like the following: > > if=wlan0 > meship=10.10.1.10 > ip link set $if down > ip addr flush $if > iw dev $if set type mp > ip link set $if up > ip addr add $meship/24 dev $if > iw dev $if set freq 5745 80 5775 > iw dev $if mesh join mesh-vht Can you add this example to patch 3, please? Also mention in patch 3 what firmware version you used to test this. Oh, but I haven't made a firmware release with RAW_MODE flag set. Need to do that. > Prerequisites: > > * latest mac80211-next is needed to ensure that a valid AID is supplied with > stations, without which firmware will crash. > > * another mac80211 patch is needed to enable VHT mesh; I'll be sending this > separately to linux-wireless, but you can find it here: > > http://bobcopeland.com/kernel/wl/20150816/ > > Notes: > * Even with 80 MHz VHT enabled, performance is not great: I get about 65 Mbps > OTA. It looks like we only send 1 frame per a-mpdu; any thoughts on how > to fix would be welcome. > > * I'm not crazy about requiring a modparam and advertising mesh interfaces > that are only really usable when the modparam is set, but I'm not sure how > to set rx decap mode on the fly and whether we can do that on a per-vif > basis. This is good enough for now, but I would prefer that we advertise mesh support to user space only when the rawmode modparam is set. I guess we should start building all iface_limits dynamically? But that's future cleanup. This looks good to me, I'll just wait that mac80211-next trickles down to ath.git. But before that can you resend and also CC linux-wireless so that this gets wider review? -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] ath10k mesh support 2015-08-18 11:50 ` [PATCH 0/3] ath10k mesh support Kalle Valo @ 2015-08-18 12:42 ` Bob Copeland 2015-08-18 16:04 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Bob Copeland @ 2015-08-18 12:42 UTC (permalink / raw) To: Kalle Valo; +Cc: ath10k On Tue, Aug 18, 2015 at 02:50:20PM +0300, Kalle Valo wrote: > Bob Copeland <me@bobcopeland.com> writes: > > > > if=wlan0 > > meship=10.10.1.10 > > ip link set $if down > > ip addr flush $if > > iw dev $if set type mp > > ip link set $if up > > ip addr add $meship/24 dev $if > > iw dev $if set freq 5745 80 5775 > > iw dev $if mesh join mesh-vht > > Can you add this example to patch 3, please? Also mention in patch 3 > what firmware version you used to test this. Oh, but I haven't made a > firmware release with RAW_MODE flag set. Need to do that. Sure -- yes I guess this patch is also missing a check for the firmware feature flag (although it works on 10.2.4.70-2 apparently) -- will add once you do such a release. > > * I'm not crazy about requiring a modparam and advertising mesh interfaces > > that are only really usable when the modparam is set, but I'm not sure how > > to set rx decap mode on the fly and whether we can do that on a per-vif > > basis. > > This is good enough for now, but I would prefer that we advertise mesh > support to user space only when the rawmode modparam is set. I guess we > should start building all iface_limits dynamically? But that's future > cleanup. I started down this path originally, but "it's complicated." There's a bit of a combinatorial explosion problem since there are already 4 different if_limits with different combinations. I guess we could iterate over them and set the bits just before calling into mac80211, but we'd need to cast away a const or two. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] ath10k mesh support 2015-08-18 12:42 ` Bob Copeland @ 2015-08-18 16:04 ` Ben Greear 0 siblings, 0 replies; 10+ messages in thread From: Ben Greear @ 2015-08-18 16:04 UTC (permalink / raw) To: Bob Copeland; +Cc: Kalle Valo, ath10k On 08/18/2015 05:42 AM, Bob Copeland wrote: > On Tue, Aug 18, 2015 at 02:50:20PM +0300, Kalle Valo wrote: >> Bob Copeland <me@bobcopeland.com> writes: >>> >>> if=wlan0 >>> meship=10.10.1.10 >>> ip link set $if down >>> ip addr flush $if >>> iw dev $if set type mp >>> ip link set $if up >>> ip addr add $meship/24 dev $if >>> iw dev $if set freq 5745 80 5775 >>> iw dev $if mesh join mesh-vht >> >> Can you add this example to patch 3, please? Also mention in patch 3 >> what firmware version you used to test this. Oh, but I haven't made a >> firmware release with RAW_MODE flag set. Need to do that. > > Sure -- yes I guess this patch is also missing a check for the firmware > feature flag (although it works on 10.2.4.70-2 apparently) -- will add > once you do such a release. > >>> * I'm not crazy about requiring a modparam and advertising mesh interfaces >>> that are only really usable when the modparam is set, but I'm not sure how >>> to set rx decap mode on the fly and whether we can do that on a per-vif >>> basis. >> >> This is good enough for now, but I would prefer that we advertise mesh >> support to user space only when the rawmode modparam is set. I guess we >> should start building all iface_limits dynamically? But that's future >> cleanup. > > I started down this path originally, but "it's complicated." There's a > bit of a combinatorial explosion problem since there are already 4 > different if_limits with different combinations. I guess we could > iterate over them and set the bits just before calling into mac80211, > but we'd need to cast away a const or two. I've been carrying a patch in my kernel that makes the limits non-const, but it was not wanted upstream. Building the limits dynamically in ath10k, by casting as needed, seems fine to me, and it would help support additional features that I use in CT firmware, like module params to tune the number of vdevs, peers, etc. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-08-18 16:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-16 15:25 [PATCH 0/3] ath10k mesh support Bob Copeland 2015-08-16 15:25 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland 2015-08-16 15:25 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland 2015-08-16 15:25 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2015-08-17 11:06 ` Unable to set channel above 100 with latest CT Kernel and Firmware Harms, Hannes 2015-08-18 11:54 ` Kalle Valo 2015-08-18 14:52 ` Ben Greear 2015-08-18 11:50 ` [PATCH 0/3] ath10k mesh support Kalle Valo 2015-08-18 12:42 ` Bob Copeland 2015-08-18 16:04 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.