[PATCH] Fixed wrong MEM1 value passed to +CPMS

[Carlo Lobrano]

> didn't we say that waiting for #QSS:3 was discarded because it would
> take too long, even > 30s?

Yes, but I was thinking about the idea of retrying some commands later when
the SIM is ready

> I think so, yes. That indicates an earlier error, we don't know what
> happened, so we should just return error here as well, IMO.

Ok, I'll update the patch then

On Thu, 23 Mar 2017 at 19:39 Aleksander Morgado <aleksander at aleksander.es>
wrote:

> On Thu, Mar 23, 2017 at 5:32 PM, Carlo Lobrano <c.lobrano at gmail.com>
> wrote:
> >> So why is current_sms_mem1_storage UNKNOWN? At which point did it
> >> fail, if it did? Did it fail doing AT+CPMS?
> >
> > Correct. AT+CPMS? returns with SIM Busy. It's something that will be
> better
> > addressed when "delay till #QSS: 3" will be implemented.
> >
>
> didn't we say that waiting for #QSS:3 was discarded because it would
> take too long, even > 30s?
>
> >> I agree that we shouldn't call any CPMS command passing "unknown" as
> >> storage, but defaulting to "SM" isn't a good approach either. [...]
> >> If it is UNKNOWN because init_current_storages() failed, we should
> >> also error out when trying to set_default_storage()
> >
> > I understand that. So, set_default_storage should return error directly
> when
> > it finds that mem1 is UNKNOWN. Is that right?
>
> I think so, yes. That indicates an earlier error, we don't know what
> happened, so we should just return error here as well, IMO.
>
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170323/533efae4/attachment.html>