#7973 BLOC 8.2.0 (: libertas unknown event IDs and hang

[Zarro Boogs per Child]

#7973: libertas unknown event IDs and hang
------------------------+---------------------------------------------------
   Reporter:  cjb       |       Owner:  dsaxena             
       Type:  defect    |      Status:  new                 
   Priority:  blocker   |   Milestone:  8.2.0 (was Update.2)
  Component:  kernel    |     Version:  not specified       
 Resolution:            |    Keywords:  blocks:8.2.0        
Next_action:  diagnose  |    Verified:  0                   
  Blockedby:            |    Blocking:                      
------------------------+---------------------------------------------------

Comment(by ashish):

 Replying to [comment:43 dcbw]:
 > We need documentation of these internal firmware dependencies then.  The
 specs don't say much here, except in section 2.2 (Driver and Firmware
 After Card Insertion) which _might_ indicate how it's supposed to work but
 is highly unclear with respect to post-insertion operations.
 >
 > A few questions:
 >
 > - Is a scan required after every CMD_802_11_DEAUTHENTICATE command?
 No.
 > - What is the host driver supposed to do if the DEAUTH command returns
 an error?  Retry the command after a timeout?  If so, how long should that
 timeout be?
 The probability of getting non-zero deauth reason code in the deauth
 command response from the firmware is very low. Ideally, driver should
 retry when it happens. A typical retry timeout could be 100ms.
 > - Do any of the Marvell-provided drivers handle an error response from
 DEAUTHENTICATE?
 >
 > I checked the original 8388 code drop, the
 SD-8686-FEDORA26-8.73.7.p3-26340P58 driver, and the moblin.org v9 driver,
 and the gumstix cf8385 5.0.13 driver, and none of them do anything
 different from the libertas driver after failure of a DEAUTHENTICATE
 command.  They don't even run the code that resets the internal driver
 state to disconnected.  What should be happening here in the driver?
 >
 > If the driver requires certain steps to be performed in a specific
 order, or the commands have interdependencies, then those need to be
 documented in the specification much like the sequence of RSN setup is
 documented in v5.1 section 7.1.1.  Otherwise, there's no way we can ever
 figure out how to work correctly with binary firmware drops.

 Nothing is required from the driver except to check for reasoncode field
 of cmd_ds_802_11_deauthenticate.

 If the deauth command fails, deauth command respone contains non-zero
 response code, and firmware works fine. However, if driver gets sucessful
 deauth command response, which is zero, but the deauth reason code (member
 {{{
 reasoncode
 }}}
  of struct
 {{{
 cmd_ds_802_11_deauthenticate
 }}}
 ) non-zero firmware may be still in associated state.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7973#comment:44>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system