subject:"New to this"


Hi Pali,




I think you will need to do this regardless.  Otherwise I fail to see how
you prevent one 'agent' from consuming AT commands it shouldn't be. This is
a possibility you need to consider, whether it happens by accident or
maliciously.


Some subset of AT commands are needed to parse and interpret. But not
telephony commands and having up-to-date internal telephony state.


Please think some more about what I said.  You will need to parse every 
AT command in your daemon, no way around that.  You are right that you 
do not need to keep track of the telephony state, but that is besides 
the point.  So if you need an AT parser anyway, the whole reasoning for 
the proposed architecture starts to look shaky.







- The other example is more practical. HFP Service Level Connection (SLC)
establishment is actually quite tricky.  There are certain limitations on
what can and cannot be done prior to SLC establishment, including how audio
handling is done.


I know :-) I already implemented prototype implementation to check and
see how complicated it is and if API make sense and how hard it is for
agents (audio - pulseaudio) implement and maintain it.


Unfortunately, codec negotiation, indicator negotiation,
and feature negotiation are part of the SLC. oFono already solves all of
this and handles all of it nicely.


CSR codecs are not supported nor implemented in ofono. It is more
complicated as HFP codecs... and needs a new API for audio application.
Another value which brings my hsphfpd is that it handles these CSR
codecs and provide API for audio application to use them.



Again, you're not addressing my main point.  Codec negotiation is part 
of SLC establishment.  SLC has both telephony and audio aspects. 
They're inseparable.  Your architecture fails to address this...


CSR codecs are not part of SLC and can be bolted on later.  I already 
told you that oFono can easily be changed to support this.



We have passed all relevant
certification testing.  It is very unclear how you plan to handle this (or
whether you realistically even can) in your architecture when the
responsibilities are split between the various daemons.  So again, oFono has
nothing to gain here...


I was not thinking about certification. It is not something which I
could do And also pulseaudio itself do not have certifications.


So again, no reason for us to get involved :)

Bottom line is there's no value for us in this architecture.  If you 
want to use the existing oFono APIs, that's fine.  But we're not adding 
a plugin for taking arbitrary AT commands from some other daemon :)





Perhaps this can even be solved in oFono itself (since it already does 90%
of what you want) by making the modem requirement optional.  What we could
do for example is to create a dummy modem if an AG connection is requested
and no other suitable modems are detected in the system.  The resultant AG
wouldn't have any call control capability, it could still be used for
transferring audio data, battery, etc.  If you want to pursue this, we can
brainstorm further.


Well, if this would work automatically without any user interaction or
without special setup, it seems to be usable.

But what is needed from this implementation in ofono? Basically API for
each functionality designed in hsphfod daemon. And one of it is also
support for HSP profile (with CSR and Apple extensions).


Start a separate thread on ofono for this.  I already gave you hints on 
how to solve the 'AG without a real modem' use case.  That would seem to 
be the biggest 'win' and it should be fairly easy to make this work.




I'm not against for it, but I thought that having functionality which is
not related to telephony / modem you would not want to see in ofono
project (like linux uinput layer for button events or API for displaying
raw text on embedded display; or CSR audio codec negotiation).

So how do you see possibility to have also HSP profile in ofono? So have
one place which would provide audio API for SCO? Because this is a big
requirements from audio software side, to not use 4 different APIs to
access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
profiles.



HSP is a separate issue.  Maybe we can handle it like the 'dundee' 
daemon inside oFono (which handles Bluetooth DUN profile).  In other 
words have a dedicated daemon for hsp support that reuses the relevant 
bits of oFono and maybe exposes the same APIs (i.e the ones documented 
in doc/handsfree-audio-api.txt).  That would make life for PulseAudio 
pretty easy.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

Hi Pali,

There have been one or two implementations of AG role fully external to
oFono. These implementations simply used the existing oFono APIs to drive
the modem.

bluez & pulseaudio developers told me that it would be a good idea to
avoid implementing a new AT parser for telephony stack. And rather use
ofono implementation for telephony part...

In my opinion there's nothing scary about AT parsing. In fact that is
the easiest part of this whole venture. If you don't want to roll your
own parser, you can borrow one from the oFono project. We already
solved this nicely in the form of the gatchat library. You could
incorporate this into your project (if it is GPL compatible). Or you
could wait until we port gatchat to ell which will be under LGPL license.

But if I should use existing DBus API provided by ofono, it means that I
need to do parsing of all AT commands (including telephony) and
translate them to ofono DBus API.

I think you will need to do this regardless. Otherwise I fail to see
how you prevent one 'agent' from consuming AT commands it shouldn't be.
This is a possibility you need to consider, whether it happens by
accident or maliciously.

I agree, this should work and there is not need to modify ofono. But it
means that in hsphfpd daemon I need to have full AT parser for all
telephony commands and it was something which bluez / pa developers
thought that should be avoided. Therefore I come up with idea that
telephony commands would be handled by external Telephony Agent, which
can be ofono.

Understood. But I think the metric function was selected
inappropriately in this case. My opinion is that you should have
started with what the overall architecture should look like; you should
not have based design decisions on which parts might be a little hard to
implement.

You could do that. But as I said, we rejected such a design a
long time ago due to complexity and other issues.

Anyway, what is the problem with accepting modem socket in ofono via
DBus and starts talking with it like with any other modem which ofono
supports? Currently ofono already takes modem socket from bluez via DBus
API, so in same way hsphfpd can pass modem socket to ofono. Basically
ofono then can reuse same code which already uses for sockets from
bluez, just it do not have to parse and interpret audio related AT
commands (as these are handled by hsphpfd itself).

What are exact issues? I do not see complexity at ofono part (as has
already everything implemented) and currently I do not see those "other"
issues.

The issues are many. And really the question is not whether it 'could
be' done, but whether it 'should be' done. Let me describe a couple
examples:

- In the case of HF role (1), oFono already provides all the necessary
APIs. So put yourself in oFono's maintainer shoes. What would we gain
by supporting almost the same but different mechanism? We would have to
introduce a new hfp_hf plugin, one that is almost identical, but
different to hfp_hf_bluez5 plugin. These two plugins would have
coexistence issues, which would add more complexity. Then there's the
impact on PulseAudio and other users. How do they know when to use the
HandsfreeAudio API vs some external API? Supporting this new way buys
us a lot of extra code / complexity with no value added.

- The other example is more practical. HFP Service Level Connection
(SLC) establishment is actually quite tricky. There are certain
limitations on what can and cannot be done prior to SLC establishment,
including how audio handling is done. Unfortunately, codec negotiation,
indicator negotiation, and feature negotiation are part of the SLC.
oFono already solves all of this and handles all of it nicely. We have
passed all relevant certification testing. It is very unclear how you
plan to handle this (or whether you realistically even can) in your
architecture when the responsibilities are split between the various
daemons. So again, oFono has nothing to gain here...

You suggested to use phone simulator together with ofono and then
starts extending / patching phone simulator to supports all needed parts
which are in my hsphfpd design (battery status, button press, codec
selection)?

Not quite. I suggested you expand oFono's emulator implementation (for
AG role) and its DBus APIs (for HF role) to support the new vendor
specific features that you want.

Forget about the phone simulator, it is really irrelevant for what
you're trying to accomplish.

Also how to handle the main problem of phone simulator that it is too
much complicated to setup it on desktop? Looking at the steps...

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2

... that desktop user needs to run nontrivial commands in command like,
plus creating configuration file only just to connect bluetooth headset
is ridiculous and non-acceptable for deskt

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux


Hi Pali,


But would you accept patches which exports DBus API e.g. for displaying text
on HFP headset with embedded display? Or patches which implements 3
different way for reporting battery level status of HFP headset? And API
for sending "computer battery level" to HFP headset? Or implementing
setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
uinput linux device for button press events? Because all these


So which roles are we talking about here?  Your Design document shows
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
the intent?


My proposed hsphfpd is going to support both roles. Which means to
implement whole HFP profile. So for connecting bluetooth headsets (when
AG role is needed on desktop) and also for connecting mobile phones
(when HF role is needed on desktop).

And my primary motivation is for bluetooth headsets as this is what are
asking desktop and laptop users again and again that is missing on Linux
systems.

So higher priority has AG role and slightly lower priority has HF role.



So to summarize.  You have broadly 3 main use cases for HFP:

1. HF connecting to AG role.  Essentially a carkit role.  oFono does 
this pretty well already and has the APIs defined that cover up to HFP 
1.7.  Any vendor extensions can be easily added.  And some carkit 
manufacturers already use it.


2. AG role when you have a 'real modem' behind it.  oFono already 
provides everything needed for this scenario.


3. AG role when you don't have a real modem or you have some sort of 
VoIP use case.  oFono doesn't cover this case as you stated.


So I can see value in something that implements case #3.  But having 
said that, oFono will not be receiving AT commands from external daemons:
	- For case 1, it'd just be a rehash of what oFono does well already.  I 
reinvented a few wheels in my time, but doesn't mean I think this one 
should be.

- The reasoning for case 2/3 I already covered upthread.


If you're talking about extending oFono APIs when it is acting as the HF
connecting to the AG, then codec setup APIs, etc are definitely something
that would be welcome.

If you're talking about AG role, then that is different... In general, if
the oFono is in an AG role, then there should be nothing to configure and
there are no APIs for this role.


Codecs needs to be configured also in AG role. Before accepting SCO
connection you need to configure SCO socket for correct codec. Also for
vendor codecs it needs to be properly negotiated via AT commands.



Sure, but that doesn't mean they need an actual D-Bus API to be 
configured with.  You can simply extend oFono emulator to support 
whatever codecs you want and whatever custom AT command handling that 
you need.  If the HF requests the codec, then you use it.  There's no 
D-Bus API required here.  Again, take a look at how this is done in 
oFono today.



Such a design will get a NAK from me on the oFono side.  But don't let that
stop you.  You can simply invoke oFono APIs directly from your daemon.  No
need for any changes in oFono itself.  As mentioned above, I wouldn't
recommend it, but... :)


So if you are disagreeing with this design, can you propose alternative?
Which would support needs for desktop users? Support for HSP profile (in
AG role), support for HFP profile (in AG role), ability to parse and
interpret needed AT commands. And later also HS and HF role of these
profiles.



There have been one or two implementations of AG role fully external to 
oFono.  These implementations simply used the existing oFono APIs to 
drive the modem.  You could do that.  But as I said, we rejected such a 
design a long time ago due to complexity and other issues.


Or you can ignore the call control aspects entirely...

But in the end, it is your architecture.  All I can do is point out 
(early in the process) what is and what is not acceptable to oFono upstream.




Okay, I see now.  Yes, the above is correct.  My comments about not needing
a modem device hold true only if oFono is in HFP HF role connecting to an
AG.


Ok. So I guess now you understood main problem. I thought it was
obvious, but seems that bluetooth HFP is too complicated, so talking
about it always needs more detailed explanation. Sorry for that if it
was not clear from my side since beginning what are requirements for my
setup.


Well it was a bit of reading comprehension fail on my part as well.  The 
two roles are really quite different, so precise language helps.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux


Hi Pali,


Yes, I see. Also there are devices without HFP support, only with HSP.
pulseaudio support also these devices and pulseaudio is not going to
drop support for them. Last time when I looked at ofono, it has no HSP
support. Is ofono going to add support for HSP?



No.





But would you accept patches which exports DBus API e.g. for displaying text
on HFP headset with embedded display? Or patches which implements 3
different way for reporting battery level status of HFP headset? And API
for sending "computer battery level" to HFP headset? Or implementing
setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
uinput linux device for button press events? Because all these


So which roles are we talking about here?  Your Design document shows 
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was 
not the intent?


If you're talking about extending oFono APIs when it is acting as the HF 
connecting to the AG, then codec setup APIs, etc are definitely 
something that would be welcome.


If you're talking about AG role, then that is different... In general, 
if the oFono is in an AG role, then there should be nothing to configure 
and there are no APIs for this role.  Things like reporting AG battery 
level to HFP headset are done directly using plugins.  See 
ofono_emulator_set_indicator and how this is done by upower.c for 
example.  I happily take patches for any additional features (codecs, 
etc) you want to support here.


But... oFono upstream has no interest in accepting forwarded AT commands 
from some external daemon if we're in AG role.  We rejected such a 
design years ago and nothing has changed.


AG role is already quite tricky to implement without additional 
complexity introduced by having multiple applications and IPC.  "Its 
your funeral" as the saying goes if you want to go that route.





I disagree here. Primary purpose of HFP for desktop users is ability to
use bluetooth's microphone. And not telephony stack and its complicated
features like call hold and others, which are in HFP used and
implemented probably only in car kits.


So your primary goal here is to have the desktop play the role of the 
AG, purely so you can forward the audio from a headset out to whatever 
it is that you want.  And you want oFono (or some other daemon) to 
(optionally) handle the call related AT commands in the HFP AG role.


Such a design will get a NAK from me on the oFono side.  But don't let 
that stop you.  You can simply invoke oFono APIs directly from your 
daemon.  No need for any changes in oFono itself.  As mentioned above, I 
wouldn't recommend it, but... :)





Also for using ofono with HFP profile is not possible on desktop
computer which do not have any modem as it is hooked to some active
modem.


This statement is not true at all.  You can use oFono without any 'real'
modems attached.  It can happily manage only HFP devices (or modems as we
call them.)


Ok, can you please provide exact steps how to do it, including
activating of bidirectional audio stream?


So again, which role?  If we're the HF connecting to the AG, then things 
just work without a modem.  If we're the AG, then yes you need a modem 
to be driven by the AG connection.




You must be thinking of the oFono HFP AG implementation...


Yes! For connecting bluetooth headset you need HFP AG implementation.

And I guess this is the reason why simulator is needed. HFP headset acts
as a "client" for modem. Therefore on desktop / laptop you need to
implement "modem server" which will be used by HFP headset "client".

And phone simulator is doing exactly this "modem server", it is
simulator of modem.



Okay, I see now.  Yes, the above is correct.  My comments about not 
needing a modem device hold true only if oFono is in HFP HF role 
connecting to an AG.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux


Hi Pali,


I'm not sure what logic around HSP you really care about.  It is just a
single button press in the end.


CSR features (battery status level, ...) and CSR codec selection (e.g.
AuriStream). Also some apple extensions are used in HSP profile.


Since HFP can do everything that HSP can and more, I view HSP as 
deprecated and not to be used.  If these are also available in HFP, then 
I'd just use HFP instead.  But HSP was never my focus, so if you feel 
there's a need for better HSP support, then fair enough.





For HFP, oFono can already support all sorts of extensions.  See for example
how we handled Siri for HFP support in oFono here:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.


