[RFC PATCH 2/2] ath10k: add testmode

Kalle Valo kvalo at qca.qualcomm.com
Fri May 30 03:35:56 PDT 2014

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

More information about the ath10k mailing list