Re: Shutdown/hibernate/sleep events

[Dan Williams <dcbw redhat com>]

On Thu, 2011-09-01 at 17:31 +0800, Daniel Yek wrote:
> On Thu, 2011-09-01 at 10:15 +0200, Jean Parpaillon wrote:
> > I'm currently developing a solution leveraging wake on wireless feature
> > on some new 3g modems. For this to work, SIM card must not be disabled
> > when computer go to sleep. 
> > Can someone point me the code which is responsible for handling SIM
> > deactivation and sleep events ? It is in ModemManager ? NetworkManager ?
> > linux driver itself ?
> 
> I won't start with ModemManager, NetworkManager, or the driver.
> 
> I will start with ACPI code and trace from there.
> 
> ACPI does Power Management and 
> implements the policy of sleeping states.
> 
> Not sure if the policy is extended up to ModemManager.
> 
> I don't know any more than this (without "doing the work",)
> so just take this as one other suggestion that you can look into.

At the moment, here's what' happens with NM/MM.  When NM gets the signal
to go to sleep, it disconnect active connections.  ModemManager
currently knows nothing about sleep/wake, it depends on the driver or
kernel stack to indicate to MM that the modem has been powered down
(usually indicated by a USB bus disconnect of the modem device and
associated serial ports).

When you say "SIM card disabled" what specifically do you mean?  Do you
mean the modem should be left in powered-up mode and potentially
registered with the network?  Normally the SIM card doesn't have much to
do with this at all, it's that the modem isn't powered down (CFUN=0) and
is allowed to stay registered.

But as Daniel wrote, you first have to ensure that the kernel's USB
stack allows the modem to remain powered and doesn't turn off the USB
controller during suspend.

So at this point it's more about the kernel drivers and USB stack than
it is about userspace.  Once you've verified that the kernel provides
the behavior you expect, then we can investigate what mechanisms the
modem provides to userspace clients for this; ie does it keep the serial
ports open across suspend/resume and thus on resume when the MM process
is unfrozen, there's data to be read on the serial port?  Or is the
serial port closed and we need to re-open it and read data?  That sort
of thing.

Dan