On Thu, Sep 20, 2018 at 7:18 PM Denis Kenzior <[email protected]> wrote:
> Hi Giacinto, > > On 09/20/2018 12:03 PM, Giacinto Cifelli wrote: > > hi Denis, > > > > On Thu, 20 Sep 2018, 18:31 Denis Kenzior, <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Giacinto, > > > > > The idea would be to just store the values in the driver but not > > in the > > > module, > > > and then send them before attaching, so that the verification can > be > > > consistent and all, > > > just like for the gprs-context atom. > > > > Yes, but that is not what you outlined in the code. You were > watching > > for SIM_STATE_READY which only means just that. > > > > Also note that we can bring the modem online even in pre_sim state > > (e.g. > > for emergency calls), in which case the lte atom doesn't exist yet. > > > > > > where should a hook be placed then? > > this looked to me a good place, just before bringing it online. > > if there is no atom, no config and everything is ok anyway. > > That's kind of the problem, there is no good place. The only thing you > can do is have the core apply settings, if available, just prior to the > set_online driver call. However, it is tricky to do so: > > - We're in pre-sim state and go online for emergency calls. This is > okay as no LTE atom is created. If a SIM is initialized / inserted at > this point, the modem can re-connect with a proper default settings. > The LTE atom creation and modem performing a re-connect is now a race. > Admittedly the solution we have today also suffers from this problem, so > maybe there's not much we can do here. > > - We're offline and going online. You need to perform the online > operation as a transaction. First setting the default attach details > and then actually setting the modem online. We can't do it > simultaneously, as again we cannot assume the multiplexing / queueing > behavior of the driver. This could perhaps be made to work, but there > may be additional issues that are discovered as we go along. Only way > to find out is to prototype it. > ok, the AT driver is piping the commands, and I am going to implement it for it. Admittedly, for another driver could be more difficult (MBIM also pipes them), but there is still the possibility to set directly the parameters as they are today, not implementing this function in the atom (NULL function or simply returning). > > > > > > > > so the idea would be to check if a new method, that I have > > tentatively > > > called set_property(), > > > exists. If so, use the reviewed stile above, otherwise fallback > > to the > > > current function. > > > > > > > I don't see what set_property is buying you. Anyway, feel free to > come > > up with a more detailed proposal, but my impression is that this > > approach will quickly become way too complicated. > > > > > > I think now i got you. The existing function could be used, but the > > driver only stores the values internally because it knows it will ve > > called later for sending the commands. > > > > Or we simply cache the values in the lte atom and call the driver method > only when appropriate. > I believe it is better to call the atom and let it decide what to do, in part to mitigate the issues above. > Regards, > -Denis > with this, I am good to go, I will try to prototype this new behavior. Regards. Giacinto
_______________________________________________ ofono mailing list [email protected] https://lists.ofono.org/mailman/listinfo/ofono
