Re: [PATCH 2/7] extended support for LTE and NR. Some minor fixes. part 2 of 7

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

Hi Giacinto,

On 09/20/2018 12:03 PM, Giacinto Cifelli wrote:
> hi Denis,
> 
> On Thu, 20 Sep 2018, 18:31 Denis Kenzior, <denkenz@gmail.com 
> <mailto:denkenz@gmail.com>> 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.

> 
>      >
>      > 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.

Regards,
-Denis