About Siri: In hsphfpd API it is delegated to Telephony Agent. So
hsphfpd is not going to (re)implement it.


I saw. But it does not support usage of vendor codecs, like CSR
AuriStream and it does not support CSR extensions, like displaying text
on embedded display.


But that's my point, you can easily accomplish this by creating another 
oFono API / atom for HFP CSR extensions and expose this information / 
functionality.  Similar to how Siri was done.  I see no need for a 
completely new external daemon.





Many of the extensions you talked about are also relevant for real modems as
well (like battery reporting, call volume, etc).  Some of these APIs are
already defined in fact.

Given the above, oFono upstream has no interest in adding or maintaining
support this new framework.


Maybe better question: Do you mean that you do not want to maintain
hsphfpd, or that you completely do not want to see that ofono would be
"Telepony Agent" for hsphfpd?


The latter.




Denis, if you are not interested in my proposed hsphfpd daemon, how you
want to solve problem with other extensions and other vendor codecs?



See above..


Also in my proposed solution it is possible to use HFP profile without
Telephony Agent (ofono). Do you think it is really a good idea to have
strong dependency on ofono just for bluetooth HFP headset?



Why not?  The main purpose of HFP is telephony; whether it is classic 
phone calls or skype/facetime.  oFono seems a natural fit.



Also for using ofono with HFP profile is not possible on desktop
computer which do not have any modem as it is hooked to some active
modem.


This statement is not true at all.  You can use oFono without any 'real' 
modems attached.  It can happily manage only HFP devices (or modems as 
we call them.)




There is a way to use ofono sim simulator which provide fake modem, but
its setup is hard on desktop and it not automated.



You must be thinking of the oFono HFP AG implementation...


So connecting bluetooth headset in HFP profile with ofono is something
not so easy and not an obvious way.



Again, not true.  As I said above, you can use oFono for this use case 
just fine.  Certainly the main driver for the development of oFono was 
to drive real modem hardware, but it isn't limited to that.  So if you 
want to use it only for HFP, you can.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux


Hi Pali,

On 12/16/19 3:15 AM, Pali Rohár wrote:

Hi!

On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:

Hi Pali,

On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár  wrote:


On Monday 02 December 2019 19:45:12 Pali Rohár wrote:

On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:

I think hsphfpd should be part of bluetoothd, but if that's not
possible, then that's not possible.


I do not know if bluez developers are interested in having this code as
part of bluez project, specially when in bluez4 HFP profile was there
and in bluez5 was HFP code completely removed.


Hello, could someone from bluez developers comment this Tanu's point?


I would have to say no, we are definitely not interested in yet
another daemon for AT parsing, we actually have too many of these
around, either in a form of Modem Manager, oFono, etc.


Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
implementing logic around HSP and HFP profiles and export either native
interfaces (linux uinput) or DBus interfaces for features provided by
HSP and HFP specifications and also for current and future vendor
extensions. And part of this HSP/HFP implementation is of course needed
parsing and interpreting some of AT commands. Look into my design and
API proposal. Current daemons which provides AT parsing (like ofono or
modem manager) are not suitable for for whole HSP and HFP profiles with
all those extensions (like all possible ways for reporting battery
level), so for HFP is needed some of custom AT parser.


I'm not sure what logic around HSP you really care about.  It is just a 
single button press in the end.


For HFP, oFono can already support all sorts of extensions.  See for 
example how we handled Siri for HFP support in oFono here:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt. 
 Many of the extensions you talked about are also relevant for real 
modems as well (like battery reporting, call volume, etc).  Some of 
these APIs are already defined in fact.


Given the above, oFono upstream has no interest in adding or maintaining 
support this new framework.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

2020-12-24 Thread Luiz Augusto von Dentz

Hi Pali,

On Mon, Dec 16, 2019 at 1:15 AM Pali Rohár  wrote:
>
> Hi!
>
> On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár  wrote:
> > >
> > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > possible, then that's not possible.
> > > >
> > > > I do not know if bluez developers are interested in having this code as
> > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > and in bluez5 was HFP code completely removed.
> > >
> > > Hello, could someone from bluez developers comment this Tanu's point?
> >
> > I would have to say no, we are definitely not interested in yet
> > another daemon for AT parsing, we actually have too many of these
> > around, either in a form of Modem Manager, oFono, etc.
>
> Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> implementing logic around HSP and HFP profiles and export either native
> interfaces (linux uinput) or DBus interfaces for features provided by
> HSP and HFP specifications and also for current and future vendor
> extensions. And part of this HSP/HFP implementation is of course needed
> parsing and interpreting some of AT commands. Look into my design and
> API proposal. Current daemons which provides AT parsing (like ofono or
> modem manager) are not suitable for for whole HSP and HFP profiles with
> all those extensions (like all possible ways for reporting battery
> level), so for HFP is needed some of custom AT parser.

Not following you on this one, oFono is intended for telephony
functionality and afaik it could parse battery, etc. Also would your
daemon include such functionality or you are to combine that with
oFono? I do appreciate the effort you have put into the SBC modes and
codec support but Im afraid you are going to experience some real pain
to maintain such a system all in your own, there are a lot of features
being exposed via AT commands and we risk to have yet another daemon
that just do parts of them until the next person comes with a
different use case and we are back to square one.

> > That said one
> > simpler way to resolve all of this is to maintain a plugin to
> > bluetoothd that way HSP/HFP becomes native again, that can either be
> > maintained in the tree or out of the tree.
>
> I do not see how could just plain plugin for bluez without AT parser
> could help. This seems to just complicate whole implementation. I
> already implemented prototype implementation of hsphfpd to see how
> complicated it is and what is needed...

Well the exactly the same thing with yet another daemon, we obviously
will need an AT parser, but the nice thing of being a native plugin is
that it can detect if another entity register for HSP/HFP and disable
itself (or have a policy to control that), the implementation can be
exactly what you have but without the extra rounds trips involved to
communicate back and forth with your daemon, so it is pretty straight
forward in terms o implementation.

> So if bluez daemon is not the right place for hsphpfd, it would be
> separate daemon outside of bluez.
>
> --
> Pali Rohár
> pali.ro...@gmail.com

-- 
Luiz Augusto von Dentz
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

2020-12-24 Thread Luiz Augusto von Dentz

Hi Pali,

On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár  wrote:
>
> On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > possible, then that's not possible.
> >
> > I do not know if bluez developers are interested in having this code as
> > part of bluez project, specially when in bluez4 HFP profile was there
> > and in bluez5 was HFP code completely removed.
>
> Hello, could someone from bluez developers comment this Tanu's point?

I would have to say no, we are definitely not interested in yet
another daemon for AT parsing, we actually have too many of these
around, either in a form of Modem Manager, oFono, etc. That said one
simpler way to resolve all of this is to maintain a plugin to
bluetoothd that way HSP/HFP becomes native again, that can either be
maintained in the tree or out of the tree.

-- 
Luiz Augusto von Dentz
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

2020-12-24 Thread Tanu Kaskinen

On Sun, 2019-12-01 at 19:57 +0100, Pali Rohár wrote:
> Hello!
> 
> I'm sending this email to relevant mailing lists and other people who
> could be interested in it. (I'm not subscribed to all of ML, so please
> CC me when replying).
> 
> 
> I would like to open a discussion about a completely new way of handling
> Bluetooth HSP and HFP profiles on Linux. These two profiles are the only
> standard way how to access microphone data from Bluetooth Headsets.
> 
> 
> Previously in bluez4, HFP profile was implemented by bluez daemon and
> telephony HFP functionality was provided by either dummy modem, ofono
> modem or by Nokia's CSD Maemo modem.
> 
> In bluez5 version was modem code together with implementation of HFP
> profile removed. And let implementation of HSP and HFP profiles to
> external application.
> 
> Currently HSP profile is implemented in pulseaudio daemon to handle
> microphone and Bluetooth speakers. HFP profile is not implemented yet.
> 
> 
> HSP and HFP profiles use AT modem commands, so its implementation needs
> to parse and generates AT commands, plus implement needed state machine
> for it.
> 
> And now problem is that last version of HFP profile specification is too
> complicated, plus Bluetooth headsets vendors started to inventing and
> using of own custom extensions to HFP profile and AT commands.
> 
> Main problem of this "external" implementation outside of bluez is that
> only one application can communicate with remote Bluetooth device. It
> is application which received needed socket from bluez.
> 
> So in this design if audio daemon (pulseaudio) implements HFP profile
> for processing audio, and e.g. power supply application wants to
> retrieve battery level from Bluetooth device, it means that audio daemon
> needs to implement also battery related functionality.
> 
> It does not make sense to force power supply daemon (upower) to
> implement audio routing/encoding/decoding or audio daemon (power supply)
> to force implementing battery related operations.
> 
> 
> For handle this problem I would like to propose a new way how to use and
> implement HSP and HFP profiles on Linux.
> 
> Implement a new HSP/HFP daemon (I called it hsphfpd) which register HSP
> and HFP profiles in bluez and then exports functionality for all other
> specific applications via DBus API (API for audio, power supply, input
> layer, telephony functions, vendor extensions, etc...). So it would acts
> as proxy daemon between bluez and target applications (pulseaudio,
> upower, ofono, ...)
> 
> This would simplify whole HFP usage as applications would not need to
> re-implement parsing and processing of AT commands and it would allow
> more applications to use HFP profile at one time. And also it means that
> audio software does not have to implement telephony stack or power
> supply operations.
> 
> 
> I wrote a document how such DBus API could look like, see here:
> 
>   https://github.com/pali/hsphfpd-prototype/raw/prototype/hsphfpd.txt
> 
> 
> And also I implemented "prototype" implementation to verify that
> designed API make sense and can be really implemented. Prototype fully
> supports HSP profile in both HS and AG role, plus HFP profile in HF
> role. This prototype implementation is available here:
> 
>   https://github.com/pali/hsphfpd-prototype
> 
> Some other details are written in README:
> 
>   https://github.com/pali/hsphfpd-prototype/raw/prototype/README
> 
> 
> What do you think about it? Does it make sense to have such design?
> Would you accept usage of such hsphfpd daemon, implemented according to
> specification, on Linux desktop?
> 
> I would like to hear your opinion if I should continue with this hsphfpd
> design, or not.
> 
> 
> With this design and implementation of hsphfpd is possible to easily fix
> pulseaudio issue about power supply properties:
> 
>   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/722

I quite like this proposal. Avoiding the need to implement the button
press, battery level etc. handling separately in PulseAudio, oFono and
PipeWire seems like a pretty good justification to me. I assume you're
volunteering to maintain this new daemon?

It's not clear to me how this would affect the PulseAudio <-> oFono
interaction, if at all. When oFono is used, would PulseAudio get the
audio socket from oFono or hsphfpd? What about volume commands, would
they go through oFono or would PulseAudio interact with hsphfpd
directly?

I think hsphfpd should be part of bluetoothd, but if that's not
possible, then that's not possible.

(I don't want to get into a lengthy discussion about programming
languages, but I'll just note here that I don't like Perl.)

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

New phonesim release including Qt5 support?

2020-10-29 Thread Simon Schmeisser

Hi,

I'm a member of the Plasma Mobile team and we are currently trying to
get our messaging and phone stack working. Having a distribution
packaged version of phonesim available would simplify things a lot for
us. However distributions are currently dropping Qt4 support and there
has been no release since Jonah Brüchert introduced support for Qt5 last
year.

So in short, could you please do a new release of phonesim?

Thanks and regards

Simon

___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Hi. I am starting new job with ofono with linux

2019-10-14 Thread khlee9228

Hello.

I am working with ofono on top of linux platform.
Until now, I am using android based modem like as Qualcomm QMI based modem.

I'd like to start with QT APP with ofono and linux 

How do I start ofono ?

Please let me know how do I start ofono job 

Paul.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Fix build with new ell

2019-05-16 Thread Denis Kenzior


Hi Sergey,

On 05/16/2019 01:12 AM, Sergey Chupligin wrote:

Hy everyone, how i can send path ti fix build with new ell ?



git send-email would be the preferable method.

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Fix build with new ell

2019-05-16 Thread Sergey Chupligin

Hy everyone, how i can send path ti fix build with new ell ? 
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 1/5] sim: Added new properties to simmanager for DSSA

2019-03-28 Thread Denis Kenzior


Hi Antara,

On 03/28/2019 07:04 AM, Antara Borwankar wrote:

Adding two new properties to sim manager interface to handle
dual SIM single active use case.

CardSlotCount [readonly]
Contains the count of number of SIM card slots available.

ActiveCardSlot [readwrite]
Contains the index of the currently active SIM card slot
for dual SIM single active mode.
---
  doc/sim-api.txt | 12 
  1 file changed, 12 insertions(+)

diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index bce47c1..c69cc74 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -205,3 +205,15 @@ Properties boolean Present [readonly]
  
  			Contains the SIM's ImsPrivateIdentity, read from the

ISIM.
+
+   uint32 CardSlotCount [readonly]
+
+   Contains the count of number of SIM card slots 
available.
+
+   uint32 ActiveCardSlot [readwrite]
+
+   Contains the index of the currently active SIM card slot
+   for dual SIM single active mode.
+
+   This property will range from 1 (default) to
+   CardSlotCount (max) value.



I amended this patch to mark both of these properties [experimental] and 
applied, thanks!


Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 1/5] sim: Added new properties to simmanager for DSSA

2019-03-28 Thread Antara Borwankar

Adding two new properties to sim manager interface to handle
dual SIM single active use case.

CardSlotCount [readonly]
Contains the count of number of SIM card slots available.

ActiveCardSlot [readwrite]
Contains the index of the currently active SIM card slot
for dual SIM single active mode.
---
 doc/sim-api.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index bce47c1..c69cc74 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -205,3 +205,15 @@ Properties boolean Present [readonly]
 
Contains the SIM's ImsPrivateIdentity, read from the
ISIM.
+
+   uint32 CardSlotCount [readonly]
+
+   Contains the count of number of SIM card slots 
available.
+
+   uint32 ActiveCardSlot [readwrite]
+
+   Contains the index of the currently active SIM card slot
+   for dual SIM single active mode.
+
+   This property will range from 1 (default) to
+   CardSlotCount (max) value.
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 2/6] sim: Added new properties to simmanager for DSSA

2019-03-27 Thread Denis Kenzior


Hi Pavel,

On 03/27/2019 07:25 AM, Pavel Machek wrote:

On Wed 2019-03-27 17:39:12, Antara Borwankar wrote:

Adding two new properties to sim manager interface to handle
dual SIM single active use case.

CardSlotCount [readonly]
Contains the count of number of SIM card slots available.

ActiveCardSlot [readwrite]
Contains the index of the currently active SIM card slot
for dual SIM single active mode.


