Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi, 2011/2/1 Aki Niemi : > I'm starting to think me just saying this out loud is not concrete > enough, so I guess one way forward here could be for me to go ahead and > adapt e.g. the netreg driver to work with N900 and later ISI modems. The > netreg driver would make a good example, as it is one of those where the > resource ID changes post N900, and the messages do vary based on it. I went ahead and pushed some patches refactoring the isimodem netreg driver to work with both the old modem API as well as the new wgmodem 2.5 version. Please take a look if it works for you. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Andreas,
2011/2/3 Andreas WESTIN :
>> I don't see what that has to do with the device supporting the "PC
>> suite" USB profile, which allows modem access using cdc_phonet.
>
> Currently our platform does not support this.
Well, I know of platforms that do, and have different versions of ISI modems.
>> That is exactly what I meant. This version allows building quirks inside
>> the drivers. An example in pseudo-code:
>>
>> if GIsiVersion.major == 15 and GIsiVersion.minor>= 3:
>> send( { FOO, value, filler, filler}, callback1 )
>> else:
>> send( { FOO, value }, callback2 )
>>
>
> Yes, we use a similar solution in gisi, but Rémi pointed out that it would
> be a maintenance problem once there are more versions to support and I tend
> to agree. A solution could be to use a lookup function, but this function
> would need to return something to compare with, an enum perhaps.
> Also are you certain that e.g major == 15 and minor == 25 is still the same
> ISI version, if not then the lookup function could become messy.
The PNS_SUBSCRIBED_RESOURCES_EXTEND_IND is a bit of a special case, as
it requires quirking inside GIsiModem. But see my other response in
that thread.
Cheers,
Aki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Aki,
On 2011-02-02 14:03, Aki Niemi wrote:
I don't see what that has to do with the device supporting the "PC
suite" USB profile, which allows modem access using cdc_phonet.
Currently our platform does not support this.
That is exactly what I meant. This version allows building quirks inside
the drivers. An example in pseudo-code:
if GIsiVersion.major == 15 and GIsiVersion.minor>= 3:
send( { FOO, value, filler, filler}, callback1 )
else:
send( { FOO, value }, callback2 )
Yes, we use a similar solution in gisi, but Rémi pointed out that it
would be a maintenance problem once there are more versions to support
and I tend to agree. A solution could be to use a lookup function, but
this function would need to return something to compare with, an enum
perhaps.
Also are you certain that e.g major == 15 and minor == 25 is still the
same ISI version, if not then the lookup function could become messy.
Regards
Andreas
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
On Wed, 2011-02-02 at 10:03 +0100, ext Andreas WESTIN wrote:
> On 2011-02-01 20:32, Aki Niemi wrote:
> > Like I replied earlier, I don't see the need for this. Also, it will not
> > work well with the isiusb plugin, which has the potential to work with
> > any ISI modem. I'm not willing to break that potential until we just
> > absolutely have to.
>
> U8500 uses shrm driver and will not be recognized via isiusb.
I don't see what that has to do with the device supporting the "PC
suite" USB profile, which allows modem access using cdc_phonet.
> > So, my stance holds: we quirk based on resource ID and based on the
> > server's ISI version.
>
> From the information we have regarding ISI version from each server is
> that it is not consistent, meaning the value you get is not really the
> ISI version but the version of the server.
That is exactly what I meant. This version allows building quirks inside
the drivers. An example in pseudo-code:
if GIsiVersion.major == 15 and GIsiVersion.minor >= 3:
send( { FOO, value, filler, filler}, callback1 )
else:
send( { FOO, value }, callback2 )
Cheers,
Aki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Aki,
> > > +enum isi_version {
> > > + ISI_20 = 0,
> > > + ISI_25 = 1
> > > +};
> >
> > so what is the final decision here now. ISI doing auto-detection and
> > this gets not exposed to the modem drivers or we do.
>
> Like I replied earlier, I don't see the need for this. Also, it will not
> work well with the isiusb plugin, which has the potential to work with
> any ISI modem. I'm not willing to break that potential until we just
> absolutely have to.
>
> So, my stance holds: we quirk based on resource ID and based on the
> server's ISI version.
good to know. I was just double-checking in case you guys agreed on
something different on a private channel.
> I'm starting to think me just saying this out loud is not concrete
> enough, so I guess one way forward here could be for me to go ahead and
> adapt e.g. the netreg driver to work with N900 and later ISI modems. The
> netreg driver would make a good example, as it is one of those where the
> resource ID changes post N900, and the messages do vary based on it.
I think having an example on how you want this handled would be a good
idea. I don't have time to get myself familiar enough with ISI that I
can do any proper review here. So this is in your hands.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Aki, On 2011-02-01 20:32, Aki Niemi wrote: Like I replied earlier, I don't see the need for this. Also, it will not work well with the isiusb plugin, which has the potential to work with any ISI modem. I'm not willing to break that potential until we just absolutely have to. U8500 uses shrm driver and will not be recognized via isiusb. So, my stance holds: we quirk based on resource ID and based on the server's ISI version. From the information we have regarding ISI version from each server is that it is not consistent, meaning the value you get is not really the ISI version but the version of the server. /Andreas ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Marcel,
On Tue, 2011-02-01 at 16:43 +0100, ext Marcel Holtmann wrote:
> > +enum isi_version {
> > + ISI_20 = 0,
> > + ISI_25 = 1
> > +};
>
> so what is the final decision here now. ISI doing auto-detection and
> this gets not exposed to the modem drivers or we do.
Like I replied earlier, I don't see the need for this. Also, it will not
work well with the isiusb plugin, which has the potential to work with
any ISI modem. I'm not willing to break that potential until we just
absolutely have to.
So, my stance holds: we quirk based on resource ID and based on the
server's ISI version.
I'm starting to think me just saying this out loud is not concrete
enough, so I guess one way forward here could be for me to go ahead and
adapt e.g. the netreg driver to work with N900 and later ISI modems. The
netreg driver would make a good example, as it is one of those where the
resource ID changes post N900, and the messages do vary based on it.
Cheers,
Aki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Marcel,
On 2011-02-01 16:43, Marcel Holtmann wrote:
Hi Jessica,
drivers/isimodem/debug.c | 132
drivers/isimodem/debug.h |9 +++
drivers/isimodem/mtc.h | 38 +
drivers/isimodem/version.h | 26 +
4 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 drivers/isimodem/version.h
+enum isi_version {
+ ISI_20 = 0,
+ ISI_25 = 1
+};
so what is the final decision here now. ISI doing auto-detection and
this gets not exposed to the modem drivers or we do.
Aki, I remember you saying that this is not needed at all.
We need to know which version of ISI we are using in the driver,
messages differ. But we are open to other suggestions.
Marcel, as to your other comments we will correct them and send new patches.
Regards
Andreas
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
Hi Jessica,
> drivers/isimodem/debug.c | 132
>
> drivers/isimodem/debug.h |9 +++
> drivers/isimodem/mtc.h | 38 +
> drivers/isimodem/version.h | 26 +
> 4 files changed, 205 insertions(+), 0 deletions(-)
> create mode 100644 drivers/isimodem/version.h
> +enum isi_version {
> + ISI_20 = 0,
> + ISI_25 = 1
> +};
so what is the final decision here now. ISI doing auto-detection and
this gets not exposed to the modem drivers or we do.
Aki, I remember you saying that this is not needed at all.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH v2 3/3] isimodem: header updates for ISI2.5
---
drivers/isimodem/debug.c | 132
drivers/isimodem/debug.h |9 +++
drivers/isimodem/mtc.h | 38 +
drivers/isimodem/version.h | 26 +
4 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 drivers/isimodem/version.h
diff --git a/drivers/isimodem/debug.c b/drivers/isimodem/debug.c
index 3d667b4..8b5fa16 100644
--- a/drivers/isimodem/debug.c
+++ b/drivers/isimodem/debug.c
@@ -165,6 +165,138 @@ const char *mtc_modem_state_name(enum mtc_modem_state
value)
return "MTC_";
}
+const char *mce_message_id_name(enum mce_message_id value)
+{
+ switch (value) {
+ _(MCE_MODEM_STATE_IND);
+ _(MCE_MODEM_STATE_QUERY_REQ);
+ _(MCE_MODEM_STATE_QUERY_RESP);
+ _(MCE_RF_STATE_REQ);
+ _(MCE_RF_STATE_RESP);
+ _(MCE_RF_STATE_IND);
+ _(MCE_RF_STATE_QUERY_REQ);
+ _(MCE_RF_STATE_QUERY_RESP);
+ _(MCE_POWER_OFF_REQ);
+ _(MCE_POWER_OFF_RESP);
+ }
+ return "MCE_";
+}
+
+const char *mce_modem_state_name(enum mce_modem_state value)
+{
+ switch (value) {
+ _(MCE_NORMAL);
+ _(MCE_LOCAL);
+ _(MCE_SW_RESET);
+ _(MCE_POWER_OFF);
+ }
+ return "MCE_";
+}
+
+const char *mce_status_info(enum mce_status_info value)
+{
+ switch (value) {
+ _(MCE_OK);
+ _(MCE_FAIL);
+ _(MCE_ALREADY_ACTIVE);
+ _(MCE_TRANSITION_ONGOING);
+ }
+ return "MCE_";
+}
+
+const char *mce_rf_state_name(enum mce_rf_state value)
+{
+ switch (value) {
+ _(MCE_RF_OFF);
+ _(MCE_RF_ON);
+ }
+ return "MCE_RF";
+}
+
+const char *uicc_status_name(uint8_t value)
+{
+ switch (value) {
+ /* Request performed successfully */
+ _(UICC_STATUS_OK);
+ /* Error in performing the command */
+ _(UICC_STATUS_FAIL);
+ /* Status is Unknown */
+ _(UICC_STATUS_UNKNOWN);
+ /* Server is not ready */
+ _(UICC_STATUS_NOT_READY);
+ /* Server start up is completed */
+ _(UICC_STATUS_START_UP_COMPLETED);
+ /* Server is shutting down */
+ _(UICC_STATUS_SHUTTING_DOWN);
+ /* Smart card is not ready */
+ _(UICC_STATUS_CARD_NOT_READY);
+ /* Smart card is ready */
+ _(UICC_STATUS_CARD_READY);
+ /* Smart card is disconnected */
+ _(UICC_STATUS_CARD_DISCONNECTED);
+ /* Smart card is not present */
+ _(UICC_STATUS_CARD_NOT_PRESENT);
+ /* Smart card has been rejected */
+ _(UICC_STATUS_CARD_REJECTED);
+ /* Application is active */
+ _(UICC_STATUS_APPL_ACTIVE);
+ /* Application is not active */
+ _(UICC_STATUS_APPL_NOT_ACTIVE);
+ /* PIN verification used */
+ _(UICC_STATUS_PIN_ENABLED);
+ /* PIN verification not used */
+ _(UICC_STATUS_PIN_DISABLED);
+ }
+ return "UICC_STATUS";
+}
+
+const char *uicc_subblock_name(uint8_t value)
+{
+ switch (value) {
+ _(UICC_SB_SHUT_DOWN_CONFIG);
+ _(UICC_SB_CARD_STATUS);
+ _(UICC_SB_CARD_INFO);
+ _(UICC_SB_CARD_REJECT_CAUSE);
+ _(UICC_SB_CLIENT);
+ _(UICC_SB_APPL_DATA_OBJECT);
+ _(UICC_SB_APPLICATION);
+ _(UICC_SB_APPL_INFO);
+ _(UICC_SB_APPL_STATUS);
+ _(UICC_SB_FCP);
+ _(UICC_SB_FCI);
+ _(UICC_SB_CHV);
+ _(UICC_SB_PIN);
+ _(UICC_SB_PIN_REF);
+ _(UICC_SB_PUK);
+ _(UICC_SB_PIN_SUBST);
+ _(UICC_SB_PIN_INFO);
+ _(UICC_SB_APPL_PATH);
+ _(UICC_SB_SESSION);
+ _(UICC_SB_FILE_DATA);
+ _(UICC_SB_APDU);
+ _(UICC_SB_TRANSPARENT_READ);
+ _(UICC_SB_TRANSPARENT_UPDATE);
+ _(UICC_SB_TRANSPARENT);
+ _(UICC_SB_LINEAR_FIXED);
+ _(UICC_SB_CYCLIC);
+ _(UICC_SB_TERMINAL_PROFILE);
+ _(UICC_SB_TERMINAL_RESPONSE);
+ _(UICC_SB_ENVELOPE);
+ _(UICC_SB_POLLING_SET);
+ _(UICC_SB_REFRESH);
+ _(UICC_SB_AID);
+ _(UICC_SB_REFRESH_RESULT);
+ _(UICC_SB_APDU_ACTIONS);
+ _(UICC_SB_OBJECT_ID);
+ _(UICC_SB_STATUS_WORD);
+ _(UICC_SB_APDU_SAP_INFO);
+ _(UICC_SB_ACCESS_MODE);
+ _(UICC_SB_RESP_INFO);
+ _(UICC_SB_APDU_SAP_CONFIG);
+ }
+ return "UICC_";
+}
+
const char *sms_i
