<div dir="ltr">In this particular case, the command AT%DPDNACT=0 took longer than 10s, which is too long when the user suspends the system.<div><br></div><div>Thanks, I'll take a look at the internal states and see if we can reset it without going through a full disable.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 4:48 PM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 2014-02-19 at 14:21 -0800, Thieu Le wrote:<br>
> Hello,<br>
><br>
> I am trying to solve a problem during our system suspend where the disable<br>
> modem step takes a long time and it would be quicker to just go straight to<br>
> modem power down.<br>
><br>
> mm-iface-modem.c:handle_set_power_state_auth_ready() checks to make sure<br>
> the modem is disabled before allowing it to be powered down.  Is this done<br>
> because some modems require it to be in a disabled state before allowing<br>
> the power down?<br>
<br>
</div></div>Out of curiosity, which command takes too long?<br>
<br>
I think this is done mostly to ensure that internal stuff is cleaned up<br>
correctly; like timeouts, polling the modem for status, and other things<br>
that may have been set up during the enable state.  I don't think most<br>
modems would care about being disabled if you're just going to CFUN=0<br>
them.<br>
<br>
If we were able to ensure that these things were properly cleaned up,<br>
then we could jump directly to the power down state.  The way to do that<br>
would probably be to identify what gets torn down during 'disable',<br>
split that out into separate functions that could be called from both<br>
disable and power down, and then do that from both places.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
<br>
</font></span></blockquote></div><br></div>