Hmm. There are already modems which can have both SIMs active at the
same time. Would it make sense to have the APIs ready for that?

Pavel


This is better handled by instantiating multiple modem objects for each 
logical modem device.  In the case of Dual SIM Dual Active you 
essentially have 2 independent modems anyway.  Dual SIM Dual Standby is 
pretty similar except one 'modem' goes offline during a call.  Jolla has 
done it this way for example, but their APIs are bolted on top of the 
oFono one.


We could consider handling this as a single modem object with a bunch of 
API extensions (e.g. like allowing multiple sim atoms) as well.  Not 
sure if such a solution is better or worse.  Either way, I'm not aware 
of anyone working on this at the moment.


Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 2/6] sim: Added new properties to simmanager for DSSA

2019-03-27 Thread Pavel Machek

On Wed 2019-03-27 17:39:12, Antara Borwankar wrote:
> Adding two new properties to sim manager interface to handle
> dual SIM single active use case.
> 
> CardSlotCount [readonly]
> Contains the count of number of SIM card slots available.
> 
> ActiveCardSlot [readwrite]
> Contains the index of the currently active SIM card slot
> for dual SIM single active mode.

Hmm. There are already modems which can have both SIMs active at the
same time. Would it make sense to have the APIs ready for that?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 2/6] sim: Added new properties to simmanager for DSSA

2019-03-27 Thread Antara Borwankar

Adding two new properties to sim manager interface to handle
dual SIM single active use case.

CardSlotCount [readonly]
Contains the count of number of SIM card slots available.

ActiveCardSlot [readwrite]
Contains the index of the currently active SIM card slot
for dual SIM single active mode.
---
 doc/sim-api.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index bce47c1..c69cc74 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -205,3 +205,15 @@ Properties boolean Present [readonly]
 
Contains the SIM's ImsPrivateIdentity, read from the
ISIM.
+
+   uint32 CardSlotCount [readonly]
+
+   Contains the count of number of SIM card slots 
available.
+
+   uint32 ActiveCardSlot [readwrite]
+
+   Contains the index of the currently active SIM card slot
+   for dual SIM single active mode.
+
+   This property will range from 1 (default) to
+   CardSlotCount (max) value.
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 7/8] common: Add new NB-IoT technologies

2019-02-17 Thread Denis Kenzior


Hi Philippe,

On 02/15/2019 06:11 AM, philippedesw...@gmail.com wrote:

From: Philippe De Swert 

Add lte-cat-m1 and lte-cat-nb1 technology identifiers.
---
  src/common.c | 4 
  src/common.h | 2 ++
  2 files changed, 6 insertions(+)


Applied, thanks.

Regards,
-Denis

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 1/8] ublox-serial: add new plugin for u-blox

2019-02-17 Thread Jonas Bonn


Hi,

My overriding comment here is to try to combine this with the existing 
ublox plugin.  That said, there are some comments below.


/Jonas

On 15/02/2019 13:11, philippedesw...@gmail.com wrote:

From: Philippe De Swert 

Add support for ublox modems that are used over the serial port.
(tested on SARA-R410M and R412M)
---
  plugins/ublox-serial.c | 393 +
  plugins/udevng.c   |   1 +
  2 files changed, 394 insertions(+)
  create mode 100644 plugins/ublox-serial.c

diff --git a/plugins/ublox-serial.c b/plugins/ublox-serial.c
new file mode 100644
index ..4f0cf5f3
--- /dev/null
+++ b/plugins/ublox-serial.c
@@ -0,0 +1,393 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2014  Philip Paeps. All rights reserved.
+ *  Copyright (C) 2018-2019 Treon oy. All rights reserved.
+ *
+ *  Inspired on the Ublox driver by Philip Paeps
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static const char *none_prefix[] = { NULL };
+
+struct ublox_data {
+   GIOChannel *device;
+   GAtChat *modem;
+   GAtChat *dlc;
+   int model_id;
+   enum ofono_vendor vendor_family;
+   guint frame_size;
+};
+
+static void ublox_debug(const char *str, void *user_data)
+{
+   const char *prefix = user_data;
+
+   ofono_info("%s%s", prefix, str);
+}
+
+static int ublox_probe(struct ofono_modem *modem)
+{
+   struct ublox_data *data;
+
+   DBG("%p", modem);
+
+   data = g_try_new0(struct ublox_data, 1);
+   if (data == NULL)
+   return -ENOMEM;
+
+   ofono_modem_set_data(modem, data);
+
+   return 0;
+}
+
+static void ublox_remove(struct ofono_modem *modem)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   ofono_modem_set_data(modem, NULL);
+   g_at_chat_unref(data->modem);
+   g_free(data);
+}
+


Your implementation of open_device is the same as the implementation in 
ublox.c with the addition of communication settings.  You could easily 
add this as open_serial_device in the ublox.c and call it for serial modems.



+static GAtChat *open_device(struct ofono_modem *modem,
+   const char *key, char *debug)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   const char *device;
+   GAtSyntax *syntax;
+   GIOChannel *channel;
+   GAtChat *chat;
+   GHashTable *options;
+
+   device = ofono_modem_get_string(modem, key);
+   if (device == NULL)
+   {
+   DBG("device = NULL");
+   return NULL;
+   }
+   DBG("%s %s", key, device);
+
+options = g_hash_table_new(g_str_hash, g_str_equal);
+if (options == NULL)
+   return NULL;
+
+g_hash_table_insert(options, "Baud", "115200");
+g_hash_table_insert(options, "Parity", "none");
+g_hash_table_insert(options, "StopBits", "1");
+g_hash_table_insert(options, "DataBits", "8");
+g_hash_table_insert(options, "XonXoff", "on");
+g_hash_table_insert(options, "Local", "on");
+g_hash_table_insert(options, "RtsCts", "off");
+g_hash_table_insert(options, "Read", "on");
+
+   channel = g_at_tty_open(device, options);
+g_hash_table_destroy(options);
+
+   if (channel == NULL)
+   return NULL;
+
+   data->device = channel;
+   syntax = g_at_syntax_new_gsm_permissive();
+   chat = g_at_chat_new(channel, syntax);
+   g_at_syntax_unref(syntax);
+
+   g_io_channel_unref(channel);
+
+   if (chat == NULL)
+   return NULL;
+
+   if (getenv("OFONO_AT_DEBUG"))
+   g_at_chat_set_debug(chat, ublox_debug, debug);
+
+   return chat;
+}
+
+#if 0


Here's a big block of commented out code.  This isn't from the ublox 
driver...



+static

Re: [PATCH 1/8] ublox-serial: add new plugin for u-blox

2019-02-17 Thread Jonas Bonn


Hi,

On 16/02/2019 14:55, Philippe De Swert wrote:

Hi,

On 16/02/2019, Jonas Bonn  wrote:

Hi,

My spontaneous reaction to this is:  why does this need to be a separate
plugin?  At first glance, it appears to be largely a copy of the ublox
plugin and the seemingly small differences would have been easy to
finesse into the existing driver.
Could you provide some more justification for requiring a completely new
plugin here?


True it looks very similar, however the current driver works for USB
only and also uses muxing which seems to be buggy on the serial port.
(it eats error messages for example).



Could you elaborate on this?  If you don't want the mux'ing, you just 
skip setting up the channel (that you don't have, anyway).  There's no 
other mux'ing in the driver.  If you skip that, I can't immediately see 
that you are actually doing anything particularly different that will 
cause any change in how error messages are propagated.





Thanks,
Jonas

(Just for info, I'm working on support for the TOBY L4 currently... it
would be preferable to get as much u-blox support into one place as
possible rather than spreading it out over multiple plugins/drivers.
All these modems share common documentation, after all.)


I understand the sentiment but I did not immediately see a way to
combine the two, and giving the limited time to get it running making
it's own plugin turned out to be the easiest given the issues
(USB/broken mux) I ran into.


I spent some time looking at this... I really don't see that this 
warrants it's own plugin.  Half of the diff is just data->aux --> 
data->dlc renaming... the rest is simple stuff that's easily hidden 
behind model checks.  This is better implemented as incremental changes 
to the existing ublox plugin; that's much easier to review and provides 
better insight into what's going on.


Or provide more justification as to why having this as a separate plugin 
is absolute necessary.


Thanks,
/Jonas




Regards,

Philippe


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 1/8] ublox-serial: add new plugin for u-blox

2019-02-16 Thread Philippe De Swert

Hi,

On 16/02/2019, Jonas Bonn  wrote:
> Hi,
>
> My spontaneous reaction to this is:  why does this need to be a separate
> plugin?  At first glance, it appears to be largely a copy of the ublox
> plugin and the seemingly small differences would have been easy to
> finesse into the existing driver.
> Could you provide some more justification for requiring a completely new
> plugin here?

True it looks very similar, however the current driver works for USB
only and also uses muxing which seems to be buggy on the serial port.
(it eats error messages for example).

> Thanks,
> Jonas
>
> (Just for info, I'm working on support for the TOBY L4 currently... it
> would be preferable to get as much u-blox support into one place as
> possible rather than spreading it out over multiple plugins/drivers.
> All these modems share common documentation, after all.)

I understand the sentiment but I did not immediately see a way to
combine the two, and giving the limited time to get it running making
it's own plugin turned out to be the easiest given the issues
(USB/broken mux) I ran into.

Regards,

Philippe
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 1/8] ublox-serial: add new plugin for u-blox

2019-02-16 Thread Jonas Bonn


Hi,

My spontaneous reaction to this is:  why does this need to be a separate 
plugin?  At first glance, it appears to be largely a copy of the ublox 
plugin and the seemingly small differences would have been easy to 
finesse into the existing driver.


Could you provide some more justification for requiring a completely new 
plugin here?


Thanks,
Jonas

(Just for info, I'm working on support for the TOBY L4 currently... it 
would be preferable to get as much u-blox support into one place as 
possible rather than spreading it out over multiple plugins/drivers. 
All these modems share common documentation, after all.)


On 15/02/2019 13:11, philippedesw...@gmail.com wrote:

From: Philippe De Swert 

Add support for ublox modems that are used over the serial port.
(tested on SARA-R410M and R412M)
---
  plugins/ublox-serial.c | 393 +
  plugins/udevng.c   |   1 +
  2 files changed, 394 insertions(+)
  create mode 100644 plugins/ublox-serial.c

diff --git a/plugins/ublox-serial.c b/plugins/ublox-serial.c
new file mode 100644
index ..4f0cf5f3
--- /dev/null
+++ b/plugins/ublox-serial.c
@@ -0,0 +1,393 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2014  Philip Paeps. All rights reserved.
+ *  Copyright (C) 2018-2019 Treon oy. All rights reserved.
+ *
+ *  Inspired on the Ublox driver by Philip Paeps
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static const char *none_prefix[] = { NULL };
+
+struct ublox_data {
+   GIOChannel *device;
+   GAtChat *modem;
+   GAtChat *dlc;
+   int model_id;
+   enum ofono_vendor vendor_family;
+   guint frame_size;
+};
+
+static void ublox_debug(const char *str, void *user_data)
+{
+   const char *prefix = user_data;
+
+   ofono_info("%s%s", prefix, str);
+}
+
+static int ublox_probe(struct ofono_modem *modem)
+{
+   struct ublox_data *data;
+
+   DBG("%p", modem);
+
+   data = g_try_new0(struct ublox_data, 1);
+   if (data == NULL)
+   return -ENOMEM;
+
+   ofono_modem_set_data(modem, data);
+
+   return 0;
+}
+
+static void ublox_remove(struct ofono_modem *modem)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   ofono_modem_set_data(modem, NULL);
+   g_at_chat_unref(data->modem);
+   g_free(data);
+}
+
+static GAtChat *open_device(struct ofono_modem *modem,
+   const char *key, char *debug)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   const char *device;
+   GAtSyntax *syntax;
+   GIOChannel *channel;
+   GAtChat *chat;
+   GHashTable *options;
+
+   device = ofono_modem_get_string(modem, key);
+   if (device == NULL)
+   {
+   DBG("device = NULL");
+   return NULL;
+   }
+   DBG("%s %s", key, device);
+
+options = g_hash_table_new(g_str_hash, g_str_equal);
+if (options == NULL)
+   return NULL;
+
+g_hash_table_insert(options, "Baud", "115200");
+g_hash_table_insert(options, "Parity", "none");
+g_hash_table_insert(options, "StopBits", "1");
+g_hash_table_insert(options, "DataBits", "8");
+g_hash_table_insert(options, "XonXoff", "on");
+g_hash_table_insert(options, "Local", "on");
+g_hash_table_insert(options, "RtsCts", "off");
+g_hash_table_insert(options, "Read", "on");
+
+   channel = g_at_tty_open(device, options);
+g_hash_table_destroy(options);
+
+   if (channel == NULL)
+   return NULL;
+
+   data->device = channel;
+   syntax = g_at_syntax_new_gsm_permissive();
+   chat = g_at_chat_new(channel, syntax);
+   g_at_syntax_unref(syntax);
+
+   g_io_channel_unref(channel);
+
+   if (chat == NULL)
+

[PATCH 1/8] ublox-serial: add new plugin for u-blox

2019-02-15 Thread philippedeswert

From: Philippe De Swert 

Add support for ublox modems that are used over the serial port.
(tested on SARA-R410M and R412M)
---
 plugins/ublox-serial.c | 393 +
 plugins/udevng.c   |   1 +
 2 files changed, 394 insertions(+)
 create mode 100644 plugins/ublox-serial.c

