[PATCH] ath10k: Make HTT fill size configurable

Sujith Manoharan sujith at msujith.org
Wed Jan 14 23:50:58 PST 2015

Kalle Valo wrote:
> Did you read at all what I wrote above? For example, what if we later
> don't actually use ATH10K_HTT_MAX_NUM_REFILL anymore?
> And the fundamental problem is that I still don't know what fill value
> you think is the best to use here, and that means neither will the
> users. That's why the values need to be within ath10k, not expose driver
> internals and use some magic numbers which are not available anywhere.

What magic numbers ?

How is 16 less a magic number than 128 or 96 or the original 1000 ?

> We are not limitting anything more. That's not any different from what
> your patch does, just that the parameter name is different and the user
> doesn't have direct access to the internal parameter. Let me explain a
> bit more how that would work in this HTT fill case:
> profile 0 (auto):
> profile 1 (slow):
>         htt_fill_size = ATH10K_HTT_MAX_NUM_REFILL
>         break:
> profile 2 (fast):
>         htt_fill_size = 77 /* or whatever */
>         break;
> So in this method the user can still choose optimal settings for a
> certain platform, I assume AP148 in this case, and not know about driver
> internals. And if there are more parameters we need to change in the
> future, we can use the same modparam to change that as well.

You seem to be fixated on some imaginary user that is going to be
confused by a module parameter.

I don't see how adding more complexity by adding profiles and such
is going to make a user less confused.


More information about the ath10k mailing list