[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