diff --git a/plugins/ublox-serial.c b/plugins/ublox-serial.c
new file mode 100644
index ..4f0cf5f3
--- /dev/null
+++ b/plugins/ublox-serial.c
@@ -0,0 +1,393 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2014  Philip Paeps. All rights reserved.
+ *  Copyright (C) 2018-2019 Treon oy. All rights reserved.
+ *
+ *  Inspired on the Ublox driver by Philip Paeps
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static const char *none_prefix[] = { NULL };
+
+struct ublox_data {
+   GIOChannel *device;
+   GAtChat *modem;
+   GAtChat *dlc;
+   int model_id;
+   enum ofono_vendor vendor_family;
+   guint frame_size;
+};
+
+static void ublox_debug(const char *str, void *user_data)
+{
+   const char *prefix = user_data;
+
+   ofono_info("%s%s", prefix, str);
+}
+
+static int ublox_probe(struct ofono_modem *modem)
+{
+   struct ublox_data *data;
+
+   DBG("%p", modem);
+
+   data = g_try_new0(struct ublox_data, 1);
+   if (data == NULL)
+   return -ENOMEM;
+
+   ofono_modem_set_data(modem, data);
+
+   return 0;
+}
+
+static void ublox_remove(struct ofono_modem *modem)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   ofono_modem_set_data(modem, NULL);
+   g_at_chat_unref(data->modem);
+   g_free(data);
+}
+
+static GAtChat *open_device(struct ofono_modem *modem,
+   const char *key, char *debug)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   const char *device;
+   GAtSyntax *syntax;
+   GIOChannel *channel;
+   GAtChat *chat;
+   GHashTable *options;
+
+   device = ofono_modem_get_string(modem, key);
+   if (device == NULL)
+   {
+   DBG("device = NULL");
+   return NULL;
+   }
+   DBG("%s %s", key, device);
+
+options = g_hash_table_new(g_str_hash, g_str_equal);
+if (options == NULL)
+   return NULL;
+
+g_hash_table_insert(options, "Baud", "115200");
+g_hash_table_insert(options, "Parity", "none");
+g_hash_table_insert(options, "StopBits", "1");
+g_hash_table_insert(options, "DataBits", "8");
+g_hash_table_insert(options, "XonXoff", "on");
+g_hash_table_insert(options, "Local", "on");
+g_hash_table_insert(options, "RtsCts", "off");
+g_hash_table_insert(options, "Read", "on");
+
+   channel = g_at_tty_open(device, options);
+g_hash_table_destroy(options);
+
+   if (channel == NULL)
+   return NULL;
+
+   data->device = channel;
+   syntax = g_at_syntax_new_gsm_permissive();
+   chat = g_at_chat_new(channel, syntax);
+   g_at_syntax_unref(syntax);
+
+   g_io_channel_unref(channel);
+
+   if (chat == NULL)
+   return NULL;
+
+   if (getenv("OFONO_AT_DEBUG"))
+   g_at_chat_set_debug(chat, ublox_debug, debug);
+
+   return chat;
+}
+
+#if 0
+static GAtChat *create_chat(GIOChannel *channel, struct ofono_modem *modem,
+char *debug)
+{
+GAtSyntax *syntax;
+GAtChat *chat;
+
+if (channel == NULL)
+return NULL;
+
+syntax = g_at_syntax_new_gsmv1();
+chat = g_at_chat_new(channel, syntax);
+g_at_syntax_unref(syntax);
+g_io_channel_unref(channel);
+
+if (chat == NULL)
+return NULL;
+
+if (getenv("OFONO_AT_DEBUG"

[PATCH 7/8] common: Add new NB-IoT technologies

2019-02-15 Thread philippedeswert

From: Philippe De Swert 

Add lte-cat-m1 and lte-cat-nb1 technology identifiers.
---
 src/common.c | 4 
 src/common.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/src/common.c b/src/common.c
index ea7842cc..4dcbc835 100644
--- a/src/common.c
+++ b/src/common.c
@@ -697,6 +697,10 @@ const char *registration_tech_to_string(int tech)
return "hspa";
case ACCESS_TECHNOLOGY_EUTRAN:
return "lte";
+   case ACCESS_TECHNOLOGY_NB_IOT_M1:
+   return "lte-cat-m1";
+   case ACCESS_TECHNOLOGY_NB_IOT_NB1:
+   return "lte-cat-nb1";
default:
return "";
}
diff --git a/src/common.h b/src/common.h
index dc618942..8fef4432 100644
--- a/src/common.h
+++ b/src/common.h
@@ -33,6 +33,8 @@ enum access_technology {
ACCESS_TECHNOLOGY_UTRAN_HSUPA = 5,
ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA =   6,
ACCESS_TECHNOLOGY_EUTRAN =  7,
+   ACCESS_TECHNOLOGY_NB_IOT_M1 =   8,
+   ACCESS_TECHNOLOGY_NB_IOT_NB1 =  9,
 };
 
 /* 27.007 Section 7.2  */
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 2/8] Makefile.am : include new u-blox serial modem driver

2019-02-15 Thread philippedeswert

From: Philippe De Swert 

Make sure the new u-blox serial modem driver gets built.
---
 Makefile.am | 4 
 1 file changed, 4 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 6aa8f8fe..df7827d4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -596,6 +596,10 @@ builtin_sources += plugins/quectel.c
 builtin_modules += ublox
 builtin_sources += plugins/ublox.c
 
+
+builtin_modules += ubloxserial
+builtin_sources += plugins/ublox-serial.c
+
 builtin_modules += xmm7xxx
 builtin_sources += plugins/xmm7xxx.c
 
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin


Hi Giacinto,


Thank you for the explanation. Is the glib going to be removed
completely then, or both will coexist?



oFono is a large project, so eradicating use of glib cannot happen 
overnight.  For the foreseeable future we will have both coexist.  I 
will start 'encouraging' people to start using ell instead of glib. 
Especially for new code that does not depend on GAtChat, etc.



Denis pointed that the atom-configuration tests can be done in the
atoms themselves, except that then I am asked to maintain my own atom
when I want to add more than a couple lines (see the lte atom story).
Nevertheless this is an excellent suggestion to reduce the complexity
in the plugin.


You will end up writing many of your own atom drivers anyway.  voicecall 
for example.  For others we will figure this out, I've some ideas I need 
to play with.




Often MBIM can be turned on or off or changed for some other interface
for the same (Gemalto) modem, depending on the application wishes, so
if the plugin is split, all its settings are just duplicated.



This also implies having the modem reconfigure itself on the USB 
interface, no?  E.g. a hot-unplug and hot-plug.  I doubt many users will 
be doing this anyway.


If you're worried about duplicating vendor specific API code between 
multiple modem drivers, then don't.  This code can be shared easily and 
I've already given you a few ideas.


Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

Hi Marcel, Denis,


On Wed, Oct 31, 2018 at 9:19 PM Marcel Holtmann  wrote:
>
> Hi Giacinto,
>
>  So you might need to expand on this some more.  What is QMI+AT or
>  MBIM+AT actually doing?  Is there a single AT port? Multiple? What is
>  the AT port being used for, just vendor specific APIs or something more?
> >>>
> >>> MBIM and QMI are actually used only for the gprs-context atom.
> >>> The modems can work with the mbim or gobi plugin if they support the
> >>> respective protocols (I have tested them with changes in udevng), but
> >>> then we only get the bare minimum: no configuration options, hardware
> >>> monitor, low-power mode, gnss and its options, and the rest.
> >>> So, given that we need the AT interface anyway, everything is done
> >>> through it. It is also easier to debug than the big binary blog
> >>> (admittedly, wireshark helps a lot for mbim, but not sure for qmi).
> >>>
> >>
> >> You really need to decide what you want to do here.  If your modem is
> >> MBIM, then MBIM driver needs to be used.  I really don't want to get
> >> into situations where we build some Frankenstein driver with
> >> gprs-context being driven via MBIM and netreg being driven via AT commands.
> >>
> >> I can understand if you have MBIM + a GPS/GNSS port and want to expose
> >> location-reporting on that.  Ok, fine, I get that.  I can also
> >> understand if you want to use the AT command port for some vendor
> >> specific extensions not available via MBIM.  But I would need serious
> >> convincing of anything beyond this.
> >>
> >>> MBIM support works a bit differently depending on the chipset
> >>> manufacturer. The drivers/mbim/gprs-context works out of the box for
> >>> some models, while for others it is necessary to create the PDP
> >>> context with AT+CGDCONT. But this is dealt with a dedicated atom, only
> >>> the atom selection is visible in the plugin.
> >>
> >> So explain that one to me?  You send all context details in
> >> MBIM_CID_CONNECT.  So why would a CGDCONT be needed?
> >>
> >>>
> >>> enough for the detour. Back to the plug-in initialization: the
> >>> different models have zillion of differences. Whenever possible, I
> >>> prefer to ask the modem, otherwise it is if/switch depending on the
> >>> model.
> >>> Example of the first case: all Gemalto modems support the AT^SAIC
> >>> command if there is voice support (I checked down to the MC55 that
> >>> were like rel.98 or earlier).
> >>
> >> You do realize that all this probing can be done in the individual atom
> >> driver, right?  Even as far as the driver being able to call
> >> ofono_foo_remove if support is lacking.
> >>
> >>> All switches are independent from each other, working on a simple
> >>> principle, like for voice: ascertain if the feature is present and
> >>> with which options, then select the right atom and atom options.
> >>> There are quite a few, but maintainable thanks to that. Unfortunately
> >>> not all features can be probed at startup because some require to be
> >>> online, so the checks are split in 3 parts: pre-defined with PID,
> >>> tested during the enable phase (could be shifted to pre-sim to have a
> >>> faster enable), and in post-online.
> >>
> >> We've been through this, no AT commands should be executed in pre_sim,
> >> post_sim, post_online hooks...
> >>
> >>> And this is the part to maintain. If I split the plugins in 3
> >>> independent ones, I need to duplicate and maintain this.
> >>
> >> No, you really don't.  It might take a while for you to be convinced 
> >> though.
> >>
> >>> mbim/qmi/plainAt will disappear. And all the vendor-specific atoms
> >>> will have to be duplicated too.
> >>
> >> Again, they really don't need to be duplicated...
> >>
>  Since it sounds like this is a very esoteric use case, you might want to
>  schedule this last.  Right now it just distracts from the core 
>  discussion.
> >>>
> >>> ok for having it last, but it is not so esoteric.
> >>> Take for example the audio settings (which most likely exist for all
> >>> other vendors): you can select the type of interface
> >>> (analog/digital/usb), the port to use in case there is more than one,
> >>> suboptions like I2C or PCM, master/slave, and quite some other.
> >>> They could be set in a quite large vendor-specific interface (I saw
> >>> some tried it in an atom), but the configuration is fixed for the end
> >>> application, and - as you explained - will raise more problems than it
> >>> solves exposing these settings through dbus.
> >>> So the best is to run a couple of commands to set the interface
> >>> properly for the product and that's it.
> >>
> >> I understand.  But this is also why we have audio-settings atom.  So all
> >> such details can be easily put in there and its relevant driver.  If you
> >> want to have some simple configuration file that is read by your driver
> >> where the user can select between some common configurations that is
> >> fine as well.
> >>
> >> One can also add

Re: [RFC PATCH] new gemalto plugin

2018-10-31 Thread Marcel Holtmann

Hi Giacinto,

 So you might need to expand on this some more.  What is QMI+AT or
 MBIM+AT actually doing?  Is there a single AT port? Multiple? What is
 the AT port being used for, just vendor specific APIs or something more?
>>> 
>>> MBIM and QMI are actually used only for the gprs-context atom.
>>> The modems can work with the mbim or gobi plugin if they support the
>>> respective protocols (I have tested them with changes in udevng), but
>>> then we only get the bare minimum: no configuration options, hardware
>>> monitor, low-power mode, gnss and its options, and the rest.
>>> So, given that we need the AT interface anyway, everything is done
>>> through it. It is also easier to debug than the big binary blog
>>> (admittedly, wireshark helps a lot for mbim, but not sure for qmi).
>>> 
>> 
>> You really need to decide what you want to do here.  If your modem is
>> MBIM, then MBIM driver needs to be used.  I really don't want to get
>> into situations where we build some Frankenstein driver with
>> gprs-context being driven via MBIM and netreg being driven via AT commands.
>> 
>> I can understand if you have MBIM + a GPS/GNSS port and want to expose
>> location-reporting on that.  Ok, fine, I get that.  I can also
>> understand if you want to use the AT command port for some vendor
>> specific extensions not available via MBIM.  But I would need serious
>> convincing of anything beyond this.
>> 
>>> MBIM support works a bit differently depending on the chipset
>>> manufacturer. The drivers/mbim/gprs-context works out of the box for
>>> some models, while for others it is necessary to create the PDP
>>> context with AT+CGDCONT. But this is dealt with a dedicated atom, only
>>> the atom selection is visible in the plugin.
>> 
>> So explain that one to me?  You send all context details in
>> MBIM_CID_CONNECT.  So why would a CGDCONT be needed?
>> 
>>> 
>>> enough for the detour. Back to the plug-in initialization: the
>>> different models have zillion of differences. Whenever possible, I
>>> prefer to ask the modem, otherwise it is if/switch depending on the
>>> model.
>>> Example of the first case: all Gemalto modems support the AT^SAIC
>>> command if there is voice support (I checked down to the MC55 that
>>> were like rel.98 or earlier).
>> 
>> You do realize that all this probing can be done in the individual atom
>> driver, right?  Even as far as the driver being able to call
>> ofono_foo_remove if support is lacking.
>> 
>>> All switches are independent from each other, working on a simple
>>> principle, like for voice: ascertain if the feature is present and
>>> with which options, then select the right atom and atom options.
>>> There are quite a few, but maintainable thanks to that. Unfortunately
>>> not all features can be probed at startup because some require to be
>>> online, so the checks are split in 3 parts: pre-defined with PID,
>>> tested during the enable phase (could be shifted to pre-sim to have a
>>> faster enable), and in post-online.
>> 
>> We've been through this, no AT commands should be executed in pre_sim,
>> post_sim, post_online hooks...
>> 
>>> And this is the part to maintain. If I split the plugins in 3
>>> independent ones, I need to duplicate and maintain this.
>> 
>> No, you really don't.  It might take a while for you to be convinced though.
>> 
>>> mbim/qmi/plainAt will disappear. And all the vendor-specific atoms
>>> will have to be duplicated too.
>> 
>> Again, they really don't need to be duplicated...
>> 
 Since it sounds like this is a very esoteric use case, you might want to
 schedule this last.  Right now it just distracts from the core discussion.
>>> 
>>> ok for having it last, but it is not so esoteric.
>>> Take for example the audio settings (which most likely exist for all
>>> other vendors): you can select the type of interface
>>> (analog/digital/usb), the port to use in case there is more than one,
>>> suboptions like I2C or PCM, master/slave, and quite some other.
>>> They could be set in a quite large vendor-specific interface (I saw
>>> some tried it in an atom), but the configuration is fixed for the end
>>> application, and - as you explained - will raise more problems than it
>>> solves exposing these settings through dbus.
>>> So the best is to run a couple of commands to set the interface
>>> properly for the product and that's it.
>> 
>> I understand.  But this is also why we have audio-settings atom.  So all
>> such details can be easily put in there and its relevant driver.  If you
>> want to have some simple configuration file that is read by your driver
>> where the user can select between some common configurations that is
>> fine as well.
>> 
>> One can also add additional drivers / plugins out-of-tree that would be
>> dynamically loaded and do whatever they desire.  But reading a file and
>> blindly executing AT commands in a daemon that is running as root is
>> just asking for trouble.  I don't really care what you

Re: [RFC PATCH] new gemalto plugin


Hi Giacinto,



MBIM is not even supported through the glib, but through the ell
library that is itself quite fresh (and for which there is little
advantage instead of the glib. Maybe because using glib you have to
listen to someone else's opinion for pushing changes).


Look, I understand you're unhappy, but please don't make stuff up.  We 
are unhappy with glib due to its size (including the GObject stuff) and 
not for any other reason you speculate.


And ell is now almost 7 years old and used by multiple serious projects. 
 It is now also a dependency for oFono starting with the next release.

So please, stop the negativity.  It is uncalled for.

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

H Pavel,

On Wed, Oct 31, 2018 at 7:03 PM Pavel Machek  wrote:
>
> Hi!
>
> > > Also, there are security and interference aspects to consider.  One can
> > > send some AT command that interferes with the functioning of an atom
> > > driver for example and then your entire system breaks.  Trust me, it is
> > > just not a good idea.  If you want to shoot yourself in the foot, be my
> > > guest.  But it isn't going upstream ;)
> >
> > it's ok, GPLv2 just requires me to publish the changes I have done to
> > the code, not to fight to get them upstream.
>
> Actually, GPLv2 does not you require to publish your changes.
>
> It just (approximately) means that if you give binaries to someone, you give 
> them
> sources, too...
>

even better!

> Best regards,
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Regards,
Giacinto
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

Hi,

On Wed, Oct 31, 2018 at 8:23 PM Denis Kenzior  wrote:
>
> Hi Marcel,
>
> >
> > I think that MBIM (and even QMI) have AT passthrough options. So by all 
> > means, the main transport suppose to be MBIM here. I always prefer if only 
> > one hardware port is opened and there is no need to open more.
>
> I've seen QMI over MBIM some vendor extended service UIDs.  Not sure
> about AT over MBIM.  If someone knows more, feel free to educate me.
>
> Isn't AT over QMI also possible?  And in theory AT over QMI over MBIM, lol.
>

AT over MBIM is possible, but we decided not to implement it.
The big advantage of MBIM is a ready-made driver on Windows and on
MM/ofono. Adding AT over it would mean reworking the driver, so no
more advantages.
Over QMI I don't know.
QMI over MBIM is also possible, but with the same disadvantage as AT over MBIM.

> Regards,
> -Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin


Hi Marcel,



I think that MBIM (and even QMI) have AT passthrough options. So by all means, 
the main transport suppose to be MBIM here. I always prefer if only one 
hardware port is opened and there is no need to open more.


I've seen QMI over MBIM some vendor extended service UIDs.  Not sure 
about AT over MBIM.  If someone knows more, feel free to educate me.


Isn't AT over QMI also possible?  And in theory AT over QMI over MBIM, lol.

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

2018-10-31 Thread Marcel Holtmann

Hi Denis,

>>> So you might need to expand on this some more.  What is QMI+AT or
>>> MBIM+AT actually doing?  Is there a single AT port? Multiple? What is
>>> the AT port being used for, just vendor specific APIs or something more?
>> MBIM and QMI are actually used only for the gprs-context atom.
>> The modems can work with the mbim or gobi plugin if they support the
>> respective protocols (I have tested them with changes in udevng), but
>> then we only get the bare minimum: no configuration options, hardware
>> monitor, low-power mode, gnss and its options, and the rest.
>> So, given that we need the AT interface anyway, everything is done
>> through it. It is also easier to debug than the big binary blog
>> (admittedly, wireshark helps a lot for mbim, but not sure for qmi).
> 
> You really need to decide what you want to do here.  If your modem is MBIM, 
> then MBIM driver needs to be used.  I really don't want to get into 
> situations where we build some Frankenstein driver with gprs-context being 
> driven via MBIM and netreg being driven via AT commands.
> 
> I can understand if you have MBIM + a GPS/GNSS port and want to expose 
> location-reporting on that.  Ok, fine, I get that.  I can also understand if 
> you want to use the AT command port for some vendor specific extensions not 
> available via MBIM.  But I would need serious convincing of anything beyond 
> this.

I think that MBIM (and even QMI) have AT passthrough options. So by all means, 
the main transport suppose to be MBIM here. I always prefer if only one 
hardware port is opened and there is no need to open more.

Regards

Marcel

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin


Hi Giacinto,


So you might need to expand on this some more.  What is QMI+AT or
MBIM+AT actually doing?  Is there a single AT port? Multiple? What is
the AT port being used for, just vendor specific APIs or something more?


MBIM and QMI are actually used only for the gprs-context atom.
The modems can work with the mbim or gobi plugin if they support the
respective protocols (I have tested them with changes in udevng), but
then we only get the bare minimum: no configuration options, hardware
monitor, low-power mode, gnss and its options, and the rest.
So, given that we need the AT interface anyway, everything is done
through it. It is also easier to debug than the big binary blog
(admittedly, wireshark helps a lot for mbim, but not sure for qmi).



You really need to decide what you want to do here.  If your modem is 
MBIM, then MBIM driver needs to be used.  I really don't want to get 
into situations where we build some Frankenstein driver with 
gprs-context being driven via MBIM and netreg being driven via AT commands.


I can understand if you have MBIM + a GPS/GNSS port and want to expose 
location-reporting on that.  Ok, fine, I get that.  I can also 
understand if you want to use the AT command port for some vendor 
specific extensions not available via MBIM.  But I would need serious 
convincing of anything beyond this.



MBIM support works a bit differently depending on the chipset
manufacturer. The drivers/mbim/gprs-context works out of the box for
some models, while for others it is necessary to create the PDP
context with AT+CGDCONT. But this is dealt with a dedicated atom, only
the atom selection is visible in the plugin.


So explain that one to me?  You send all context details in 
MBIM_CID_CONNECT.  So why would a CGDCONT be needed?




enough for the detour. Back to the plug-in initialization: the
different models have zillion of differences. Whenever possible, I
prefer to ask the modem, otherwise it is if/switch depending on the
model.
Example of the first case: all Gemalto modems support the AT^SAIC
command if there is voice support (I checked down to the MC55 that
were like rel.98 or earlier).


You do realize that all this probing can be done in the individual atom 
driver, right?  Even as far as the driver being able to call 
ofono_foo_remove if support is lacking.



All switches are independent from each other, working on a simple
principle, like for voice: ascertain if the feature is present and
with which options, then select the right atom and atom options.
There are quite a few, but maintainable thanks to that. Unfortunately
not all features can be probed at startup because some require to be
online, so the checks are split in 3 parts: pre-defined with PID,
tested during the enable phase (could be shifted to pre-sim to have a
faster enable), and in post-online.


We've been through this, no AT commands should be executed in pre_sim, 
post_sim, post_online hooks...



And this is the part to maintain. If I split the plugins in 3
independent ones, I need to duplicate and maintain this.


No, you really don't.  It might take a while for you to be convinced though.


mbim/qmi/plainAt will disappear. And all the vendor-specific atoms
will have to be duplicated too.


Again, they really don't need to be duplicated...


Since it sounds like this is a very esoteric use case, you might want to
schedule this last.  Right now it just distracts from the core discussion.


ok for having it last, but it is not so esoteric.
Take for example the audio settings (which most likely exist for all
other vendors): you can select the type of interface
(analog/digital/usb), the port to use in case there is more than one,
suboptions like I2C or PCM, master/slave, and quite some other.
They could be set in a quite large vendor-specific interface (I saw
some tried it in an atom), but the configuration is fixed for the end
application, and - as you explained - will raise more problems than it
solves exposing these settings through dbus.
So the best is to run a couple of commands to set the interface
properly for the product and that's it.


I understand.  But this is also why we have audio-settings atom.  So all 
such details can be easily put in there and its relevant driver.  If you 
want to have some simple configuration file that is read by your driver 
where the user can select between some common configurations that is 
fine as well.


One can also add additional drivers / plugins out-of-tree that would be 
dynamically loaded and do whatever they desire.  But reading a file and 
blindly executing AT commands in a daemon that is running as root is 
just asking for trouble.  I don't really care what you do in your 
products, but I'm not taking security holes upstream.




Have you considered just having your modem driver auto-magically setting
the time into the modem and forgetting all this API business?



I'll look into this with the customer who proposed it, most likely
reading this

Re: [RFC PATCH] new gemalto plugin

2018-10-31 Thread Pavel Machek

Hi!

> > Also, there are security and interference aspects to consider.  One can
> > send some AT command that interferes with the functioning of an atom
> > driver for example and then your entire system breaks.  Trust me, it is
> > just not a good idea.  If you want to shoot yourself in the foot, be my
> > guest.  But it isn't going upstream ;)
> 
> it's ok, GPLv2 just requires me to publish the changes I have done to
> the code, not to fight to get them upstream.

Actually, GPLv2 does not you require to publish your changes.

It just (approximately) means that if you give binaries to someone, you give 
them
sources, too...

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

RE: [PATCH] udev: udpate udev to detect new 7xxx modems

2018-10-31 Thread Rebello, Nandini

Hi, 

Happen to spend time with old modems and validated code. Found a more cleaner 
approach.
Please consider the next path.

Regards,
Nandini 

-Original Message-
From: Giacinto Cifelli [mailto:gciof...@gmail.com] 
Sent: Wednesday, October 31, 2018 12:29 PM
To: Rebello, Nandini 
Cc: ofono@ofono.org; Borwankar, Antara ; Gargi, 
Anirudh 
Subject: Re: [PATCH] udev: udpate udev to detect new 7xxx modems

Hi,

On Wed, Oct 31, 2018 at 7:54 AM Nandini Rebello  
wrote:
>
> Newer intel modems enumerate with different subsystem numbers, adding 
> code to detect newer 7xxx modules.
>
> Plan to add patch for backward compatibility of intels modems soon, to 
> based on interface number instead of subsystem name string.
> ---
>  plugins/udevng.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/plugins/udevng.c b/plugins/udevng.c index 
> 11338f7..bf0b1c4 100644
> --- a/plugins/udevng.c
> +++ b/plugins/udevng.c
> @@ -1194,10 +1194,10 @@ static gboolean setup_xmm7xxx(struct modem_info 
> *modem)
> info->sysattr, info->subsystem);
>
> if (g_strcmp0(info->subsystem, "tty") == 0) {
> -   if (g_strcmp0(info->number, "02") == 0)
> +   if (g_strcmp0(info->number, "00") == 0)

but then all current users of the models using the usb device 02 (and
00 below) will be cut off if they update to this patch.
Maybe you need to add the switching logic you mentioned above based on 
interface number in the same patch.

> mdm = info->devnode;
> } else if (g_strcmp0(info->subsystem, "net") == 0) {
> -   if (g_strcmp0(info->number, "00") == 0)
> +   if (g_strcmp0(info->number, "06") == 0)
> net = info->devnode;
> }
> }
> --
> 2.7.4
>
> ___
> ofono mailing list
> ofono@ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono

