This patch reads and writes the call forwarding unconditional status
from and to the SIM depending on the SIM file availability.
New property needs to be added due to the fact that number won't be
available from the cphs-cff file.
Incase of SIM, EFcphs-cff file holds call forwarding status and it
is represented as a flag. In case of USIM(EFcfis), we have the status
flag and also number.So, adding new property for status and using the
existing VoiceUnconditional with number will work for both SIM and USIM cases.
Other option is to have 2 properties, "VoiceUnconditional" and "Number".
"VoiceUnconditional" will have the status of the call forwarding( "enabled",
"disabled") whereas the "Number" property will have the call forwared number.
offline-online state transitions results in caching the call forwaring status
every time. To avoid this, call forwarding atom is moved to the post sim and
its moved also due to the fact that call forwarding status doesn't change in
Jeevaka Badrappan (7):
call-forwarding: Read/Write cfis/cphs-cff
ifx: Move call forwarding to post sim
isigen: Move call forwarding to post sim
plugins/n900: Move call forwarding to post sim
phonesim: Move call forwarding to post sim
doc: Add new property to call forwarding
TODO: Marking the Read/Write EFcfis task as done
TODO | 9 --
doc/call-forwarding-api.txt | 5 +
doc/features.txt | 5 +
plugins/ifx.c | 2 +-
plugins/isigen.c | 2 +-
plugins/n900.c | 2 +-
plugins/phonesim.c | 3 +-
src/call-forwarding.c | 242 ++++++++++++++++++++++++++++++++++++++++++-
8 files changed, 256 insertions(+), 14 deletions(-)
[sorry for the last mails where I got your last name mixed up...]
On 08/10/2017 07:03 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Could you send me the exact modem description you are using? So that we can write quirk?
> I am using TELIT 910 EUG Modem.
Okay, maybe that is already enough. I saw that in drivers/telit.c there
is already some code to handle variants of the modem. The matching is
done on these strings.
Are there any vid/pid available fot his modem?
I'm writing a custom network-registration driver for uBlox modems and
I'd like to know if you will choke on the following approach:
i) export method implementations from atmodem driver
ii) set up uBlox netreg vtable with custom probe method and exported
atmodem implementations for rest
If you can't accept this approach, please let me know of an alternative
method that would be preferable that (hopefully) doesn't entail just
copying all the code from one driver to the other (1000+ lines to keep
in sync going forward).
PS: This is an RFC... patches are not quite done. That said, feel free
to patch review if you've got a moment; the final result shouldn't
differ all that much from what's here.
Jonas Bonn (2):
atmodem: export generic netreg funcs
ublox: network-registration atom
drivers/atmodem/network-registration.c | 16 +-
drivers/atmodem/network-registration.h | 17 +
drivers/ubloxmodem/network-registration.c | 413 ++++++++++++++++++++++
drivers/ubloxmodem/ubloxmodem.c | 2 +
drivers/ubloxmodem/ubloxmodem.h | 3 +
5 files changed, 444 insertions(+), 7 deletions(-)
create mode 100644 drivers/atmodem/network-registration.h
create mode 100644 drivers/ubloxmodem/network-registration.c