[PATCH 3/3] ath10k: implement mesh support
Jason Andryuk
jandryuk at gmail.com
Mon Aug 31 20:02:32 PDT 2015
On Sat, Aug 29, 2015 at 6:25 PM, Bob Copeland <me at 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
More information about the ath10k
mailing list