[PATCH] doc: Add modem Type property

[PATCH] doc: Add modem Type property

[Dara Spieker-Doyle]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Add support for providing the type of the attached modem device
including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
---
 doc/modem-api.txt |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/doc/modem-api.txt b/doc/modem-api.txt
index 45043b0..fe806c8 100644
--- a/doc/modem-api.txt
+++ b/doc/modem-api.txt
@@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
 
 			This is usually obtained by using the +CGSN AT command.
 
+		string Type [readonly, optional, experimental]
+
+			String representing the type of the modem device.
+
+			The possible values are:
+				"gsm" 	Modem supports one or more of the 3GPP
+					family of technologies including GSM,
+					EDGE, UMTS, HSPA, LTE.
+				"cdma"  Modem supports one or more of the 3GPP2
+					family of technologies including CDMA 1x,
+					EVDO.
+				"hfp"	Bluetooth hands-free profile (HFP) modem
+
 		array{string} Features [readonly]
 
 			List of currently enabled features. It uses simple
-- 
1.7.0.4

Re: [PATCH] doc: Add modem Type property

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Hi Dara,

On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote:
> Add support for providing the type of the attached modem device
> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
> ---
>  doc/modem-api.txt |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
> index 45043b0..fe806c8 100644
> --- a/doc/modem-api.txt
> +++ b/doc/modem-api.txt
> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>  
>  			This is usually obtained by using the +CGSN AT command.
>  
> +		string Type [readonly, optional, experimental]
> +
> +			String representing the type of the modem device.
> +
> +			The possible values are:
> +				"gsm" 	Modem supports one or more of the 3GPP
> +					family of technologies including GSM,
> +					EDGE, UMTS, HSPA, LTE.
> +				"cdma"  Modem supports one or more of the 3GPP2
> +					family of technologies including CDMA 1x,
> +					EVDO.
> +				"hfp"	Bluetooth hands-free profile (HFP) modem
> +

So one pointed question:

How are we planning to support dual-mode devices with this property?  I
believe during the CDMA workshop we decided that the clients should
simply look at the set of interfaces, not a semi-static property...

Regards,
-Denis

Re: [PATCH] doc: Add modem Type property

[Gustavo F. Padovan]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

Hi Denis,

* Denis Kenzior <denkenz@gmail.com> [2011-01-21 14:15:46 -0600]:

> Hi Dara,
> 
> On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote:
> > Add support for providing the type of the attached modem device
> > including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
> > ---
> >  doc/modem-api.txt |   13 +++++++++++++
> >  1 files changed, 13 insertions(+), 0 deletions(-)
> > 
> > diff --git a/doc/modem-api.txt b/doc/modem-api.txt
> > index 45043b0..fe806c8 100644
> > --- a/doc/modem-api.txt
> > +++ b/doc/modem-api.txt
> > @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
> >  
> >  			This is usually obtained by using the +CGSN AT command.
> >  
> > +		string Type [readonly, optional, experimental]
> > +
> > +			String representing the type of the modem device.
> > +
> > +			The possible values are:
> > +				"gsm" 	Modem supports one or more of the 3GPP
> > +					family of technologies including GSM,
> > +					EDGE, UMTS, HSPA, LTE.
> > +				"cdma"  Modem supports one or more of the 3GPP2
> > +					family of technologies including CDMA 1x,
> > +					EVDO.
> > +				"hfp"	Bluetooth hands-free profile (HFP) modem
> > +
> 
> So one pointed question:
> 
> How are we planning to support dual-mode devices with this property?  I
> believe during the CDMA workshop we decided that the clients should
> simply look at the set of interfaces, not a semi-static property...

We can have a value that is "gsm & cdma". This fits for now, but won't scale. 
And this list won't increase in the near future I think.

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: [PATCH] doc: Add modem Type property

[Dara Spieker-Doyle]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi Gustavo and Denis

