Re: [PATCH 10/21] offchannel: add support to issue multiple offchannel requests

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

> 
> It wouldn't hurt, but I think we were always under the assuming that the ack 
> would come before the event so I never bothered using a callback :)
>

My memory is fuzzy now, but I think brcmfmac was very weird in this area.  Which 
might explain why offchannel code is written the way it is.

>>
>>> src/offchannel.c:offchannel_mlme_notify() ROC cancel, cookie=1
>>>
>>> # Cancel ROC is correctly waited for before starting the next item
>>> src/wiphy.c:wiphy_radio_work_done() Work item 1 done
>>> src/wiphy.c:wiphy_radio_work_next() Starting work item 2
>>> src/offchannel.c:offchannel_work_ready() Issuing ROC
>>> src/netdev.c:netdev_mlme_notify() MLME notification Remain on Channel(55)
>>
>> This seems fishy?  What else is going offchannel?
> 
> No, this is the same event as below, just netdev printing it.

Ah, ok.

> 
>>
>>>
>>> # Then immediately we get a Remain on Channel event
>>> src/offchannel.c:offchannel_mlme_notify() ROC notify, cookie=3
>>> src/offchannel.c:offchannel_mlme_notify() ROC started prior to ACK, setting 
>>> cookie 3
>>> src/dpp.c:dpp_send_frame() Sending frame on frequency 2437
>>>
>>> # And finally the ack comes in
>>> src/offchannel.c:offchannel_roc_cb() cookie=3
>>
>> Yeah, why is the cookie 3?  Shouldn't it be 2?
> 
> 2 is the work item, 3 is the cookie above.

Yeah, I get that.  But shouldn't the cookie from the kernel be 2 and not 3?  Or 
is the cookie also being incremented by CMD_FRAME?

Regards,
-Denis