On 16.06.2015 22:00, ofono-request(a)ofono.org wrote:
Date: Tue, 16 Jun 2015 11:53:33 -0500 From: Denis Kenzior
<denkenz(a)gmail.com> To: ofono(a)ofono.org Subject: Re: ofono Digest, Vol
Today LockedPins is emitted only as a result of locking or unlocking
PIN. We can certainly look into emitting it when PinRequired is
emitted. Do you already have a patch for this handy?
Sure, coming up.
Yes, this sounds like a bug. We should always emit PinRequired on
> >OFONO_SIM_PASSWORD_INVALID was used because at startup
it's the initial
Actually, it isn't. OFONO_SIM_PASSWORD_NONE is the initial value.
incorrectly recalled value would be "0" which is what the struct
is initialised to.
> >Logs about use-case: remove & insert a pin-required usim
> >There's an additional __ofono_sim_recheck_pin call seen
> >ofono_sim_inserted_notify from driver to core trigger a password query.
> >Now when I look at it I'm not sure if it's still needed, but
> >nevertheless even if it's removed monitor-ofono does not show
> >"LockedPins" or "PinRequired" being emitted
> >(logs and code analysis confirm that).
??? This seems wrong. Are you running upstream? We should not be
querying the PIN until after we read EFpl
Like I wrote the logs show an additional __ofono_sim_recheck_pin call
but that's besides the point, the property signalling problem is still
valid in upstream even when the extra __ofono_sim_recheck_pin is removed.
Just FYI, it is there because upstream EFpl reading triggers password
query, but sometimes at that time modem returns still an old value. As a
workaround the driver needs to poke "core" ofono to re-query when it's
updated. But let's not focus to that, we're not upstreaming that :)
Let's continue the discussion in the patch thread,