On 01/21/2011 12:25 PM, ext Gustavo F. Padovan wrote:
> Hi Denis,
>
> * Denis Kenzior<denkenz@gmail.com>  [2011-01-21 14:15:46 -0600]:
>
>> Hi Dara,
>>
>> On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote:
>>> Add support for providing the type of the attached modem device
>>> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
>>> ---
>>>   doc/modem-api.txt |   13 +++++++++++++
>>>   1 files changed, 13 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
>>> index 45043b0..fe806c8 100644
>>> --- a/doc/modem-api.txt
>>> +++ b/doc/modem-api.txt
>>> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>>>
>>>   			This is usually obtained by using the +CGSN AT command.
>>>
>>> +		string Type [readonly, optional, experimental]
>>> +
>>> +			String representing the type of the modem device.
>>> +
>>> +			The possible values are:
>>> +				"gsm" 	Modem supports one or more of the 3GPP
>>> +					family of technologies including GSM,
>>> +					EDGE, UMTS, HSPA, LTE.
>>> +				"cdma"  Modem supports one or more of the 3GPP2
>>> +					family of technologies including CDMA 1x,
>>> +					EVDO.
>>> +				"hfp"	Bluetooth hands-free profile (HFP) modem
>>> +
>>
>> So one pointed question:
>>
>> How are we planning to support dual-mode devices with this property?  I
>> believe during the CDMA workshop we decided that the clients should
>> simply look at the set of interfaces, not a semi-static property...
>
> We can have a value that is "gsm&  cdma". This fits for now, but won't scale.
> And this list won't increase in the near future I think.
>
This is along the lines of my thoughts for future support of a 
multi-mode device- but I left it out for now as a value as it's future work.
Denis - Lei's about to pop in and answer your questions as he was 
actually at the workshop! :)

Cheers
Dara

Re: [PATCH] doc: Add modem Type property

[Lei Yu]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Hi Denis,

On 01/21/2011 12:15 PM, ext Denis Kenzior wrote:
> Hi Dara,
>
> On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote:
>> Add support for providing the type of the attached modem device
>> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
>> ---
>>   doc/modem-api.txt |   13 +++++++++++++
>>   1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
>> index 45043b0..fe806c8 100644
>> --- a/doc/modem-api.txt
>> +++ b/doc/modem-api.txt
>> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>>
>>   			This is usually obtained by using the +CGSN AT command.
>>
>> +		string Type [readonly, optional, experimental]
>> +
>> +			String representing the type of the modem device.
>> +
>> +			The possible values are:
>> +				"gsm" 	Modem supports one or more of the 3GPP
>> +					family of technologies including GSM,
>> +					EDGE, UMTS, HSPA, LTE.
>> +				"cdma"  Modem supports one or more of the 3GPP2
>> +					family of technologies including CDMA 1x,
>> +					EVDO.
>> +				"hfp"	Bluetooth hands-free profile (HFP) modem
>> +
>
> So one pointed question:
>
> How are we planning to support dual-mode devices with this property?  I
> believe during the CDMA workshop we decided that the clients should
> simply look at the set of interfaces, not a semi-static property...

We understand that the decision during the CDMA workshop but as we 
explained one use case in the cover letter 
(http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for 
this RFC, there will be cases where atom's D-Bus I/F is not suitable (or 
as a reliable way) for telling what is current mode (CDMA or GSM). E.g., 
in the case of retrieving serial number from modem. Currently both CDMA 
and GSM shares the same I/F (ofono.org.modem) rather than having 
separate (ofono.org.cdma.modem). And, further if no other atom has been 
instantiated, then, there will be no other way to tell which mode (CDMA 
or GSM) the modem is. And, further for displaying serial number, upper 
layer will need to know it is CDMA or GSM. In case of CDMA, the serial 
number is MEID and GSM it is IMEI. As explained in cover letter, we 
anticipate more cases like this.

>
> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards
Lei

Re: [PATCH] doc: Add modem Type property

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Hi Lei,