regards,
Giacinto
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

RE: [PATCH] udev: udpate udev to detect new 7xxx modems

2018-10-31 Thread Navik, Ankit P

Hi Nandini, 

> -Original Message-
> From: ofono [mailto:ofono-boun...@ofono.org] On Behalf Of Nandini Rebello
> Sent: Wednesday, October 31, 2018 12:26 PM
> To: ofono@ofono.org
> Cc: Borwankar, Antara ; Gargi, Anirudh
> ; Rebello, Nandini 
> Subject: [PATCH] udev: udpate udev to detect new 7xxx modems
> 
> Newer intel modems enumerate with different subsystem numbers, adding code
> to detect newer 7xxx modules.
> 
> Plan to add patch for backward compatibility of intels modems soon, to based
> on interface number instead of subsystem name string.
> ---
>  plugins/udevng.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/plugins/udevng.c b/plugins/udevng.c index 11338f7..bf0b1c4 100644
> --- a/plugins/udevng.c
> +++ b/plugins/udevng.c
> @@ -1194,10 +1194,10 @@ static gboolean setup_xmm7xxx(struct
> modem_info *modem)
>   info->sysattr, info->subsystem);
> 
>   if (g_strcmp0(info->subsystem, "tty") == 0) {
> - if (g_strcmp0(info->number, "02") == 0)
> + if (g_strcmp0(info->number, "00") == 0)
>   mdm = info->devnode;
>   } else if (g_strcmp0(info->subsystem, "net") == 0) {
> - if (g_strcmp0(info->number, "00") == 0)
> + if (g_strcmp0(info->number, "06") == 0)
Can this be maintained as separate patch in board support package ?
The reason is, this will be keep on getting change with different series of xmm 
modem.

Regards, 
Ankit

>   net = info->devnode;
>   }
>   }
> --
> 2.7.4
> 
> ___
> ofono mailing list
> ofono@ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH] udev: udpate udev to detect new 7xxx modems

Hi,

On Wed, Oct 31, 2018 at 7:54 AM Nandini Rebello
 wrote:
>
> Newer intel modems enumerate with different subsystem numbers,
> adding code to detect newer 7xxx modules.
>
> Plan to add patch for backward compatibility of intels modems soon,
> to based on interface number instead of subsystem name string.
> ---
>  plugins/udevng.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/plugins/udevng.c b/plugins/udevng.c
> index 11338f7..bf0b1c4 100644
> --- a/plugins/udevng.c
> +++ b/plugins/udevng.c
> @@ -1194,10 +1194,10 @@ static gboolean setup_xmm7xxx(struct modem_info 
> *modem)
> info->sysattr, info->subsystem);
>
> if (g_strcmp0(info->subsystem, "tty") == 0) {
> -   if (g_strcmp0(info->number, "02") == 0)
> +   if (g_strcmp0(info->number, "00") == 0)

but then all current users of the models using the usb device 02 (and
00 below) will be cut off if they update to this patch.
Maybe you need to add the switching logic you mentioned above based on
interface number in the same patch.

> mdm = info->devnode;
> } else if (g_strcmp0(info->subsystem, "net") == 0) {
> -   if (g_strcmp0(info->number, "00") == 0)
> +   if (g_strcmp0(info->number, "06") == 0)
> net = info->devnode;
> }
> }
> --
> 2.7.4
>
> ___
> ofono mailing list
> ofono@ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono

regards,
Giacinto
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

Hi Denis,

On Tue, Oct 30, 2018 at 4:23 PM Denis Kenzior  wrote:
>
> Hi Giacinto,
>
> >> So just a cursory look through this, but overall my impression is that
> >> this code would be utterly unmaintainable.  You need to split this up
> >> into something without a bazillion if conditions and #ifdefs in it.
> >> Notice how none of our existing driver code uses #ifdefs.
> >
> > In your existing code, there are a few models from each vendor,
> > partially supported, with hardcoded choices for several options.
> >
>
> We can only do so much without docs.  Remember, much of these drivers
> were community contributed based on reverse engineering efforts or if
> lucky, leaked docs which were frequently incomplete.  So let me flip
> this around and ask where were you all this time? ;)

