#9967 NORM 1.0-sof: 2.6.31.6: libertas suspend fails on XO-1

[Zarro Boogs per Child]

#9967: 2.6.31.6: libertas suspend fails on XO-1
------------------------------------+---------------------------------------
           Reporter:  sascha_silbe  |       Owner:  dsaxena                           
               Type:  defect        |      Status:  assigned                          
           Priority:  normal        |   Milestone:  1.0-software-later                
          Component:  kernel        |     Version:  Development source as of this date
         Resolution:                |    Keywords:  libertas suspend                  
        Next_action:  diagnose      |    Verified:  0                                 
Deployment_affected:                |   Blockedby:                                    
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsaxena):

  * status:  new => assigned


Comment:

 I wasn't really sure that the patch removing the call to host_sleep_cfg()
 was the right solution so started doing some testing. What Marvell's patch
 does is move the call to host_sleep_cfg() out out of the WOL-configuration
 path and into the suspend path. By default, WOL is disabled, but if I run
 "ethtool -s eth0 u" and then "echo mem > /sys/power/state", the system
 will go to sleep and I can wake it up with a ping from a host. When we
 resume, I still see a "command 0x0043 failed" and the reason is b/c the
 WOL-disable command (EHS_REMOVE_WAKEUP) does not seem to be supported by
 the 8388 firmware. This is not fatal as the card keeps running.

 The proper fix would be to update the userspace on XO-1 F11 to submit the
 proper WOL commands on suspend as we do on XO-1.5 but this still leaves us
 with the case where we are closing the lid and we want full WOL disable
 which we can't issue. :/ A workaround would be to unload the driver on lid
 close and re-load it on lid-open, which is reasonable as resume speed is
 not critical for this use case.

 Another option is to add a flag to the lbs_priv structure that we fill in
 at probe time to let the suspend/resume code know not to submit the PM
 commands and move the WOL-enable back into the WOL path for that case.
 This is not much different than Bernie's patches but a bit more upstream
 friendly than checking the machine type on every suspend. I will first
 test Bernie's patches and see if I can reproduce the issue Sascha saw as I
 would likely see the same issue with the other approach.

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