>>> +        string Type [readonly, optional, experimental]
>>> +
>>> +            String representing the type of the modem device.
>>> +
>>> +            The possible values are:
>>> +                "gsm"     Modem supports one or more of the 3GPP
>>> +                    family of technologies including GSM,
>>> +                    EDGE, UMTS, HSPA, LTE.
>>> +                "cdma"  Modem supports one or more of the 3GPP2
>>> +                    family of technologies including CDMA 1x,
>>> +                    EVDO.
>>> +                "hfp"    Bluetooth hands-free profile (HFP) modem
>>> +
>>
>> So one pointed question:
>>
>> How are we planning to support dual-mode devices with this property?  I
>> believe during the CDMA workshop we decided that the clients should
>> simply look at the set of interfaces, not a semi-static property...
> 
> We understand that the decision during the CDMA workshop but as we
> explained one use case in the cover letter
> (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for
> this RFC, there will be cases where atom's D-Bus I/F is not suitable (or
> as a reliable way) for telling what is current mode (CDMA or GSM). E.g.,
> in the case of retrieving serial number from modem. Currently both CDMA
> and GSM shares the same I/F (ofono.org.modem) rather than having
> separate (ofono.org.cdma.modem). And, further if no other atom has been
> instantiated, then, there will be no other way to tell which mode (CDMA
> or GSM) the modem is. And, further for displaying serial number, upper
> layer will need to know it is CDMA or GSM. In case of CDMA, the serial
> number is MEID and GSM it is IMEI. As explained in cover letter, we
> anticipate more cases like this.

So let us say I have a dual-mode modem.  Are there now two serial
numbers? One for MEID and one for IMEI?  Are there now two
Manufacturers? Two Revisions?

Regards,
-Denis

Re: [PATCH] doc: Add modem Type property

[Lei Yu]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

Hi Denis,

On 01/21/2011 12:15 PM, ext Denis Kenzior wrote:
> Hi Dara,
>
> On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote:
>> Add support for providing the type of the attached modem device
>> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
>> ---
>>   doc/modem-api.txt |   13 +++++++++++++
>>   1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
>> index 45043b0..fe806c8 100644
>> --- a/doc/modem-api.txt
>> +++ b/doc/modem-api.txt
>> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>>
>>   			This is usually obtained by using the +CGSN AT command.
>>
>> +		string Type [readonly, optional, experimental]
>> +
>> +			String representing the type of the modem device.
>> +
>> +			The possible values are:
>> +				"gsm" 	Modem supports one or more of the 3GPP
>> +					family of technologies including GSM,
>> +					EDGE, UMTS, HSPA, LTE.
>> +				"cdma"  Modem supports one or more of the 3GPP2
>> +					family of technologies including CDMA 1x,
>> +					EVDO.
>> +				"hfp"	Bluetooth hands-free profile (HFP) modem
>> +
>
> So one pointed question:
>
> How are we planning to support dual-mode devices with this property?  I
> believe during the CDMA workshop we decided that the clients should
> simply look at the set of interfaces, not a semi-static property...

Also, it is my understanding that the reason we create org.ofono.cdma 
interfaces during CDMA workshop are to make sure CDMA interfaces and 
logics do not "pollute" GSM interfaces and logics which are very 
different anyway. We have not ruled out the case where there may be 
shared interfaces as we see a need. Currently, org.ofono.modem is this 
case. Unless we would go ahead creating org.ofono.cdma.modem, we 
discussed that option internally but feel that is less preferable than 
the "Type" property we proposed here.

>
> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
-Lei

Re: [PATCH] doc: Add modem Type property

[Lei Yu]