The point here is that it is the first time a large scale operation is
attempted.
I find it normal to have all kind of options for all the models.
It won't be easy to maintain, I agree.

Below I see that your main concerns are about mixed-mode drivers,
which make only a part of the if's, all the branching is at the moment
limited to the initialization.

>
> >>
> >> That means MBIM/QMI/AT logic needs to be separated into separate
> >> drivers.  If you have a weird QMI/AT or MBIM/AT or QMI over MBIM
> >> combination stuff going on, then these all need to be separate drivers.
> >>
> >
> > Several modems are either qmi+at or mbim+at, while others are simply
> > at (for example with ppp, ecm, ncm networking).
>
> So you might need to expand on this some more.  What is QMI+AT or
> MBIM+AT actually doing?  Is there a single AT port? Multiple? What is
> the AT port being used for, just vendor specific APIs or something more?

MBIM and QMI are actually used only for the gprs-context atom.
The modems can work with the mbim or gobi plugin if they support the
respective protocols (I have tested them with changes in udevng), but
then we only get the bare minimum: no configuration options, hardware
monitor, low-power mode, gnss and its options, and the rest.
So, given that we need the AT interface anyway, everything is done
through it. It is also easier to debug than the big binary blog
(admittedly, wireshark helps a lot for mbim, but not sure for qmi).

>
> >
> > The qmi and mbim part is limited to initialization and gprs-context,
> > the rest is common.
> > Shall I duplicate everything for this?
>
> I don't really have a recommendation yet as I don't have enough info.
> But, in general, we prefer duplication over convoluted code.  This is
> because you can turn features off via configure / plugin blacklisting.
> If you have one giant unified driver, then your hands are tied.

The plugin works this way: if mbim is detected, it is initialized, and
then up to 2 AT interfaces are probed.
The same for qmi: if qmi is detected, it is initialized, and then up
to 2 AT interfaces are probed.
If ELL is not used, mbim is skipped and the modem will use PPP from
atmodem/gprs-context.
The same would be true for qmi, but there is no ifdef, so there is no
need for fallback options.
Apart from its length, the code is quite simple. When the mbim or qmi
initialization is finished, successfully or not, the plugin moves to
the AT interfaces.

QMI support is quite straightforward: only a quick initialization,
basically to make sure it is there. It doesn't need all the gobi
plugin init sequence.
MBIM is more elaborate, it needs to exchange a few frames for a proper
initialization, but then again, it finishes here. This initialization
follows the mbim plugin up to a point, but does not need the entire
mbim plugin enable sequence.
MBIM support works a bit differently depending on the chipset
manufacturer. The drivers/mbim/gprs-context works out of the box for
some models, while for others it is necessary to create the PDP
context with AT+CGDCONT. But this is dealt with a dedicated atom, only
the atom selection is visible in the plugin.

enough for the detour. Back to the plug-in initialization: the
different models have zillion of differences. Whenever possible, I
prefer to ask the modem, otherwise it is if/switch depending on the
model.
Example of the first case: all Gemalto modems support the AT^SAIC
command if there is voice support (I checked down to the MC55 that
were like rel.98 or earlier).
All switches are independent from each other, working on a simple
principle, like for voice: ascertain if the feature is present and
with which options, then select the right atom and atom options.
There are quite a few, but maintainable thanks to that. Unfortunately
not all features can be probed at startup because some require to be
online, so the checks are split in 3 parts: pre-defined with PID,
tested during the enable phase (could be shifted to pre-sim to have a
faster enable), and in post-online.
And this is the part to maintain. If I split the plugins in 3
independent ones, I need to duplicate and maintain this.

>
> >
> > The #ifdefs are a choice of the project for

[PATCH] udev: udpate udev to detect new 7xxx modems

2018-10-31 Thread Nandini Rebello

Newer intel modems enumerate with different subsystem numbers,
adding code to detect newer 7xxx modules.

Plan to add patch for backward compatibility of intels modems soon,
to based on interface number instead of subsystem name string.
---
 plugins/udevng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 11338f7..bf0b1c4 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1194,10 +1194,10 @@ static gboolean setup_xmm7xxx(struct modem_info *modem)
info->sysattr, info->subsystem);
 
if (g_strcmp0(info->subsystem, "tty") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
+   if (g_strcmp0(info->number, "00") == 0)
mdm = info->devnode;
} else if (g_strcmp0(info->subsystem, "net") == 0) {
-   if (g_strcmp0(info->number, "00") == 0)
+   if (g_strcmp0(info->number, "06") == 0)
net = info->devnode;
}
}
-- 
2.7.4

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH] new gemalto plugin

2018-10-30 Thread Denis Kenzior


Hi Giacinto,


So just a cursory look through this, but overall my impression is that
this code would be utterly unmaintainable.  You need to split this up
into something without a bazillion if conditions and #ifdefs in it.
Notice how none of our existing driver code uses #ifdefs.


In your existing code, there are a few models from each vendor,
partially supported, with hardcoded choices for several options.



We can only do so much without docs.  Remember, much of these drivers 
were community contributed based on reverse engineering efforts or if 
lucky, leaked docs which were frequently incomplete.  So let me flip 
this around and ask where were you all this time? ;)




That means MBIM/QMI/AT logic needs to be separated into separate
drivers.  If you have a weird QMI/AT or MBIM/AT or QMI over MBIM
combination stuff going on, then these all need to be separate drivers.



Several modems are either qmi+at or mbim+at, while others are simply
at (for example with ppp, ecm, ncm networking).


So you might need to expand on this some more.  What is QMI+AT or 
MBIM+AT actually doing?  Is there a single AT port? Multiple? What is 
the AT port being used for, just vendor specific APIs or something more?




The qmi and mbim part is limited to initialization and gprs-context,
the rest is common.
Shall I duplicate everything for this?


I don't really have a recommendation yet as I don't have enough info. 
But, in general, we prefer duplication over convoluted code.  This is 
because you can turn features off via configure / plugin blacklisting. 
If you have one giant unified driver, then your hands are tied.




The #ifdefs are a choice of the project for the ELL, otherwise it
would be simply, well-integrated ifs (like for qmi).
I understand that the use of ELL will be extended in the future, why
not go all the way, remove the #ifdefs, and declare a full dependency?


We can do that.  But that won't really help you in the grand scheme of 
things.  My point still stands though, we cannot have a bazillion if 
conditions in the driver with dozens/hundreds of different forks.  That 
just does not lead to maintainable code.  Lets work smarter, not harder 
here.




Reading stored commands and executing them.
It is intended to configure the modem for a specific application.
There are hooks for each state of the modem state machine.

There isn't much interest in passing these commands through an
interface, because each application has its own configuration and
sends a different set of commands.
And it is modem-specific, so  it is stored by USB VID-PID.



Since it sounds like this is a very esoteric use case, you might want to 
schedule this last.  Right now it just distracts from the core discussion.




So first question is, why would you want to do this?  These days most
systems use the time on the Application processor.  Who cares what the
modem thinks the time is.


Some systems care: this comes in fact from an application (and will be
committed mentioning a co-author).
And it helps for timestamps in case of stack logs.



So who do you think is going to be responsible for setting the time 
appropriately in the modem?  Remember, oFono is a user-centric API.  We 
don't expose stuff that is not somehow visible to the user.


Have you considered just having your modem driver auto-magically setting 
the time into the modem and forgetting all this API business?




No AT command pass through in oFono upstream ;)  We've had this
conversation many times, if there are useful AT commands that can be
sent via this interface, then they should be abstracted behind a proper
API instead.


I may have misunderstood your comments the one time we had the conversation.
I don't understand your blind refusal: cluttering the interface with
every single command that an application may need for some special
events doesn't seem that brilliant.


As I said, we're a user-centric and use-case centric API.  If a typical 
user doesn't see this or doesn't know what to do with something, then 
don't expose it.  If you can't explain a use case for something, don't 
expose it.  No typical user is going to send arbitrary AT commands and 
'application may need special events' is also not a valid use case.


Also, there are security and interference aspects to consider.  One can 
send some AT command that interferes with the functioning of an atom 
driver for example and then your entire system breaks.  Trust me, it is 
just not a good idea.  If you want to shoot yourself in the foot, be my 
guest.  But it isn't going upstream ;)



So the modem is doing the property validation?  Yeah, not happening ;)


The name and number of properties vary by the models.
There isn't much to validate in a general way. Null perhaps, or an
arbitrary maximum length.
This interface is supposed to use GetProperties and then can change
some of them.
That the set property is in the list returned by GetProperties can be verified.



Yeah, again.  Not a valid usecase.

Re: [RFC PATCH] new gemalto plugin

2018-10-29 Thread Denis Kenzior


Hi Giacinto,

On 10/26/2018 01:10 AM, Giacinto Cifelli wrote:

I would like to submit to your attention the new version of the Gemalto
plugin. It is not ready, but would already benefit from some feedback.
The purpose of this new plugin is to address most of the Gemalto modules
(excluding perhaps some LTE CatM and CatNB), interfaced either via USB
or RS232 interface.


So just a cursory look through this, but overall my impression is that 
this code would be utterly unmaintainable.  You need to split this up 
into something without a bazillion if conditions and #ifdefs in it. 
Notice how none of our existing driver code uses #ifdefs.


That means MBIM/QMI/AT logic needs to be separated into separate 
drivers.  If you have a weird QMI/AT or MBIM/AT or QMI over MBIM 
combination stuff going on, then these all need to be separate drivers.


You may want to basically start with the basics.  Get the initial driver 
separation figured out, then you can add fancy stuff like vendor 
specific APIs, etc.  Right now they just clutter the code and are not 
really useful to a wide audience anyway.




I have included the totality of file plugins/gemalto.c because it is
quite different from the current one.

I would appreciate a generic comment on how to split it in commits
this file.

I have added an include/gemalto.h file, as suggested by Jonas Bonn.
There isn't much in it yet, but some additional code should be moved into
it.

The gprs and gprs-context's are perhaps not finished.

In udevng there are 3 additional commits, please just comment if you
like and find them useful and I will submit separately.

There are some review comments, in // format, not part of the code.

---
  include/gemalto.h |   27 +
  plugins/gemalto.c | 2715 +
  plugins/udevng.c  |  208 ++--
  3 files changed, 2885 insertions(+), 65 deletions(-)
  create mode 100644 include/gemalto.h
  create mode 100644 plugins/gemalto.c

diff --git a/include/gemalto.h b/include/gemalto.h
new file mode 100644
index ..26165eb1
--- /dev/null
+++ b/include/gemalto.h
@@ -0,0 +1,27 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2018 Gemalto M2M
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+enum auth_option {
+   GEMALTO_AUTH_DEFAULTS   = 0,
+   GEMALTO_AUTH_USE_SGAUTH = 1<<0,
+   GEMALTO_AUTH_ORDER_PWD_USR  = 1<<1,
+   GEMALTO_AUTH_ALWAYS_ALL_PARAMS  = 1<<2,
+};
diff --git a/plugins/gemalto.c b/plugins/gemalto.c
new file mode 100644
index ..6b208572
--- /dev/null
+++ b/plugins/gemalto.c
@@ -0,0 +1,2715 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2017 Vincent Cesson. All rights reserved.
+ *  Copyright (C) 2018 Gemalto M2M
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ofono.h"
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef HAVE_ELL
+#include 
+#include 
+#include 
+#include 
+#endif
// some models can use MBIM, but if the option is not included,
// they fall back to PPP
+
+#include 
+#include 
+#include "gemalto.h"
+
// the next part will not be in the official commit
+/* debug utilities - begin */
+
+#define REDCOLOR "\x1b\x5b\x30\x31\x3b\x33\x31\x6d"
+#define NOCOLOR "\x1b\x5b\x30\x30\x6d"
+
+#include 
+#include 
+#include 
+#include 
+
+voi

[RFC PATCH] new gemalto plugin

2018-10-26 Thread Giacinto Cifelli

I would like to submit to your attention the new version of the Gemalto
plugin. It is not ready, but would already benefit from some feedback.
The purpose of this new plugin is to address most of the Gemalto modules
(excluding perhaps some LTE CatM and CatNB), interfaced either via USB
or RS232 interface.

I have included the totality of file plugins/gemalto.c because it is
quite different from the current one.

I would appreciate a generic comment on how to split it in commits
this file.

I have added an include/gemalto.h file, as suggested by Jonas Bonn.
There isn't much in it yet, but some additional code should be moved into
it.

The gprs and gprs-context's are perhaps not finished.

In udevng there are 3 additional commits, please just comment if you
like and find them useful and I will submit separately.

There are some review comments, in // format, not part of the code.

---
 include/gemalto.h |   27 +
 plugins/gemalto.c | 2715 +
 plugins/udevng.c  |  208 ++--
 3 files changed, 2885 insertions(+), 65 deletions(-)
 create mode 100644 include/gemalto.h
 create mode 100644 plugins/gemalto.c

diff --git a/include/gemalto.h b/include/gemalto.h
new file mode 100644
index ..26165eb1
--- /dev/null
+++ b/include/gemalto.h
@@ -0,0 +1,27 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2018 Gemalto M2M
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+enum auth_option {
+   GEMALTO_AUTH_DEFAULTS   = 0,
+   GEMALTO_AUTH_USE_SGAUTH = 1<<0,
+   GEMALTO_AUTH_ORDER_PWD_USR  = 1<<1,
+   GEMALTO_AUTH_ALWAYS_ALL_PARAMS  = 1<<2,
+};
diff --git a/plugins/gemalto.c b/plugins/gemalto.c
new file mode 100644
index ..6b208572
--- /dev/null
+++ b/plugins/gemalto.c
@@ -0,0 +1,2715 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2017 Vincent Cesson. All rights reserved.
+ *  Copyright (C) 2018 Gemalto M2M
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ofono.h"
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef HAVE_ELL
+#include 
+#include 
+#include 
+#include 
+#endif
// some models can use MBIM, but if the option is not included,
// they fall back to PPP
+
+#include 
+#include 
+#include "gemalto.h"
+
// the next part will not be in the official commit
+/* debug utilities - begin */
+
+#define REDCOLOR "\x1b\x5b\x30\x31\x3b\x33\x31\x6d"
+#define NOCOLOR "\x1b\x5b\x30\x30\x6d"
+
+#include 
+#include 
+#include 
+#include 
+
+void print_trace();
+
+void print_trace() {
+char pid_buf[30];
+char name_buf[512];
+int child_pid;
+sprintf(pid_buf, "%d", getpid());
+name_buf[readlink("/proc/self/exe", name_buf, 511)]=0;
+child_pid = fork();
+if (!child_pid) {
+dup2(2,1); // redirect output to stderr
+fprintf(stdout,"stack trace for %s pid=%s\n",name_buf,pid_buf);
+execlp("gdb", "gdb", "--batch", "-n", "-ex", "thread", "-ex", "bt", 
name_buf, pid_buf, NULL);
+abort(); /* If gdb failed to start */
+} else {
+waitpid(child_pid,NULL,0);
+}
+}
+
+/* debug utilities - end */
+
+enum gemalto_connection_type {
+   GEMALTO_CONNECTION_SERIAL = 1,
+

Re: [PATCH] test: add support for new languages

2018-10-15 Thread Denis Kenzior


Hi Nandini,

On 10/12/2018 03:12 AM, Nandini Rebello wrote:

Adding new language support to set "alphabet" parameter.
---
  test/set-sms-alphabet | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)



