Re: [PATCH 0/3] ath10k mesh support

From: Ben Greear <greearb@candelatech.com>
To: Bob Copeland <me@bobcopeland.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>, ath10k@lists.infradead.org
Subject: Re: [PATCH 0/3] ath10k mesh support
Date: Tue, 18 Aug 2015 09:04:04 -0700	[thread overview]
Message-ID: <55D35774.10103@candelatech.com> (raw)
In-Reply-To: <20150818124233.GA867@localhost>

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