[-- Attachment #1: Type: text/plain, Size: 2894 bytes --]

Hi Denis,

On 01/21/2011 01:04 PM, ext Denis Kenzior wrote:
> Hi Lei,
>
>>>> +        string Type [readonly, optional, experimental]
>>>> +
>>>> +            String representing the type of the modem device.
>>>> +
>>>> +            The possible values are:
>>>> +                "gsm"     Modem supports one or more of the 3GPP
>>>> +                    family of technologies including GSM,
>>>> +                    EDGE, UMTS, HSPA, LTE.
>>>> +                "cdma"  Modem supports one or more of the 3GPP2
>>>> +                    family of technologies including CDMA 1x,
>>>> +                    EVDO.
>>>> +                "hfp"    Bluetooth hands-free profile (HFP) modem
>>>> +
>>>
>>> So one pointed question:
>>>
>>> How are we planning to support dual-mode devices with this property?  I
>>> believe during the CDMA workshop we decided that the clients should
>>> simply look at the set of interfaces, not a semi-static property...
>>
>> We understand that the decision during the CDMA workshop but as we
>> explained one use case in the cover letter
>> (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for
>> this RFC, there will be cases where atom's D-Bus I/F is not suitable (or
>> as a reliable way) for telling what is current mode (CDMA or GSM). E.g.,
>> in the case of retrieving serial number from modem. Currently both CDMA
>> and GSM shares the same I/F (ofono.org.modem) rather than having
>> separate (ofono.org.cdma.modem). And, further if no other atom has been
>> instantiated, then, there will be no other way to tell which mode (CDMA
>> or GSM) the modem is. And, further for displaying serial number, upper
>> layer will need to know it is CDMA or GSM. In case of CDMA, the serial
>> number is MEID and GSM it is IMEI. As explained in cover letter, we
>> anticipate more cases like this.
>
> So let us say I have a dual-mode modem.  Are there now two serial
> numbers? One for MEID and one for IMEI?  Are there now two
> Manufacturers? Two Revisions?

Try to clarify what you try to ask first. Let's start with the dual-mode 
case where the modem is integrated modem (one piece of HW) where it 
supports both CDMA and GSM. Then, there is case where the phone actually 
has both MEID and IMEI. And, these two numbers are actually the same 
(note, per IMEI's assignment there is a pre-arranged segment for this 
kind of world phone). And, in which case, one manufacture, one revision. 
Per the other thread, in which case the "Type" will be something like 
"gsm_cdma".
Of course, there can be case where two physical modems are in the device 
in which case there will be two separate serial numbers and two 
manufacturers and revisions. I am assuming you are not asking for this case.

Again, the problem we try to solve is single mode case.

>
> Regards,
> -Denis

Regards,
- Lei

Re: [PATCH] doc: Add modem Type property

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

Hi Lei,

On 01/21/2011 03:48 PM, Lei Yu wrote:
> Hi Denis,
> 
> On 01/21/2011 01:04 PM, ext Denis Kenzior wrote:
>> Hi Lei,
>>
>>>>> +        string Type [readonly, optional, experimental]
>>>>> +
>>>>> +            String representing the type of the modem device.
>>>>> +
>>>>> +            The possible values are:
>>>>> +                "gsm"     Modem supports one or more of the 3GPP
>>>>> +                    family of technologies including GSM,
>>>>> +                    EDGE, UMTS, HSPA, LTE.
>>>>> +                "cdma"  Modem supports one or more of the 3GPP2
>>>>> +                    family of technologies including CDMA 1x,
>>>>> +                    EVDO.
>>>>> +                "hfp"    Bluetooth hands-free profile (HFP) modem
>>>>> +
>>>>
>>>> So one pointed question:
>>>>
>>>> How are we planning to support dual-mode devices with this property?  I
>>>> believe during the CDMA workshop we decided that the clients should
>>>> simply look at the set of interfaces, not a semi-static property...
>>>
>>> We understand that the decision during the CDMA workshop but as we
>>> explained one use case in the cover letter
>>> (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for
>>> this RFC, there will be cases where atom's D-Bus I/F is not suitable (or
>>> as a reliable way) for telling what is current mode (CDMA or GSM). E.g.,
>>> in the case of retrieving serial number from modem. Currently both CDMA
>>> and GSM shares the same I/F (ofono.org.modem) rather than having
>>> separate (ofono.org.cdma.modem). And, further if no other atom has been
>>> instantiated, then, there will be no other way to tell which mode (CDMA
>>> or GSM) the modem is. And, further for displaying serial number, upper
>>> layer will need to know it is CDMA or GSM. In case of CDMA, the serial
>>> number is MEID and GSM it is IMEI. As explained in cover letter, we
>>> anticipate more cases like this.
>>
>> So let us say I have a dual-mode modem.  Are there now two serial
>> numbers? One for MEID and one for IMEI?  Are there now two
>> Manufacturers? Two Revisions?
> 
> Try to clarify what you try to ask first. Let's start with the dual-mode
> case where the modem is integrated modem (one piece of HW) where it
> supports both CDMA and GSM. Then, there is case where the phone actually
> has both MEID and IMEI. And, these two numbers are actually the same
> (note, per IMEI's assignment there is a pre-arranged segment for this
> kind of world phone). And, in which case, one manufacture, one revision.
> Per the other thread, in which case the "Type" will be something like
> "gsm_cdma".

So how does the modem type help you here if you have 'gsm_cdma'?  Is the
modem giving you a MEID? An IMEI?  I'm not convinced the Type helps you
in any way.  It might help you for HFP, but certainly not the dual mode
case.

> Of course, there can be case where two physical modems are in the device
> in which case there will be two separate serial numbers and two
> manufacturers and revisions. I am assuming you are not asking for this
> case.

Yes, I'm ignoring the true dual-mode dual-radio case right now.

Regards,
-Denis

Re: [PATCH] doc: Add modem Type property

[Lei Yu]

[-- Attachment #1: Type: text/plain, Size: 3945 bytes --]

Hi Denis,

On 01/21/2011 02:04 PM, ext Denis Kenzior wrote:
> Hi Lei,
>
> On 01/21/2011 03:48 PM, Lei Yu wrote:
>> Hi Denis,
>>
>> On 01/21/2011 01:04 PM, ext Denis Kenzior wrote:
>>> Hi Lei,
>>>
>>>>>> +        string Type [readonly, optional, experimental]
>>>>>> +
>>>>>> +            String representing the type of the modem device.
>>>>>> +
>>>>>> +            The possible values are:
>>>>>> +                "gsm"     Modem supports one or more of the 3GPP
>>>>>> +                    family of technologies including GSM,
>>>>>> +                    EDGE, UMTS, HSPA, LTE.
>>>>>> +                "cdma"  Modem supports one or more of the 3GPP2
>>>>>> +                    family of technologies including CDMA 1x,
>>>>>> +                    EVDO.
>>>>>> +                "hfp"    Bluetooth hands-free profile (HFP) modem
>>>>>> +
>>>>>
>>>>> So one pointed question:
>>>>>
>>>>> How are we planning to support dual-mode devices with this property?  I
>>>>> believe during the CDMA workshop we decided that the clients should
>>>>> simply look at the set of interfaces, not a semi-static property...
>>>>
>>>> We understand that the decision during the CDMA workshop but as we
>>>> explained one use case in the cover letter
>>>> (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for
>>>> this RFC, there will be cases where atom's D-Bus I/F is not suitable (or
>>>> as a reliable way) for telling what is current mode (CDMA or GSM). E.g.,
>>>> in the case of retrieving serial number from modem. Currently both CDMA
>>>> and GSM shares the same I/F (ofono.org.modem) rather than having
>>>> separate (ofono.org.cdma.modem). And, further if no other atom has been
>>>> instantiated, then, there will be no other way to tell which mode (CDMA
>>>> or GSM) the modem is. And, further for displaying serial number, upper
>>>> layer will need to know it is CDMA or GSM. In case of CDMA, the serial
>>>> number is MEID and GSM it is IMEI. As explained in cover letter, we
>>>> anticipate more cases like this.
>>>
>>> So let us say I have a dual-mode modem.  Are there now two serial
>>> numbers? One for MEID and one for IMEI?  Are there now two
>>> Manufacturers? Two Revisions?
>>
>> Try to clarify what you try to ask first. Let's start with the dual-mode
>> case where the modem is integrated modem (one piece of HW) where it
>> supports both CDMA and GSM. Then, there is case where the phone actually
>> has both MEID and IMEI. And, these two numbers are actually the same
>> (note, per IMEI's assignment there is a pre-arranged segment for this
>> kind of world phone). And, in which case, one manufacture, one revision.
>> Per the other thread, in which case the "Type" will be something like
>> "gsm_cdma".
>
> So how does the modem type help you here if you have 'gsm_cdma'?  Is the
> modem giving you a MEID? An IMEI?  I'm not convinced the Type helps you
> in any way.  It might help you for HFP, but certainly not the dual mode
> case.
>

First, our original use case is really for a single mode case, not dual 
mode. Please see our cover letter in our original RFC. Please do let us 
know if you agree or disagree whether there is a problem needing to be 
solved for single mode case.
Second, in case of the example I gave above, modem will provide one 
serial number which is both MEID and IMEI since they are identical. In 
which case based on "Type" setting to "cdma_gsm", it will be upper 
layer's choice to do the processing. E.g., upper layer can do something 
like: MEID/IMEI: xxxxxxx.

>> Of course, there can be case where two physical modems are in the device
>> in which case there will be two separate serial numbers and two
>> manufacturers and revisions. I am assuming you are not asking for this
>> case.
>
> Yes, I'm ignoring the true dual-mode dual-radio case right now.
>
> Regards,
> -Denis

Regards,
-Lei

Re: [PATCH] doc: Add modem Type property

[Gustavo F. Padovan]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

Hi Dara,

* Dara Spieker-Doyle <dara.spieker-doyle@nokia.com> [2011-01-20 14:48:57 -0800]:

> Add support for providing the type of the attached modem device
> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
> ---
>  doc/modem-api.txt |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
> index 45043b0..fe806c8 100644
> --- a/doc/modem-api.txt
> +++ b/doc/modem-api.txt
> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>  
>  			This is usually obtained by using the +CGSN AT command.
>  
> +		string Type [readonly, optional, experimental]
> +
> +			String representing the type of the modem device.
> +
> +			The possible values are:
> +				"gsm" 	Modem supports one or more of the 3GPP
> +					family of technologies including GSM,
> +					EDGE, UMTS, HSPA, LTE.
> +				"cdma"  Modem supports one or more of the 3GPP2
> +					family of technologies including CDMA 1x,
> +					EVDO.
> +				"hfp"	Bluetooth hands-free profile (HFP) modem

I think that this can also help with ConnMan, currently it enables all modems,
even the hfp one, which is wrong.

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: [PATCH] doc: Add modem Type property

[Dara Spieker-Doyle]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi Gustavo

On 02/03/2011 11:25 AM, ext Gustavo F. Padovan wrote:
> Hi Dara,
>
> * Dara Spieker-Doyle<dara.spieker-doyle@nokia.com>  [2011-01-20 14:48:57 -0800]:
>
>> Add support for providing the type of the attached modem device
>> including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP.
>> ---
>>   doc/modem-api.txt |   13 +++++++++++++
>>   1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/modem-api.txt b/doc/modem-api.txt
>> index 45043b0..fe806c8 100644
>> --- a/doc/modem-api.txt
>> +++ b/doc/modem-api.txt
>> @@ -82,6 +82,19 @@ Properties	boolean Powered [readwrite]
>>
>>   			This is usually obtained by using the +CGSN AT command.
>>
>> +		string Type [readonly, optional, experimental]
>> +
>> +			String representing the type of the modem device.
>> +
>> +			The possible values are:
>> +				"gsm" 	Modem supports one or more of the 3GPP
>> +					family of technologies including GSM,
>> +					EDGE, UMTS, HSPA, LTE.
>> +				"cdma"  Modem supports one or more of the 3GPP2
>> +					family of technologies including CDMA 1x,
>> +					EVDO.
>> +				"hfp"	Bluetooth hands-free profile (HFP) modem
>
> I think that this can also help with ConnMan, currently it enables all modems,
> even the hfp one, which is wrong.
>

Yes, this is what we suspect as well and had a discussion about it in 
the IRC recently. We are currently preparing a CDMA ConnMan patch to 
establish if it will further justify supporting this interface from a 
CDMA perspective.

Cheers
Dara