[RFTv2 3/5] ath10k: rework peer accounting

[Michal Kazior]

On 10 April 2014 08:50, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> It was troublesome to iterate over peers and
>> perform sleepable calls. This will be necessary
>> for some upcomming changes to tx flushing.
>>
>> Make peer allocation and initial setup
>> protected by both ar->conf_mutex and
>> ar->data_lock. This way it's possible to iterate
>> over peers with conf_mutex and call sleepable
>> functions.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> Sorry, but I'm not really getting your idea here of using both
> conf_mutex and data_lock to protect ar->peers. Can you elaborate more,
> please? Why can't we just use conf_mutex then? What am I missing?

Originally ar->peers was protected by data_lock. The reason for that
the list is accessed from a tasklet context for htt peer map/unmap
events. Originally those events allocated/freed peers. This however is
cumbersome to work with when you want to iterate over peers and issue
blocking/sleepable calls (e.g. flush tx via wmi).

Having conf_mutex-only protected conf_mutex would require htt peer
map/unmap event processing to be moved into sleepable context (e.g.
into a worker).

That's why I've made ar->peers being write-protected by both so that
it can be read while holding any of these locks.

I'll try to make the commit message clearer.


Michał