| Message ID | 1440673024-13696-4-git-send-email-me@bobcopeland.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
On Thu, Aug 27, 2015 at 6:57 AM, Bob Copeland <me@bobcopeland.com> wrote: > @@ -1117,6 +1120,15 @@ 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) { > + if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT, > + ar->fw_features)) { > + ath10k_err(ar, "rawmode = 1 requires support from firmware"); > + return -EINVAL; > + } > + set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags); > + } > + Is there a reason to hide rawmode behind a modparam, or should the modparam just be removed? Just let the driver set ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is detected? > @@ -6708,7 +6729,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, Does struct ieee80211_iface_limit need to be conditional on firmware support as well or does interface_modes (below) gate use of MESH_POINT? > @@ -6998,7 +7020,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); Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? Regards, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Aug 29, 2015 at 01:11:03PM -0400, Jason Andryuk wrote: > Is there a reason to hide rawmode behind a modparam, or should the > modparam just be removed? Just let the driver set > ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is > detected? Yes: you don't want to enable raw mode TX / RX decap in the normal case because it's fairly inefficient compared to "native" wifi mode, according to my understanding. The latter doesn't support mesh framing however. > Does struct ieee80211_iface_limit need to be conditional on firmware > support as well or does interface_modes (below) gate use of > MESH_POINT? If you advertise a combination that isn't supported by interface modes, I believe you'll get a kernel warning when the wiphy is registered. > > > @@ -6998,7 +7020,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); > > Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? Yes, this was discussed on the ath10k mailing list and I'll probably do it in a follow-up patch. It is a little messy because it will involve casting away a const somewhere.
Hi, Bob > Yes: you don't want to enable raw mode TX / RX decap in the normal > case because it's fairly inefficient compared to "native" wifi mode, > according to my understanding. The latter doesn't support mesh framing > however. > The native WiFi mode doesn't support mesh framing. Can you elaborate more on this? Thanks ---- Chun-Yeow -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Aug 29, 2015 at 6:25 PM, Bob Copeland <me@bobcopeland.com> wrote: > On Sat, Aug 29, 2015 at 01:11:03PM -0400, Jason Andryuk wrote: >> Is there a reason to hide rawmode behind a modparam, or should the >> modparam just be removed? Just let the driver set >> ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is >> detected? > > Yes: you don't want to enable raw mode TX / RX decap in the normal > case because it's fairly inefficient compared to "native" wifi mode, > according to my understanding. The latter doesn't support mesh framing > however. > >> Does struct ieee80211_iface_limit need to be conditional on firmware >> support as well or does interface_modes (below) gate use of >> MESH_POINT? > > If you advertise a combination that isn't supported by interface modes, > I believe you'll get a kernel warning when the wiphy is registered. > >> >> > @@ -6998,7 +7020,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); >> >> Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? > > Yes, this was discussed on the ath10k mailing list and I'll probably do > it in a follow-up patch. It is a little messy because it will involve > casting away a const somewhere. Great. Glad you've already considered all these things. -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bob Copeland <me@bobcopeland.com> writes: > 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. The firmware must advertise support for rawmode > (tested successfully with firmware 10.2.4.70-2). > > When loaded with rawmode=1, ath10k can operate an open mesh STA via > something like the following: > > ip link set wlan0 down > iw dev wlan0 set type mp > ip link set wlan0 up > iw dev wlan0 set freq 5745 80 5775 > iw dev wlan0 mesh join mesh-vht > > Signed-off-by: Bob Copeland <me@bobcopeland.com> I did a quick smoke test and saw the splat below. It's this warning from cfg80211: /* * Don't advertise an unsupported type * in a combination. */ if (WARN_ON((wiphy->interface_modes & types) != types)) return -EINVAL; I didn't immeaditely figure out what's causing this, the interface types looked correct to me. Unfortunately I don't have time to investigate more at the moment, but will look later. [ 152.113232] ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70.6 api 3 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p [ 152.113448] ath10k_pci 0000:02:00.0: debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 [ 152.226213] ath: EEPROM regdomain: 0x0 [ 152.226296] ath: EEPROM indicates default country code should be used [ 152.226365] ath: doing EEPROM country->regdmn map search [ 152.226434] ath: country maps to regdmn code: 0x3a [ 152.226504] ath: Country alpha2 being used: US [ 152.226573] ath: Regpair used: 0x3a [ 152.226677] ------------[ cut here ]------------ [ 152.226785] WARNING: CPU: 0 PID: 1141 at net/wireless/core.c:530 wiphy_register+0x680/0x780 [cfg80211]() [ 152.226864] Modules linked in: ath10k_pci ath10k_core ath mac80211 cfg80211 [last unloaded: cfg80211] [ 152.227882] CPU: 0 PID: 1141 Comm: kworker/u16:5 Not tainted 4.2.0-wl-ath+ #1044 [ 152.227972] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 152.228068] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 152.228372] 00000000 00000000 f1c19d08 c18c0e4e 00000000 f1c19d38 c10578ce c1b0f660 [ 152.229343] 00000000 00000475 fb37017a 00000212 fb317130 fb317130 00000088 efe48320 [ 152.230500] 00000008 f1c19d48 c1057932 00000009 00000000 f1c19dac fb317130 f1c10008 [ 152.231541] Call Trace: [ 152.231634] [<c18c0e4e>] dump_stack+0x48/0x60 [ 152.231824] [<c10578ce>] warn_slowpath_common+0x8e/0xd0 [ 152.232014] [<fb317130>] ? wiphy_register+0x680/0x780 [cfg80211] [ 152.232232] [<fb317130>] ? wiphy_register+0x680/0x780 [cfg80211] [ 152.232448] [<c1057932>] warn_slowpath_null+0x22/0x30 [ 152.232561] [<fb317130>] wiphy_register+0x680/0x780 [cfg80211] [ 152.232657] [<c11a3926>] ? __kmalloc+0x216/0x370 [ 152.232749] [<c10acd69>] ? mark_held_locks+0x59/0x80 [ 152.232898] [<fbfcb3d0>] ? ieee80211_register_hw+0x1f0/0x970 [mac80211] [ 152.233468] [<fbfcb3d0>] ? ieee80211_register_hw+0x1f0/0x970 [mac80211] [ 152.233576] [<fc22c7d0>] ? ath10k_hw_scan+0x210/0x210 [ath10k_core] [ 152.233679] [<fc22c5c0>] ? ath10k_start_scan+0x140/0x140 [ath10k_core] [ 152.233794] [<fbfcb541>] ieee80211_register_hw+0x361/0x970 [mac80211] [ 152.233889] [<c1000f0c>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 152.233983] [<c18caef5>] ? restore_all+0xf/0xf [ 152.234084] [<fc22d973>] ath10k_mac_register+0x7c3/0x920 [ath10k_core] [ 152.234196] [<c10a66bc>] ? __lock_is_held+0x3c/0x50 [ 152.236050] [<fc234e61>] ath10k_core_register_work+0x5d1/0x6d0 [ath10k_core] [ 152.236136] [<c1070f00>] process_one_work+0x1d0/0x6c0 [ 152.236204] [<c1070e52>] ? process_one_work+0x122/0x6c0 [ 152.236270] [<c107150a>] worker_thread+0xea/0x3d0 [ 152.236335] [<c10acf5b>] ? trace_hardirqs_on+0xb/0x10 [ 152.236399] [<c1071420>] ? process_scheduled_works+0x30/0x30 [ 152.236466] [<c10773f5>] kthread+0xa5/0xc0 [ 152.236531] [<c18ca917>] ? _raw_spin_unlock_irq+0x27/0x40 [ 152.236596] [<c18cad01>] ret_from_kernel_thread+0x21/0x30 [ 152.236664] [<c1077350>] ? __init_kthread_worker+0x60/0x60 [ 152.236731] ---[ end trace ce831788c6a79cf8 ]--- [ 152.236813] ath10k_pci 0000:02:00.0: failed to register ieee80211: -22 [ 152.236889] ath10k_pci 0000:02:00.0: could not register to mac80211 (-22)
Kalle Valo <kvalo@qca.qualcomm.com> writes: > Bob Copeland <me@bobcopeland.com> writes: > >> 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. The firmware must advertise support for rawmode >> (tested successfully with firmware 10.2.4.70-2). >> >> When loaded with rawmode=1, ath10k can operate an open mesh STA via >> something like the following: >> >> ip link set wlan0 down >> iw dev wlan0 set type mp >> ip link set wlan0 up >> iw dev wlan0 set freq 5745 80 5775 >> iw dev wlan0 mesh join mesh-vht >> >> Signed-off-by: Bob Copeland <me@bobcopeland.com> > > I did a quick smoke test and saw the splat below. It's this warning from > cfg80211: > > /* > * Don't advertise an unsupported type > * in a combination. > */ > if (WARN_ON((wiphy->interface_modes & types) != types)) > return -EINVAL; Forgot to mention that this was with 10.2.4.70.6-2 (which has the raw feature bit set, will push it soon) but rawmode modparam not set. And I had applied your patches on top of ath.git master branch (commit d89281c7d6bb9).
On Wed, Sep 09, 2015 at 10:57:30AM +0300, Kalle Valo wrote: > I did a quick smoke test and saw the splat below. It's this warning from > cfg80211: > > /* > * Don't advertise an unsupported type > * in a combination. > */ > if (WARN_ON((wiphy->interface_modes & types) != types)) > return -EINVAL; > > I didn't immeaditely figure out what's causing this, the interface types > looked correct to me. Unfortunately I don't have time to investigate > more at the moment, but will look later. Doh! Yeah this warning is exactly why I marked it supported even if you couldn't use it due to missing rawmode support. Obviously I missed one of the cases, I'll take a look.
On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: > > I did a quick smoke test and saw the splat below. It's this warning from > > cfg80211: > > > > /* > > * Don't advertise an unsupported type > > * in a combination. > > */ > > if (WARN_ON((wiphy->interface_modes & types) != types)) > > return -EINVAL; OK, this happens when mesh is configured out (we mask off the mesh interface_modes internally but not the types). Sent an updated version with appropriate ifdefs added.
Bob Copeland <me@bobcopeland.com> writes: > On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: >> > I did a quick smoke test and saw the splat below. It's this warning from >> > cfg80211: >> > >> > /* >> > * Don't advertise an unsupported type >> > * in a combination. >> > */ >> > if (WARN_ON((wiphy->interface_modes & types) != types)) >> > return -EINVAL; > > OK, this happens when mesh is configured out (we mask off the mesh > interface_modes internally but not the types). Sent an updated version > with appropriate ifdefs added. Indeed, when I enabled CONFIG_MAC80211_MESH I didn't see the WARN_ON() anymore. (I haven't tested your latest version yet, will do it soon)
On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote: > On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: > > > I did a quick smoke test and saw the splat below. It's this > > > warning from > > > cfg80211: > > > > > > /* > > > * Don't advertise an unsupported type > > > * in a combination. > > > */ > > > if (WARN_ON((wiphy->interface_modes & > > > types) != types)) > > > return -EINVAL; > > OK, this happens when mesh is configured out (we mask off the mesh > interface_modes internally but not the types). Sent an updated > version with appropriate ifdefs added. Yeah this is an unfortunate quirk in the APIs ... I think adding the ifdefs to the driver is the best thing to do. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/10/2015 12:22 AM, Johannes Berg wrote: > On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote: >> On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: >>>> I did a quick smoke test and saw the splat below. It's this >>>> warning from >>>> cfg80211: >>>> >>>> /* >>>> * Don't advertise an unsupported type >>>> * in a combination. >>>> */ >>>> if (WARN_ON((wiphy->interface_modes & >>>> types) != types)) >>>> return -EINVAL; >> OK, this happens when mesh is configured out (we mask off the mesh >> interface_modes internally but not the types). Sent an updated >> version with appropriate ifdefs added. > Yeah this is an unfortunate quirk in the APIs ... I think adding the > ifdefs to the driver is the best thing to do. > > johannes Can we configure mesh point with hostapd or can we use mesh point without neither wpa_supplicant nor hostapd? Currently I'm trying to bring up mesh point, but whenever I run hostpad after creating mesh point (iw phy0 interface add mesh type mp), hostapd change the interface mode to managed. > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2015 at 12:21:35AM -0700, Peter Oh wrote: > Can we configure mesh point with hostapd or can we use mesh point without > neither wpa_supplicant nor hostapd? > Currently I'm trying to bring up mesh point, but whenever I run hostpad > after creating mesh point (iw phy0 interface add mesh type mp), hostapd > change the interface mode to managed. Hostapd can't control the mesh interface, but wpa_supplicant can, though I believe there's a little more work needed to support VHT for mesh in wpa_supplicant. If you want to run an unencrypted mesh, you can start it with iw and the kernel will run the peering manager. If you're asking about a mesh-enabled access point, you can run hostapd separately from wpa_supplicant/iw, as in the below script. (I've only tested that you can bring this up on ath10k, not actual operation, though it should work as far as I know. I've run similar scripts on ath9k.) #!/bin/bash -x # # Example of running a mesh-enabled access point with one radio. # killall hostapd > /dev/null killall wpa_supplicant > /dev/null pubip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}'` last8=`echo $pubip | awk -F . '{print $4}'` meship=10.10.1.$last8 iface=wlan0 ap_iface=ap0 br_iface=br0 mesh_mac=42:00:00:00:00:`printf "%.2x" $last8` channel=36 freq=5180 brctl delbr $br_iface brctl addbr $br_iface # add a new interface for ap operation iw dev $ap_iface del iw dev $iface interface add $ap_iface type managed ip addr flush $ap_iface ip link set $ap_iface down # create hostapd conf for ath10k cat <<__EOM > hostapd.conf interface=$ap_iface driver=nl80211 ssid=mesh-ap hw_mode=a channel=$channel auth_algs=3 own_ip_addr=$meship wpa=1 wpa_passphrase=my_password wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP ht_capab=[HT40+] ieee80211n=1 ieee80211ac=1 vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=$((channel + 6)) bridge=$br_iface __EOM # configure main interface to run in mesh mode ip addr flush $iface ip link set $iface down ip link set addr $mesh_mac dev $iface iw dev $iface set type mp ip link set $iface up # start the mesh # here you might instead run wpa_supplicant for an encrypted mesh iw dev $iface set freq $freq 80 $((freq + 30)) iw dev $iface mesh join mesh-vht sleep 5 # add mesh to bridge (hostapd adds AP interface to bridge) brctl addif $br_iface $iface ip addr add $meship/24 dev $br_iface ip link set $br_iface up # run hostapd hostapd -dd hostapd.conf >hostapd.log 2>&1 &
On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: > Hi, Bob > > > Yes: you don't want to enable raw mode TX / RX decap in the normal > > case because it's fairly inefficient compared to "native" wifi mode, > > according to my understanding. The latter doesn't support mesh framing > > however. > > > > The native WiFi mode doesn't support mesh framing. Can you elaborate > more on this? Sorry, missed this before -- the 'nwifi' mode which is the normal datapath for ath10k discards the QoS header and following mesh header when transmitting, if I recall correctly. I also had some issues with the received frames when using nwifi RX decap with raw mode TX, but I don't recall exactly the problem. I can retest with these modes if you really want the details.
Hi, Bob I have also tested with nwifi mode for non-secured mesh. It seems to be worked for me with the following two test scenarios: Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k] Node 1 [ath10k] <---> Node 2 [ath9k] I am using the following: compat-wireless-2015-07-21 from OpenWRT firmware-5.bin_10.2.4.70.6-2 I just wondering whether using raw wifi is better for encrypted mesh later? ---- Chun-Yeow On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland <me@bobcopeland.com> wrote: > On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: >> Hi, Bob >> >> > Yes: you don't want to enable raw mode TX / RX decap in the normal >> > case because it's fairly inefficient compared to "native" wifi mode, >> > according to my understanding. The latter doesn't support mesh framing >> > however. >> > >> >> The native WiFi mode doesn't support mesh framing. Can you elaborate >> more on this? > > Sorry, missed this before -- the 'nwifi' mode which is the normal > datapath for ath10k discards the QoS header and following mesh header > when transmitting, if I recall correctly. I also had some issues with the > received frames when using nwifi RX decap with raw mode TX, but I don't > recall exactly the problem. I can retest with these modes if you really > want the details. > > -- > Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/17/2015 10:48 AM, Yeoh Chun-Yeow wrote: > Hi, Bob > > I have also tested with nwifi mode for non-secured mesh. It seems to > be worked for me with the following two test scenarios: > > Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k] > Node 1 [ath10k] <---> Node 2 [ath9k] > > I am using the following: > compat-wireless-2015-07-21 from OpenWRT > firmware-5.bin_10.2.4.70.6-2 > > I just wondering whether using raw wifi is better for encrypted mesh > later? nwifi mode will be in trouble when SNAP/LLC encapsulation used since firmware and hardware have no way to distinguish if it's SNAP header or Mesh Control field. -- Peter > > ---- > Chun-Yeow > > On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland <me@bobcopeland.com> wrote: >> On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: >>> Hi, Bob >>> >>>> Yes: you don't want to enable raw mode TX / RX decap in the normal >>>> case because it's fairly inefficient compared to "native" wifi mode, >>>> according to my understanding. The latter doesn't support mesh > framing >>>> however. >>>> >>> The native WiFi mode doesn't support mesh framing. Can you elaborate >>> more on this? >> Sorry, missed this before -- the 'nwifi' mode which is the normal >> datapath for ath10k discards the QoS header and following mesh header >> when transmitting, if I recall correctly. I also had some issues with > the >> received frames when using nwifi RX decap with raw mode TX, but I don't >> recall exactly the problem. I can retest with these modes if you really >> want the details. >> >> -- >> Bob Copeland %% http://bobcopeland.com/ > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index b87b986..9dafe25 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[] = { { @@ -1117,6 +1120,15 @@ 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) { + if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT, + ar->fw_features)) { + ath10k_err(ar, "rawmode = 1 requires support from firmware"); + return -EINVAL; + } + 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 7dfe37f..b0f1594 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4176,6 +4176,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; @@ -4216,6 +4224,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, @@ -4555,6 +4564,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) { @@ -5294,6 +5310,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. @@ -5329,6 +5346,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. @@ -6642,14 +6660,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) }, }; @@ -6688,7 +6708,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, @@ -6708,7 +6729,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, @@ -6998,7 +7020,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;
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. The firmware must advertise support for rawmode (tested successfully with firmware 10.2.4.70-2). When loaded with rawmode=1, ath10k can operate an open mesh STA via something like the following: ip link set wlan0 down iw dev wlan0 set type mp ip link set wlan0 up iw dev wlan0 set freq 5745 80 5775 iw dev wlan0 mesh join mesh-vht Signed-off-by: Bob Copeland <me@bobcopeland.com> --- Since ath10k ml posting: * added raw mode feature flag check * usage and firmware notes in commit log drivers/net/wireless/ath/ath10k/core.c | 12 ++++++++++++ drivers/net/wireless/ath/ath10k/mac.c | 33 ++++++++++++++++++++++++++++----- 2 files changed, 40 insertions(+), 5 deletions(-)