#12657 NORM 13.2.0: Fix btmrvl/mwifiex suspend interactions

[Zarro Boogs per Child]

#12657: Fix btmrvl/mwifiex suspend interactions
------------------------------+---------------------------------------------
           Reporter:  dsd     |       Owner:  pgf          
               Type:  defect  |      Status:  new          
           Priority:  normal  |   Milestone:  13.2.0       
          Component:  kernel  |     Version:  not specified
         Resolution:          |    Keywords:               
        Next_action:  code    |    Verified:  0            
Deployment_affected:          |   Blockedby:               
           Blocking:          |  
------------------------------+---------------------------------------------
Changes (by pgf):

 * cc: dsd (added)


Comment:

 {{{
 <dsd> pgf: just a guess (without looking at the code), for that mwifiex
 bug try dropping the line that sets is_suspended to true
 <pgf> okay.  i'm officially hanging it up.  dsd just fixed the bug (which
 i've been diagnosing on and off for several days) by asking me to delete a
 line, without even looking at the code.
 <dsd> hah, sorry
 <pgf> oh, believe me -- it's okay!  :-)
 ...
 <dsd> that flag also got in my way before, which is why i figured that was
 worth a try
 <pgf> do you think it's needed for any of the other host interfaces?
 <dsd> just the USB one
 <pgf> okay, so it shouldn't be eliminated -- just not maintained in sdio.
 <dsd> it would be worth getting an understanding of whats going on though,
 if you dont have that already. it suggests that we're trying to send a
 command after that flag is set
 <pgf> yeah -- that's where i was when i stopped for the day.
 <pgf> "that shouldn't be happening"
 <dsd> ok
 <pgf> i'll try and understand it tom'w.
 }}}

 i believe the problem is that while the setting of host sleep mode is done
 synchronously, unsetting it is done async.  when mmc realizes that no card
 function needs a powered suspend, it runs all of the card function resume
 routines (which is when mwifiex_sdio_resume() sends the async command to
 cancel host sleep), and then commences removing the card.  during the
 remove sequence, the driver tries to talk to the card, and there's a race
 condition against the cancellation of host sleep.

 dsd's proposed change, above, fixes the problem.  so does changing the
 cancellation of host sleep to be a synchronous command.

 daniel -- opinions?  we could apply either change, or both, i guess.

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