From: Tommi Kenakkala <tommi.kenakkala@tieto.com>
To: ofono@ofono.org
Subject: Re: ofono Digest, Vol 74, Issue 6
Date: Thu, 18 Jun 2015 15:11:33 +0300 [thread overview]
Message-ID: <5582B575.6040100@tieto.com> (raw)
In-Reply-To: <mailman.1.1434481201.32187.ofono@ofono.org>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
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@gmail.com> To: ofono(a)ofono.org Subject: Re: ofono Digest, Vol
> Today LockedPins is emitted only as a result of locking or unlocking the
> 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
> pin-enabled hotswaps.
Proposal sent
>> >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.
True. I incorrectly recalled value would be "0" which is what the struct
is initialised to.
>> >Logs about use-case: remove & insert a pin-required usim card.
(...)
>> >There's an additional __ofono_sim_recheck_pin call seen here after
>> >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).
...
>> >src/sim.c:__ofono_sim_recheck_pin()
> ??? This seems wrong. Are you running upstream? We should not be
> querying the PIN until after we read EFpl
...
> Regards,
> -Denis
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,
thanks
--
Tommi
parent reply other threads:[~2015-06-18 12:11 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <mailman.1.1434481201.32187.ofono@ofono.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5582B575.6040100@tieto.com \
--to=tommi.kenakkala@tieto.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.