Hi Denis,
On Sun, Apr 29, 2012 at 10:51:17PM -0500, Denis Kenzior wrote:
> Hi Pablo,
>
> >>> + /* AT+CRSM not supported by Q2403. */
> >>> + if (sd->vendor == OFONO_VENDOR_WAVECOM_Q) {
> >>> + unsigned char access[3] = { 0x00, 0x00, 0x00 };
> >>> +
> >>> + CALLBACK_WITH_SUCCESS(cb, 4, 0, 0, access,
> >>> + EF_STATUS_VALID, data);
> >>
> >> Why don't you simply return an error here?
> >
> > Without it, the modem initialization does not complete.
>
> Can you fallback to CSIM?
I don't know what you mean, could you provide more information?
<snip>
> >>> - for (mem = 0; mem < 3; mem++) {
> >>> + /* Wavecom Q replies something like this:
> >>> + *
> >>> + * +CPMS: (("SM","BM","SR"),("SM"))
> >>> + *
> >>> + * It does not provide the way income messages are stored.
> >>> + * 3GPP TS 07.05 allows mem2 and mem3 to be optional.
> >>> + */
> >>
> >> Just how old is this modem and what version of 07.05 are you using?
> >>
> >> For reference, 07.05 version 7.0.1 from July 1999:
> >> "
> >> +CPMS=?
> >> +CPMS: (list of supported <mem1>s),(list of supported <mem2>s),
> >> (list of supported <mem3>s)
> >> "
> >>
> >> So the comment should probably be changed to indicate that this modem is
> >> just broken.
> >>
> >
> > From: "3.2.2 Preferred Message Storage +CPMS" (TS 07.05 July 1999):
> >
> > +CPMS=<mem1>[, <mem2>[,<mem3>]]
>
> That is a set operation, we're doing a support query.
You're right, then it's a broken modem indeed.
> >> Are you sure you can't reuse the same behavior as OFONO_VENDOR_WAVECOM
> >> quirk inside drivers/atmodem/sim.c?
> >
> > Yes, I remember to have tried that. That quirk didn't work for me
> > though.
>
> I think we need to dig a bit deeper as to why, the VENDOR_WAVECOM
> behavior seems to be addressing exactly this case.
I think the other wavecom vendor provides a different reply. I can add
a different quirk to at_cpin_cb instead and see how it goes.
> >> This is probably wrong, I suspect we need to add a generic function to
> >> register (real) serial tty based modems.
> >
> > I should have added some add_wavecom function instead.
> >
> > I used that because I noticed that:
> >
> > add_sim900
> > add_nokiacdma
> > add_tc65
> > ...
> > and so on.
> >
> > look the same. So I guess that it is indeed a good idea to remove
> > redundant code and provide some generic one.
> >
>
> If they are all the same, then adding a generic function is fine.
I'll send you a patch for this.
> <snip>
>
> >>> +OFONO_PLUGIN_DEFINE(wavecom_q, "Wavecom-Q driver", VERSION,
> >>> + OFONO_PLUGIN_PRIORITY_DEFAULT, wavecom_q_init, wavecom_q_exit)
> >>
> >> Is there a way to just re-use the wavecom driver instead of creating a
> >> brand new one?
> >
> > I didn't find any cleaner solution I could like, but if you propose any
> > other solution, I'll make it.
>
> Right now to me it seems like the differences between the -Q version is
> a slightly different set of quirks. Can't we query the model / firmware
> versions and set the quirks accordingly?
Is there any facility that ofono provides to do this? If so, please
point to some existing code.
Thank you.
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
