From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>, ofono@lists.linux.dev
Cc: absicsz@gmail.com, merlijn@wizzup.org
Subject: Re: [PATCH 2/2] qmimodem: implement call-forwarding driver
Date: Fri, 16 Feb 2024 19:56:41 +0200 [thread overview]
Message-ID: <adfd3b78-68ba-87c1-ddf2-0a938b08396b@gmail.com> (raw)
In-Reply-To: <0f9ee157-6fcb-4042-860f-124a8c4335bc@gmail.com>
Hi Denis and thanks for the prompt reply!
On 16.02.24 г. 19:13 ч., Denis Kenzior wrote:
> Hi Ivaylo,
>
>>>
>>> I fixed up a small whitespace warning flagged by CI:
>>> 0002-qmimodem-implement-call-forwarding-driver.patch:394: WARNING:
>>> please, no space before tabs
>>>
>>
>> can I use checkpatch.pl from kernel scripts to verify the patches
>> before sending?
>
> Yes, of course. That is what the CI uses.
>
Ok, great.
>>
>> Thanks!
>>
>> BTW, looking at the dbus call forwarding interface, I think we have
>> issue in both org.ofono.SupplementaryServices and
>> org.ofono.CallForwarding interfaces: We can have call forwarding that
>> has phone number provisioned, but disabled. I don't see how that
>> information is populated - if I read the docs properly, when a
>> particular type of forwarding is disabled, the relevant property is an
>> empty string, but that does not reflect the provisioned value. Not
>> sure how can this
>
> My memory is fuzzy here, let me look into the relevant docs. This may
> be a limitation of the AT command spec, i.e. 27.007 or so?
>
Not really, according to
https://www.etsi.org/deliver/etsi_ts/127000_127099/127007/15.02.00_60/ts_127007v150200p.pdf
+CCFC provides status and optional phone number/type. And at least the
EC20 around me provides phone numbers for disabled forwarding.
>> be fixed without breaking the API. org.ofono.SupplementaryServices2
>> and org.ofono.CallForwarding2? Or additional properties, like
>> VoiceUnconditionalNetwork (bool enabled, string phone_number). What do
>> you think?
>
> Given that oFono is now 2.x, I think breaking APIs is an option,
> especially since there are few users of CallForwarding. Introducing API
> versioning might also work, but lets see if we can get away without it.
>
I don't know if SFOS guys will be happy with breaking the API :) .
Regards,
Ivo
prev parent reply other threads:[~2024-02-16 17:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 7:17 [0/2] qmimodem: add more drivers Ivaylo Dimitrov
2024-02-15 7:17 ` [PATCH 1/2] qmimodem: implement call-barring driver Ivaylo Dimitrov
2024-02-15 20:43 ` Denis Kenzior
2024-02-15 7:17 ` [PATCH 2/2] qmimodem: implement call-forwarding driver Ivaylo Dimitrov
2024-02-15 20:46 ` Denis Kenzior
2024-02-16 17:07 ` Ivaylo Dimitrov
2024-02-16 17:13 ` Denis Kenzior
2024-02-16 17:56 ` Ivaylo Dimitrov [this message]
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=adfd3b78-68ba-87c1-ddf2-0a938b08396b@gmail.com \
--to=ivo.g.dimitrov.75@gmail.com \
--cc=absicsz@gmail.com \
--cc=denkenz@gmail.com \
--cc=merlijn@wizzup.org \
--cc=ofono@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).