<div dir="ltr"><div><div><div>Hi all, </div>sorry for the long -email, but I got stuck again in another problem: the re-probe does not start when the ModemManager is in "SIM missing failed state" and mm_base_modem_set_valid(..., false) is called. The current, modified, initialization code has got the following new steps: 1. mm-iface-modem.c:interface_initialization_step has got a new step (sim hot swap) just before INITIALIZATION_STEP_UNLOCK_REQUIRED(1), where the modem code is called to - enable QSS unsolicited (that signals when the SIM has been removed/inserted) - register a handler to catch the unsolicited. 2. mm-broadband-modem.c:initialize_step has got a new step (again sim hot swap), just after INITIALIZE_STEP_IFACE_FIRMWARE(2) where it - checks whether the modem supports sim hot swap (with a property) - creates a new instance of PortsContext and save a reference of it in ctx->self->priv->sim_hot_swap_ports Now, when a modem's initialized and SIM is missing, I have: modem disabled and in failed state, QSS enabled, an handler set and the ports open. When the SIM is inserted again the handler 1. updates the state to MODEM_STATE_UNKNOWN 2. releases the PortContext kept open to receinve the unsolicited 3. calls mm_base_modem_set_valid(..., FALSE) but the re-probe does not start as I expected and I can't figure out why. Is there any precondition for having the reprobe starting as expected? NOTES (1) this step is here because the INITIALIZATION_STEP_UNLOCK_REQUIRED is the first one that recognizes that the SIM is missing and if so it makes initialization jumps to INITIALIZATION_STEP_LAST. (2) This step is here because when iface-modem initialization fails, we jump directly to INITIALIZE_STEP_IFACE_FIRMWARE. </div>Thank you in advance, </div>Carlo <div><div> <div class="gmail_quote"><div dir="ltr">On Thu, 24 Mar 2016 at 16:50 Carlo Lobrano <<a href="mailto:c.lobrano@gmail.com">c.lobrano@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi Aleksander,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">thank you for this reply, lot of information and clear.</div></div><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Carlo</div></div><div class="gmail_extra"> <div class="gmail_quote">On 23 March 2016 at 10:06, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey! On Tue, Mar 22, 2016 at 3:25 PM, Carlo Lobrano <<a href="mailto:c.lobrano@gmail.com" target="_blank">c.lobrano@gmail.com</a>> wrote: > I had some time now to look at the changes for SIM hot insertion feature > (QSS unsolicited in Telit modems), lot of doubts actually. > > My idea is the following: > > 1. in modem iface initialization, ask the modem whether it supports or not > SIM hot insertion (TBD: sync method? property?). How will you know if it supports SIM hot insertion? Is there any Telit specific command to do so? Or is it that all Telit modems support it? If the former, then an async method to query doing initialization; if the latter, then a property that can be set to TRUE when the modem object is created from the plugin code. > 2. according to point 1, if initialization fails for > MM_MOBILE_EQUIPMENT_ERROR_SIM_NOT_INSERTED, allow the modem enable command > (I am not sure about this actually, see my note below). Hum... no. Don't think this should be the case. Enable() should only be allowed if the modem is Disabled, which means it isn't Failed, which means it has SIM. > 3. In telit plugin, register an handler for QSS unsolicited (3gpp iface) > a. when sim is removed > - disable modem (mm_modem_disable) keeping the QSS handler (and the > port open) > - set modem in locked state (mm_iface_modem_update_state) > b. when sim is inserted > - start re-probe (mm_base_modem_set_valid(..., false)) > This should go in the generic logic, not in the 3GPP logic, I would say. E.g. the "unlock_required" stuff is not 3GPP only. What I would do, is: a1) If the modem supports SIM hot plugging and we boot without a SIM, we end up going to the same Failed state as before, but in this case we don't just close all ports. We would need some additional extra logic to be run in Failed state, like opening the port and keeping it open with the QSS handler set. I would definitely not touch any other logic. a2) If the modem already had a SIM and modem gets enabled; and then the SIM is removed, we would go first to disable to cleanup everything and then right away to Failed state (no locked), but with the same additional logic discussed before to monitor QSS. Or, if you prefer, you could also try to just set_valid(...,false) as that would reprobe the modem, and we would end up in case a1) again. b) When modem is in Failed state and SIM is inserted, we directly call set_valid(...,false) to reprobe from scratch, so that it starts the probing with the SIM available. > > There are still some open points, here are the most important IMO > > A. The modem really needs to be enabled to get the the unsolicited? No. The modem can be in Failed state, BUT, it will need additional logic to keep the serial port open listening for QSS. > B. How to keep the port open. > mm_serial_port_open() has an "open count" logic. If you add additional logic in Failed state, you could keep an "open reference" (meaning you called open once explicitly). > Point A > ======= > > I added a QSS handler in the plugin along with the other unsolicited in > `modem_3gpp_setup/enable_unsolicited_events` functions, but this way I can > register an handler only when modem is enabled, which is not something I > would allow when SIM is not inserted. I also tried to move the handler > registration logic inside a new modem-iface's function (namely, not in 3gpp > iface), but did't work. > Am I missing something, or enabling the modem is really needed to listen to > modem's unsolicited? Enabling modem explicitly opens the port and keeps it open (see open_ports_enabling()), which is what you need, but you need to add it additionally in the Failed state. > > Point B > ======= > > I thought to solve this point adding a parameter "keep_open" to > MMPortSerialPrivate along with a new function to set it to TRUE, in order to > keep the port open when open_count==1, but it does not seems to be effective > (the main issue now is a crash, that I am still debugging, when SIM is > removed and then re-inserted, like if the port status is invalid, > "partially" close). Do you think is a viable solution? No, don't touch the MMPortSerial logic. The object already has the logic of "open count"; e.g. in open_ports_enabling() we explicitly open the primary and secondary ports by calling mm_serial_port_open(), and if those succeed we keep track that we had opened the ports in ctx->primary_open and ctx->secondary_open (so that we only try to close them if we had opened them before, i.e. if we are holding the "open reference"). This info is kept in the PortsContext struct which is stored in self->priv->enabled_ports_ctx. Different implementations may have different PortsContext (e.g. QMI has the state of which QMI clients were allocated), but all have the same purpose: context of what is the state of the ports when the modem is enabled. What you should do is to have a new "failed_ports_ctx" PortsContext, or similar, which would be the state of the ports while in Failed state. So, when e.g. the modem goes into Failed state during initialization because it didn't find a SIM card, you would start a new "Failing" logic, similar to the "Enabling" logic, but with just 2 steps: preparing a PortsContext with the open ports info, and setting up the unsolicited messages handlers for QSS. All of this, except for the actual QSS handler, would be in the generic code; the QSS handler implementation in the Telit plugin. -- Aleksander <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div> </div> </blockquote></div></div></div></div>