[RFC PATCH 2/2] ath10k: add testmode

[Kalle Valo]

Michal Kazior <michal.kazior at tieto.com> writes:

> On 30 May 2014 12:06, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> On 29 May 2014 14:51, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>>>
>>>> BTW, please edit your quotes. It's pain to find your comments from a 700
>>>> line monster :)
>>
>> This request still stands, even though 170 lines is much better than 700
>> lines ;)
>
> I intended to trim it this time but I've hit 'send' before actually
> doing that.. sorry!

No problem :)

>>> We could also depend on cmd_id to accept/reject skbuffs in
>>> ath10k_tm_event_wmi() since, at least for now, there aren't any
>>> special cases to handle. But then.. will we really ever need to have a
>>> passthrough (i.e. pass buffers to userspace but still process them in
>>> the driver afterwards)? Does that even make sense?
>>
>> I think that's getting a bit too complicated. Basically we just need
>> ath10k act as a pipe for WMI packets.
>
> Hmm..
>
> With v1 code if you assume UTF firmware sends an SWBA event then
> ath10k would send the testmode event AND try to actually handle it as
> if it was regular operation.. but how is that supposed to work if you
> have no mac80211 interface structures around at all? My point is
> ath10k_tm_event_wmi() should _consume_ buffers and the caller should
> not processes consumed buffers (assuming you want to keep
> ath10k_tm_event_wmi call where it is now, i.e. before switch-case).

I see your point now, thanks for banging it to my thick head with a
sledge hammer :)

I'll rethink this part and try to solve it for v2. The reason I would
like to avoid your consuming idea is that at some point we might want to
enable this WMI pipe also in "normal mode".

-- 
Kalle Valo