On 30/06/17 20:28, Eric Caruso wrote: >>>>>> If I'm not mistaken, whenever a sim insert/removal event is detected, we >>>>>> should just call >>>>>> mm_broadband_modem_update_sim_hot_swap_detected(), which will trigger a >>>>>> full modem re-probe. >>>> I had imagined that a full re-probe on SIM removal was overkill, and >>>> the discussion in thread >>>> https://lists.freedesktop.org/archives/modemmanager-devel/2014-February/000914.html >>>> seemed to land on moving the modem into the failed state rather than >>>> disabling it. I suppose the re-probe will re-initialize it and it will >>>> get to the failed state because it doesn't have a SIM inserted, so I >>>> can change this if that's what we want. >>>> >>> A full reprobe is a bit overkill, yes, but right now that's the only way to >>> not only force the modem in Failed state but also make sure all feature >>> interfaces get un-exported from DBus. A modem in failed state should only >>> allow very few of the feature interfaces exposed, mainly those which would >>> allow to get away from a failed state, like e.g. the Firmware interface. >>> >>> I'd suggest we keep the full reprobe for now, but also investigate the >>> possibility of getting in the Failed state with the limited interfaces, as >>> that would be much quicker. >> Thanks, I'll do that for now and look into moving it into the failed >> state in the future. > Something interesting happened when I tried this out: when re-probing > the modem on removal, we disable the Modem3gpp interface. This calls > mm_iface_modem_3gpp_disable which in turn calls > cleanup_unsolicited_events. As as result we stop getting > SUBSCRIBER_READY_STATUS notifications and we can no longer get > notified when the SIM is inserted. Simply moving the modem to the > failed state when the SIM card is ejected did not disable the 3gpp > interface so we were still able to get notifications. > > However, this is still a problem even for the original patch if a SIM > card is not inserted when the modem is first enabled, so we have to > deal with this anyway. Additionally, if we want to move to the failed > state and disable interfaces we'll probably have the same issue. We > might want to be notified of SUBSCRIBER_INFO events regardless of > whether setup_unsolicited_events or cleanup_unsolicited_events is > called (e.g. we can subscribe to them separately in > setup_sim_hot_swap). >
Yes, that is true. Check how the Telit plugin deals with this registering the #QSS indications separately. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