Applied, thanks.

Regards,
-Denis

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH] test: add support for new languages

2018-10-12 Thread Nandini Rebello

Adding new language support to set "alphabet" parameter.
---
 test/set-sms-alphabet | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/test/set-sms-alphabet b/test/set-sms-alphabet
index 5573891..ca099fc 100644
--- a/test/set-sms-alphabet
+++ b/test/set-sms-alphabet
@@ -15,7 +15,9 @@ elif len(sys.argv) == 2:
path = modems[0][0]
alphabet = sys.argv[1]
 else:
-   print("%s [PATH] turkish|spanish|portuguese|bengali|gujarati" % 
(sys.argv[0]))
+   print("%s [PATH] turkish|spanish|portuguese|bengali|gujarati|hindi \
+ |kannada|malayalam|oriya|punjabi|tamil|telugu|urdu" %
+   (sys.argv[0]))
sys.exit(1)
 
 print("Setting alphabet for modem %s..." % path)
-- 
2.7.4

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 11/12] voicecall: Use new voicecall enums

---
 src/voicecall.c | 144 
 1 file changed, 73 insertions(+), 71 deletions(-)

diff --git a/src/voicecall.c b/src/voicecall.c
index e4f6a4c..a5de038 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -177,10 +177,10 @@ static const char *disconnect_reason_to_string(enum 
ofono_disconnect_reason r)
 static const char *phone_and_clip_to_string(const struct ofono_phone_number *n,
int clip_validity)
 {
-   if (clip_validity == CLIP_VALIDITY_WITHHELD && !strlen(n->number))
+   if (clip_validity == OFONO_CLIP_VALIDITY_WITHHELD && !strlen(n->number))
return "withheld";
 
-   if (clip_validity == CLIP_VALIDITY_NOT_AVAILABLE)
+   if (clip_validity == OFONO_CLIP_VALIDITY_NOT_AVAILABLE)
return "";
 
return phone_number_to_string(n);
@@ -188,10 +188,10 @@ static const char *phone_and_clip_to_string(const struct 
ofono_phone_number *n,
 
 static const char *cnap_to_string(const char *name, int cnap_validity)
 {
-   if (cnap_validity == CNAP_VALIDITY_WITHHELD && !strlen(name))
+   if (cnap_validity == OFONO_CNAP_VALIDITY_WITHHELD && !strlen(name))
return "withheld";
 
-   if (cnap_validity == CNAP_VALIDITY_NOT_AVAILABLE)
+   if (cnap_validity == OFONO_CNAP_VALIDITY_NOT_AVAILABLE)
return "";
 
return name;
@@ -227,20 +227,20 @@ static unsigned int voicecalls_num_with_status(struct 
ofono_voicecall *vc,
 
 static unsigned int voicecalls_num_active(struct ofono_voicecall *vc)
 {
-   return voicecalls_num_with_status(vc, CALL_STATUS_ACTIVE);
+   return voicecalls_num_with_status(vc, OFONO_CALL_STATUS_ACTIVE);
 }
 
 static unsigned int voicecalls_num_held(struct ofono_voicecall *vc)
 {
-   return voicecalls_num_with_status(vc, CALL_STATUS_HELD);
+   return voicecalls_num_with_status(vc, OFONO_CALL_STATUS_HELD);
 }
 
 static unsigned int voicecalls_num_connecting(struct ofono_voicecall *vc)
 {
unsigned int r = 0;
 
-   r += voicecalls_num_with_status(vc, CALL_STATUS_DIALING);
-   r += voicecalls_num_with_status(vc, CALL_STATUS_ALERTING);
+   r += voicecalls_num_with_status(vc, OFONO_CALL_STATUS_DIALING);
+   r += voicecalls_num_with_status(vc, OFONO_CALL_STATUS_ALERTING);
 
return r;
 }
@@ -253,9 +253,9 @@ static gboolean voicecalls_have_active(struct 
ofono_voicecall *vc)
for (l = vc->call_list; l; l = l->next) {
v = l->data;
 
-   if (v->call->status == CALL_STATUS_ACTIVE ||
-   v->call->status == CALL_STATUS_DIALING ||
-   v->call->status == CALL_STATUS_ALERTING)
+   if (v->call->status == OFONO_CALL_STATUS_ACTIVE ||
+   v->call->status == OFONO_CALL_STATUS_DIALING ||
+   v->call->status == OFONO_CALL_STATUS_ALERTING)
return TRUE;
}
 
@@ -280,17 +280,17 @@ static gboolean voicecalls_have_with_status(struct 
ofono_voicecall *vc,
 
 static gboolean voicecalls_have_held(struct ofono_voicecall *vc)
 {
-   return voicecalls_have_with_status(vc, CALL_STATUS_HELD);
+   return voicecalls_have_with_status(vc, OFONO_CALL_STATUS_HELD);
 }
 
 static gboolean voicecalls_have_waiting(struct ofono_voicecall *vc)
 {
-   return voicecalls_have_with_status(vc, CALL_STATUS_WAITING);
+   return voicecalls_have_with_status(vc, OFONO_CALL_STATUS_WAITING);
 }
 
 static gboolean voicecalls_have_incoming(struct ofono_voicecall *vc)
 {
-   return voicecalls_have_with_status(vc, CALL_STATUS_INCOMING);
+   return voicecalls_have_with_status(vc, OFONO_CALL_STATUS_INCOMING);
 }
 
 static void dial_request_finish(struct ofono_voicecall *vc)
@@ -314,11 +314,11 @@ static gboolean voicecalls_can_dtmf(struct 
ofono_voicecall *vc)
for (l = vc->call_list; l; l = l->next) {
v = l->data;
 
-   if (v->call->status == CALL_STATUS_ACTIVE)
+   if (v->call->status == OFONO_CALL_STATUS_ACTIVE)
return TRUE;
 
/* Connected for 2nd stage dialing */
-   if (v->call->status == CALL_STATUS_ALERTING)
+   if (v->call->status == OFONO_CALL_STATUS_ALERTING)
return TRUE;
}
 
@@ -405,7 +405,7 @@ static void append_voicecall_properties(struct voicecall *v,
 
ofono_dbus_dict_append(dict, "State", DBUS_TYPE_STRING, );
 
-   if (call->direction == CALL_DIRECTION_MOBILE_TERMINATED)
+   if (call->direction == OFONO_CALL_DIRECTION_MOBILE_TERMINATED)
callerid = phone_and_clip_to_string(>phone_number,
call->clip_validity);
else
@@ -427,9 +427,9 @@ static void append_voicecall_properties(struct voicecall *v,
 
ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, );

[PATCH 12/12] common: Use new voicecall enums

---
 src/common.c | 20 ++--
 src/common.h | 33 +
 2 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/src/common.c b/src/common.c
index 3ccaf7c..06b3521 100644
--- a/src/common.c
+++ b/src/common.c
@@ -740,26 +740,26 @@ const char *ofono_uuid_to_str(const struct ofono_uuid 
*uuid)
 void ofono_call_init(struct ofono_call *call)
 {
memset(call, 0, sizeof(struct ofono_call));
-   call->cnap_validity = CNAP_VALIDITY_NOT_AVAILABLE;
-   call->clip_validity = CLIP_VALIDITY_NOT_AVAILABLE;
+   call->cnap_validity = OFONO_CNAP_VALIDITY_NOT_AVAILABLE;
+   call->clip_validity = OFONO_CLIP_VALIDITY_NOT_AVAILABLE;
 }
 
-const char *call_status_to_string(enum call_status status)
+const char *call_status_to_string(enum ofono_call_status status)
 {
switch (status) {
-   case CALL_STATUS_ACTIVE:
+   case OFONO_CALL_STATUS_ACTIVE:
return "active";
-   case CALL_STATUS_HELD:
+   case OFONO_CALL_STATUS_HELD:
return "held";
-   case CALL_STATUS_DIALING:
+   case OFONO_CALL_STATUS_DIALING:
return "dialing";
-   case CALL_STATUS_ALERTING:
+   case OFONO_CALL_STATUS_ALERTING:
return "alerting";
-   case CALL_STATUS_INCOMING:
+   case OFONO_CALL_STATUS_INCOMING:
return "incoming";
-   case CALL_STATUS_WAITING:
+   case OFONO_CALL_STATUS_WAITING:
return "waiting";
-   case CALL_STATUS_DISCONNECTED:
+   case OFONO_CALL_STATUS_DISCONNECTED:
return "disconnected";
}
 
diff --git a/src/common.h b/src/common.h
index 1b6b01d..5fc9617 100644
--- a/src/common.h
+++ b/src/common.h
@@ -53,13 +53,6 @@ enum operator_status {
OPERATOR_STATUS_FORBIDDEN = 3,
 };
 
-/* 27.007 Section 7.6 */
-enum clip_validity {
-   CLIP_VALIDITY_VALID =   0,
-   CLIP_VALIDITY_WITHHELD =1,
-   CLIP_VALIDITY_NOT_AVAILABLE =   2,
-};
-
 /* 27.007 Section 7.29 */
 enum packet_bearer {
PACKET_BEARER_NONE =0,
@@ -72,30 +65,6 @@ enum packet_bearer {
PACKET_BEARER_EPS = 7,
 };
 
-/* 27.007 Section 7.30 */
-enum cnap_validity {
-   CNAP_VALIDITY_VALID =   0,
-   CNAP_VALIDITY_WITHHELD =1,
-   CNAP_VALIDITY_NOT_AVAILABLE =   2,
-};
-
-/* 27.007 Section 7.18 */
-enum call_status {
-   CALL_STATUS_ACTIVE =0,
-   CALL_STATUS_HELD =  1,
-   CALL_STATUS_DIALING =   2,
-   CALL_STATUS_ALERTING =  3,
-   CALL_STATUS_INCOMING =  4,
-   CALL_STATUS_WAITING =   5,
-   CALL_STATUS_DISCONNECTED
-};
-
-/* 27.007 Section 7.18 */
-enum call_direction {
-   CALL_DIRECTION_MOBILE_ORIGINATED =  0,
-   CALL_DIRECTION_MOBILE_TERMINATED =  1,
-};
-
 /* 27.007 Section 7.11 */
 enum bearer_class {
BEARER_CLASS_VOICE =1,
@@ -184,4 +153,4 @@ const char *registration_tech_to_string(int tech);
 const char *packet_bearer_to_string(int bearer);
 
 gboolean is_valid_apn(const char *apn);
-const char *call_status_to_string(enum call_status status);
+const char *call_status_to_string(enum ofono_call_status status);
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 08/12] cdma-voicecall: Use new voicecall enums

---
 src/cdma-voicecall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cdma-voicecall.c b/src/cdma-voicecall.c
index fd38dd8..90cad10 100644
--- a/src/cdma-voicecall.c
+++ b/src/cdma-voicecall.c
@@ -251,7 +251,7 @@ static void manager_dial_callback(const struct ofono_error 
*error, void *data)
}
 
voicecall_set_call_lineid(vc);
-   vc->direction = CALL_DIRECTION_MOBILE_ORIGINATED;
+   vc->direction = OFONO_CALL_DIRECTION_MOBILE_ORIGINATED;
voicecall_set_call_status(vc, CDMA_CALL_STATUS_DIALING);
 
reply = dbus_message_new_method_return(vc->pending);
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 09/12] emulator: Use new voicecall enums

---
 src/emulator.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/emulator.c b/src/emulator.c
index ccb26dc..bda8f35 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -404,9 +404,9 @@ static gboolean notify_ccwa(void *user_data)
!em->ccwa)
goto end;
 
-   c = find_call_with_status(em, CALL_STATUS_WAITING);
+   c = find_call_with_status(em, OFONO_CALL_STATUS_WAITING);
 
-   if (c && c->clip_validity == CLIP_VALIDITY_VALID) {
+   if (c && c->clip_validity == OFONO_CLIP_VALIDITY_VALID) {
phone = phone_number_to_string(>phone_number);
sprintf(str, "+CCWA: \"%s\",%d", phone, c->phone_number.type);
 
@@ -439,19 +439,19 @@ static gboolean notify_ring(void *user_data)
if (!em->clip)
return TRUE;
 
-   c = find_call_with_status(em, CALL_STATUS_INCOMING);
+   c = find_call_with_status(em, OFONO_CALL_STATUS_INCOMING);
 
if (c == NULL)
return TRUE;
 
switch (c->clip_validity) {
-   case CLIP_VALIDITY_VALID:
+   case OFONO_CLIP_VALIDITY_VALID:
phone = phone_number_to_string(>phone_number);
sprintf(str, "+CLIP: \"%s\",%d", phone, c->phone_number.type);
g_at_server_send_unsolicited(em->server, str);
break;
 
-   case CLIP_VALIDITY_WITHHELD:
+   case OFONO_CLIP_VALIDITY_WITHHELD:
g_at_server_send_unsolicited(em->server, "+CLIP: \"\",128");
break;
}
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 10/12] stk: Use new voicecall enums

---
 src/stk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/stk.c b/src/stk.c
index 9cdf2b1..eb27555 100644
--- a/src/stk.c
+++ b/src/stk.c
@@ -1732,7 +1732,7 @@ static void call_setup_connected(struct ofono_call *call, 
void *data)
static struct ofono_error error = { .type = OFONO_ERROR_TYPE_FAILURE };
static unsigned char facility_rejected_result[] = { 0x9d };
 
-   if (call == NULL || call->status == CALL_STATUS_DISCONNECTED) {
+   if (call == NULL || call->status == OFONO_CALL_STATUS_DISCONNECTED) {
memset(, 0, sizeof(rsp));
 
ADD_ERROR_RESULT(rsp.result,
@@ -1745,7 +1745,7 @@ static void call_setup_connected(struct ofono_call *call, 
void *data)
return;
}
 
-   if (call->status == CALL_STATUS_ACTIVE)
+   if (call->status == OFONO_CALL_STATUS_ACTIVE)
send_simple_response(stk, STK_RESULT_TYPE_SUCCESS);
else
send_simple_response(stk, STK_RESULT_TYPE_USER_CANCEL);
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 06/12] rilmodem: Use new voicecall enums

---
 drivers/rilmodem/voicecall.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rilmodem/voicecall.c b/drivers/rilmodem/voicecall.c
index b7180b9..585f216 100644
--- a/drivers/rilmodem/voicecall.c
+++ b/drivers/rilmodem/voicecall.c
@@ -288,7 +288,7 @@ no_calls:
 * arrives, or RING is used, then signal the call
 * here
 */
-   if (nc->status == CALL_STATUS_INCOMING &&
+   if (nc->status == OFONO_CALL_STATUS_INCOMING &&
(vd->flags & FLAG_NEED_CLIP)) {
if (nc->type)
ofono_voicecall_notify(vc, nc);
@@ -490,7 +490,7 @@ void ril_dial(struct ofono_voicecall *vc, const struct 
ofono_phone_number *ph,
for (l = vd->calls; l; l = l->next) {
call = l->data;
 
-   if (call->status == CALL_STATUS_ACTIVE) {
+   if (call->status == OFONO_CALL_STATUS_ACTIVE) {
current_active = 1;
break;
}
@@ -536,7 +536,7 @@ void ril_hangup_all(struct ofono_voicecall *vc, 
ofono_voicecall_cb_t cb,
for (l = vd->calls; l; l = l->next) {
call = l->data;
 
-   if (call->status == CALL_STATUS_INCOMING) {
+   if (call->status == OFONO_CALL_STATUS_INCOMING) {
/*
 * Need to use this request so that declined
 * calls in this state, are properly forwarded
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 03/12] hfpmodem: Use new voicecall enums

---
 drivers/hfpmodem/voicecall.c | 92 +++-
 1 file changed, 48 insertions(+), 44 deletions(-)

diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index 6ffe9d5..1ab2aa2 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -84,13 +84,14 @@ static GSList *find_dialing(GSList *calls)
 {
GSList *c;
 
-   c = g_slist_find_custom(calls, GINT_TO_POINTER(CALL_STATUS_DIALING),
+   c = g_slist_find_custom(calls,
+   GINT_TO_POINTER(OFONO_CALL_STATUS_DIALING),
at_util_call_compare_by_status);
 
if (c == NULL)
c = g_slist_find_custom(calls,
-   GINT_TO_POINTER(CALL_STATUS_ALERTING),
-   at_util_call_compare_by_status);
+   GINT_TO_POINTER(OFONO_CALL_STATUS_ALERTING),
+   at_util_call_compare_by_status);
 
return c;
 }
@@ -104,7 +105,8 @@ static void voicecall_notify(gpointer value, gpointer user)
 }
 
 static struct ofono_call *create_call(struct ofono_voicecall *vc, int type,
-   int direction, int status,
+   enum ofono_call_direction direction,
+   enum ofono_call_status status,
const char *num, int num_type, int clip)
 {
struct voicecall_data *d = ofono_voicecall_get_data(vc);
@@ -230,10 +232,10 @@ static void clcc_poll_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
nc = n ? n->data : NULL;
oc = o ? o->data : NULL;
 
-   if (nc && (nc->status == CALL_STATUS_ACTIVE))
+   if (nc && (nc->status == OFONO_CALL_STATUS_ACTIVE))
num_active++;
 
-   if (nc && (nc->status == CALL_STATUS_HELD))
+   if (nc && (nc->status == OFONO_CALL_STATUS_HELD))
num_held++;
 
if (oc && (nc == NULL || (nc->id > oc->id))) {
@@ -361,14 +363,15 @@ static void atd_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
for (l = vd->calls; l; l = l->next) {
call = l->data;
 
-   if (call->status != CALL_STATUS_ACTIVE)
+   if (call->status != OFONO_CALL_STATUS_ACTIVE)
continue;
 
-   call->status = CALL_STATUS_HELD;
+   call->status = OFONO_CALL_STATUS_HELD;
ofono_voicecall_notify(vc, call);
}
 
-   call = create_call(vc, 0, 0, CALL_STATUS_DIALING, NULL, type, validity);
+   call = create_call(vc, 0, OFONO_CALL_DIRECTION_MOBILE_ORIGINATED,
+   OFONO_CALL_STATUS_DIALING, NULL, type, validity);
if (call == NULL) {
ofono_error("Unable to allocate call, "
"call tracking will fail!");
@@ -478,10 +481,10 @@ static void hfp_answer(struct ofono_voicecall *vc,
 static void hfp_hangup(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
-   unsigned int affected = (1 << CALL_STATUS_INCOMING) |
-   (1 << CALL_STATUS_DIALING) |
-   (1 << CALL_STATUS_ALERTING) |
-   (1 << CALL_STATUS_ACTIVE);
+   unsigned int affected = (1 << OFONO_CALL_STATUS_INCOMING) |
+   (1 << OFONO_CALL_STATUS_DIALING) |
+   (1 << OFONO_CALL_STATUS_ALERTING) |
+   (1 << OFONO_CALL_STATUS_ACTIVE);
 
/* Hangup current active call */
hfp_template("AT+CHUP", vc, generic_cb, affected, cb, data);
@@ -504,7 +507,7 @@ static void hfp_release_all_held(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
-   unsigned int held_status = 1 << CALL_STATUS_HELD;
+   unsigned int held_status = 1 << OFONO_CALL_STATUS_HELD;
 
if (vd->ag_mpty_features & HFP_AG_CHLD_0) {
hfp_template("AT+CHLD=0", vc, generic_cb, held_status,
@@ -519,7 +522,7 @@ static void hfp_set_udub(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
-   unsigned int incoming_or_waiting = 1 << CALL_STATUS_WAITING;
+   unsigned int incoming_or_waiting = 1 << OFONO_CALL_STATUS_WAITING;
 
if (vd->ag_mpty_features & HFP_AG_CHLD_0) {
hfp_template("AT+CHLD=0", vc, generic_cb, incoming_or_waiting,
@@ -759,7 +762,7 @@ static void ccwa_notify(GAtResult *result, gpointer 
user_data)
 
/* CCWA can repeat, ignore if we already have an waiting call */
if (g_slist_find_custom(vd->calls,
-

[PATCH 04/12] huaweimodem: Use new voicecall enums

---
 drivers/huaweimodem/voicecall.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/huaweimodem/voicecall.c b/drivers/huaweimodem/voicecall.c
index f55568d..36a16a1 100644
--- a/drivers/huaweimodem/voicecall.c
+++ b/drivers/huaweimodem/voicecall.c
@@ -49,7 +49,8 @@ struct voicecall_data {
 };
 
 static struct ofono_call *create_call(struct ofono_voicecall *vc, int type,
-   int direction, int status,
+   enum ofono_call_direction direction,
+   enum ofono_call_status status,
const char *num, int num_type,
int clip, int id)
 {
@@ -178,7 +179,7 @@ static void cring_notify(GAtResult *result, gpointer 
user_data)
 
/* CRING can repeat, ignore if we already have an incoming call */
if (g_slist_find_custom(vd->calls,
-   GINT_TO_POINTER(CALL_STATUS_INCOMING),
+   GINT_TO_POINTER(OFONO_CALL_STATUS_INCOMING),
at_util_call_compare_by_status))
return;
 
@@ -200,7 +201,8 @@ static void cring_notify(GAtResult *result, gpointer 
user_data)
id = ofono_voicecall_get_next_callid(vc);
 
/* Generate an incoming call */
-   create_call(vc, type, 1, CALL_STATUS_INCOMING, NULL, 128, 2, id);
+   create_call(vc, type, OFONO_CALL_DIRECTION_MOBILE_TERMINATED,
+   OFONO_CALL_STATUS_INCOMING, NULL, 128, 2, id);
 
/* Assume the CLIP always arrives, and we signal the call there */
DBG("%d", type);
@@ -217,7 +219,7 @@ static void clip_notify(GAtResult *result, gpointer 
user_data)
struct ofono_call *call;
 
l = g_slist_find_custom(vd->calls,
-   GINT_TO_POINTER(CALL_STATUS_INCOMING),
+   GINT_TO_POINTER(OFONO_CALL_STATUS_INCOMING),
at_util_call_compare_by_status);
if (l == NULL) {
ofono_error("CLIP for unknown call");
@@ -316,8 +318,9 @@ static void orig_notify(GAtResult *result, gpointer 
user_data)
 
ofono_info("Call origin: id %d type %d", call_id, call_type);
 
-   call = create_call(vc, call_type, 0, CALL_STATUS_DIALING, NULL, 128, 2,
-   call_id);
+   call = create_call(vc, call_type,
+   OFONO_CALL_DIRECTION_MOBILE_ORIGINATED,
+   OFONO_CALL_STATUS_DIALING, NULL, 128, 2, call_id);
if (call == NULL) {
ofono_error("Unable to malloc, call tracking will fail!");
return;
@@ -355,7 +358,7 @@ static void conf_notify(GAtResult *result, gpointer 
user_data)
 
/* Set call to alerting */
call = l->data;
-   call->status = CALL_STATUS_ALERTING;
+   call->status = OFONO_CALL_STATUS_ALERTING;
 
if (call->type == 0)
ofono_voicecall_notify(vc, call);
@@ -392,7 +395,7 @@ static void conn_notify(GAtResult *result, gpointer 
user_data)
 
/* Set call to active */
call = l->data;
-   call->status = CALL_STATUS_ACTIVE;
+   call->status = OFONO_CALL_STATUS_ACTIVE;
 
if (call->type == 0)
ofono_voicecall_notify(vc, call);
-- 
1.9.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 07/12] stemodem: Use new voicecall enums

---
 drivers/stemodem/voicecall.c | 77 +++-
 1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/drivers/stemodem/voicecall.c b/drivers/stemodem/voicecall.c
index 356ab7c..eb4431c 100644
--- a/drivers/stemodem/voicecall.c
+++ b/drivers/stemodem/voicecall.c
@@ -82,28 +82,29 @@ static int call_status_ste_to_ofono(enum call_status_ste 
status)
switch (status) {
case STE_CALL_STATUS_IDLE:
case STE_CALL_STATUS_RELEASED:
-   return CALL_STATUS_DISCONNECTED;
+   return OFONO_CALL_STATUS_DISCONNECTED;
case STE_CALL_STATUS_CALLING:
-   return CALL_STATUS_DIALING;
+   return OFONO_CALL_STATUS_DIALING;
case STE_CALL_STATUS_CONNECTING:
-   return CALL_STATUS_ALERTING;
+   return OFONO_CALL_STATUS_ALERTING;
case STE_CALL_STATUS_ACTIVE:
-   return CALL_STATUS_ACTIVE;
+   return OFONO_CALL_STATUS_ACTIVE;
case STE_CALL_STATUS_HOLD:
-   return CALL_STATUS_HELD;
+   return OFONO_CALL_STATUS_HELD;
case STE_CALL_STATUS_WAITING:
-   return CALL_STATUS_WAITING;
+   return OFONO_CALL_STATUS_WAITING;
case STE_CALL_STATUS_ALERTING:
-   return CALL_STATUS_INCOMING;
+   return OFONO_CALL_STATUS_INCOMING;
case STE_CALL_STATUS_BUSY:
-   return CALL_STATUS_DISCONNECTED;
+   return OFONO_CALL_STATUS_DISCONNECTED;
}
 
-   return CALL_STATUS_DISCONNECTED;
+   return OFONO_CALL_STATUS_DISCONNECTED;
 }
 
 static struct ofono_call *create_call(struct ofono_voicecall *vc, int type,
-   int direction, int status,
+   enum ofono_call_direction direction,
+   enum ofono_call_status status,
const char *num, int num_type, int clip)
 {
struct voicecall_data *d = ofono_voicecall_get_data(vc);
@@ -120,7 +121,7 @@ static struct ofono_call *create_call(struct 
ofono_voicecall *vc, int type,
call->direction = direction;
call->status = status;
 
-   if (clip != CLIP_VALIDITY_NOT_AVAILABLE) {
+   if (clip != OFONO_CLIP_VALIDITY_NOT_AVAILABLE) {
strncpy(call->phone_number.number, num,
OFONO_MAX_PHONE_NUMBER_LENGTH);
call->phone_number.type = num_type;
@@ -255,10 +256,10 @@ static void ste_hangup(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
unsigned int active_dial_alert_or_incoming =
-   (1 << CALL_STATUS_ACTIVE) |
-   (1 << CALL_STATUS_DIALING) |
-   (1 << CALL_STATUS_ALERTING) |
-   (1 << CALL_STATUS_INCOMING);
+   (1 << OFONO_CALL_STATUS_ACTIVE) |
+   (1 << OFONO_CALL_STATUS_DIALING) |
+   (1 << OFONO_CALL_STATUS_ALERTING) |
+   (1 << OFONO_CALL_STATUS_INCOMING);
 
ste_template("AT+CHUP", vc, ste_generic_cb,
active_dial_alert_or_incoming, cb, data);
@@ -273,7 +274,7 @@ static void ste_hold_all_active(struct ofono_voicecall *vc,
 static void ste_release_all_held(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
-   unsigned int held = 1 << CALL_STATUS_HELD;
+   unsigned int held = 1 << OFONO_CALL_STATUS_HELD;
 
ste_template("AT+CHLD=0", vc, ste_generic_cb, held, cb, data);
 }
@@ -282,7 +283,8 @@ static void ste_set_udub(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
unsigned int incoming_or_waiting =
-   (1 << CALL_STATUS_INCOMING) | (1 << 
CALL_STATUS_WAITING);
+   (1 << OFONO_CALL_STATUS_INCOMING) |
+   (1 << OFONO_CALL_STATUS_WAITING);
 
ste_template("AT+CHLD=0", vc, ste_generic_cb, incoming_or_waiting,
cb, data);
@@ -291,7 +293,7 @@ static void ste_set_udub(struct ofono_voicecall *vc,
 static void ste_release_all_active(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
 {
-   unsigned int active = 1 << CALL_STATUS_ACTIVE;
+   unsigned int active = 1 << OFONO_CALL_STATUS_ACTIVE;
 
ste_template("AT+CHLD=1", vc, ste_generic_cb, active, cb, data);
 }
@@ -359,7 +361,8 @@ static void ste_deflect(struct ofono_voicecall *vc,
 {
char buf[128];
unsigned int incoming_or_waiting =
-   (1 << CALL_STATUS_INCOMING) | (1 << CALL_STATUS_WAITING);
+   (1 << OFONO_CALL_STATUS_INCOMING) |
+   (1 << OFONO_CALL_STATUS_WAITING);
 
snprintf(buf, sizeof(buf), "AT+CTFR=\"%s\",%d", ph->number, ph->type);
ste_template(buf, vc,

[PATCH 05/12] ifxmodem: Use new voicecall enums