**** BEGIN LOGGING AT Mon Jan 17 02:59:57 2011
Jan 17 12:32:33 <Jeevaka> denkenz, holtmann: ping
Jan 17 13:53:30 <nbertrand> :q
Jan 17 14:25:11 <Jeevaka> demarchi: ping
Jan 17 14:32:55 <demarchi> Jeevaka: pong
Jan 17 14:34:36 <Jeevaka> regarding the pin retry counter
Jan 17 14:36:00 <Jeevaka> list-modems test script is not updated for the Retries property
Jan 17 14:38:27 <Jeevaka> can i goahead and do this?
Jan 17 14:45:33 <Jeevaka> and also memcmp of the retry counter didn't work due to sizeof issue
Jan 17 15:14:39 <Jeevaka> demarchi: ?
Jan 17 15:24:30 <denkenz> Jeevaka: Don't bother asking, if you see something you want to fix, just send it in
Jan 17 15:26:03 <Jeevaka> ok
Jan 17 15:29:16 <demarchi> Jeevaka: sorry, lunch time
Jan 17 15:29:31 <demarchi> Jeevaka: yeah, please sendo to ML so we can review it
Jan 17 15:30:31 <demarchi> Jeevaka: where's the problem with memcmp?
Jan 17 15:31:20 <Jeevaka> in the core
Jan 17 15:31:30 <demarchi> Jeevaka: it looks right
Jan 17 15:31:41 <demarchi> if (!memcmp(retries, sim->pin_retries, sizeof(retries)))
Jan 17 15:31:42 <demarchi> ?
Jan 17 15:32:19 <Jeevaka> yes, but sizeof(retries) returns 4
Jan 17 15:33:31 <Jeevaka> due to this memcmp always results in match
Jan 17 15:34:11 <demarchi> Jeevaka: what compiler are you using?
Jan 17 15:34:48 <demarchi> Jeevaka: http://codepad.org/yTSf5yRY
Jan 17 15:35:11 <demarchi> this returns 20 for me, i.e. sizeof(int) * 5
Jan 17 15:35:41 <Jeevaka> yes, thats always the case with my config if the param is not functioanl argument
Jan 17 15:37:11 <demarchi> Jeevaka: what config? i didn't understand
Jan 17 15:37:39 <Jeevaka> i mean no difference in compiler
Jan 17 15:37:51 <denkenz> memcmp seems right to me
Jan 17 15:38:22 <Jeevaka> can you print the sizeof retries inside function sim_pin_retries_query_cb
Jan 17 15:38:36 <pessi> http://c-faq.com/aryptr/aryparmsize.html
Jan 17 15:39:04 <Jeevaka> thanks pessi
Jan 17 15:40:52 <Jeevaka> demarchi, denkenz: it would be nice if we can change the callback prototype of sim_pin_retries_query_cb as well
Jan 17 15:41:08 <balrog-k1n> (gdb) print sizeof(int[5])   $2 = 20
Jan 17 15:41:23 <denkenz> works for me on gcc 4.4.3
Jan 17 15:41:34 <denkenz> 16
Jan 17 15:41:44 <denkenz> void foo(int a[4])
Jan 17 15:41:45 <denkenz> {
Jan 17 15:41:45 <denkenz>         printf("%ld\n", sizeof(a));
Jan 17 15:41:45 <denkenz> }
Jan 17 15:42:28 <denkenz> If the compilers are that stupid then I suggest passing in the array and length, similar to other functions that do this
Jan 17 15:42:42 <Jeevaka> http://codepad.org/0O8oo3CL
Jan 17 15:42:55 <Jeevaka> nod, thats my proposal.
Jan 17 15:42:56 <denkenz> Or just use the sim pin enum in the memcmp
Jan 17 15:43:11 <Jeevaka> checkout the link
Jan 17 15:43:36 <Jeevaka> which one can we agree one?
Jan 17 15:44:01 <denkenz> IMO either struct sim_pin_retry { enum retry, int remaining } *retries, int num_retries
Jan 17 15:44:07 <denkenz> or just keep the current API
Jan 17 15:44:25 <pessi> or pass in array type, like typedef sim_pin_retries_array_t[OFONO_SIM_PASSWORD_INVALID] ?
Jan 17 15:44:43 <pessi> typedef int sim_pin_retries_array_t[OFONO_SIM_PASSWORD_INVALID];
Jan 17 15:45:00 <denkenz> typedef should not make any difference
Jan 17 15:45:53 <pessi> oh it will
Jan 17 15:46:24 <pessi> if you have sim_pin_retries_array_t *foo; then sizeof(*foo) == sizeof(sim_pin_retries_array_t)
Jan 17 15:46:42 <pessi> but otherise using array types is just plain evil
Jan 17 15:46:53 <denkenz> which is the same type as we're sizeofing in the first place
Jan 17 15:47:07 <demarchi> Jeevaka: pessi: can't you just use sizeof(sim->pin_retries) instead of sizeof(retries) ?
Jan 17 15:47:20 <Jeevaka> thats my next proposal
Jan 17 15:47:23 <Jeevaka> :)
Jan 17 15:47:27 <Jeevaka> memcmp(retries, sim->pin_retries, sizeof(sim->pin_retries)
Jan 17 15:47:49 <demarchi> yeah, this should work with any compiler version
Jan 17 15:48:06 <Jeevaka> so,can we agree to use sim->pin_retries in memcmp?
Jan 17 15:48:07 <demarchi> otherwise the compiler would be utterly broken
Jan 17 15:48:09 <pessi> demarchi: sure
Jan 17 15:48:09 <balrog-k1n> on which version is there a problem with the current api though?
Jan 17 15:49:35 <Jeevaka> latest clone of the ofono repo
Jan 17 15:49:51 <Jeevaka> compiler version on my side is gcc 4.4.3
Jan 17 15:49:54 <pessi> denkenz: have you had time to look at the gprs & sms offline-proof patches?
Jan 17 15:50:27 <denkenz> nope
Jan 17 18:40:19 <Jeevaka> denkenz: ping
Jan 17 18:40:43 <denkenz> Jeevaka: pong
Jan 17 18:41:54 <Jeevaka> incase of ifx, CMUT is supported whereas CLVL is not supported
Jan 17 18:42:33 <denkenz> For IFX don't bother creating call volume atom
Jan 17 18:42:39 <denkenz> All of this should be done by Pulse
Jan 17 18:43:03 <Jeevaka> yep, but what about other modems which support only CMUT and not CLVL
Jan 17 18:43:13 <Jeevaka> bit more paranoid here
Jan 17 18:43:17 <Jeevaka> ;)
Jan 17 18:45:16 <denkenz> Do those modems exist?
Jan 17 18:45:45 <Jeevaka> dont know
Jan 17 18:45:50 <denkenz> Feel free to fix it, but seemed like if a platform really controls audio volume via the modem side then both exist
Jan 17 18:48:19 <Jeevaka> ok
Jan 17 19:10:39 <balrog-k1n> denkenz: is it ok for a method like the "discover apps" to return a structure that's up to the caller to free?
Jan 17 19:15:56 <denkenz> balrog-k1n: I'd rather not, we have no other APIs like this
Jan 17 19:16:29 <denkenz> balrog-k1n: And in general I don't want to muddy the water with memory management once we cross the core/driver border
Jan 17 19:17:00 <denkenz> balrog-k1n: I want to KISS and stipulate that the driver owns its data and core owns its data
Jan 17 19:17:11 <balrog-k1n> denkenz: ok.. i was trying to think of any method that did this and couldn't find either
Jan 17 19:18:02 <denkenz> There isn't
Jan 17 20:32:55 <padovan> denkenz: ping
Jan 17 22:45:07 <denkenz> padovan: pong
Jan 17 23:14:27 <padovan> denkenz: what's the connman job in the DUN connection process. I'm testing zhenhua rebased patches.
Jan 17 23:14:46 <denkenz> I don't think zhenhua ever got that far
Jan 17 23:15:10 <padovan> ah, that's why I wasn't able to see that.
Jan 17 23:17:43 <padovan> denkenz: what should be ConnMan actions then?
Jan 17 23:18:23 <denkenz> It needs some form of API to add the established dun connection to a bridge / port forwarder
Jan 17 23:18:35 <denkenz> padovan: Talk to sameo over on connman, I think he already has an API in mind
Jan 17 23:20:46 <padovan> denkenz: ok.
Jan 17 23:22:38 <padovan> denkenz: and do you know any detailed doc about DUN connection flow, I'm having problem to understand all the steps needed by a DUN connection.
Jan 17 23:22:52 <denkenz> doc? not really
Jan 17 23:23:05 <denkenz> which parts are you having trouble visualizing?
Jan 17 23:25:38 <padovan> denkenz: I don't know the whole command flow for a DUN connection. And I'm  not sure about which parts inside oFono will handle which part.
Jan 17 23:26:44 <padovan> and also when ConnMan will enter in the game. I'm supposing that it is when I have GPRS attached = 1.
Jan 17 23:28:30 <denkenz> there is really no command flow for DUN according to the baseline BT spec
Jan 17 23:28:40 <denkenz> its just establish rfcomm link and send ATD*99
Jan 17 23:29:08 <denkenz> Then you do the regular ppp negotiation crap + packet flow
Jan 17 23:29:19 <denkenz> Once you have the ppp interface you just hand it off to connman
Jan 17 23:29:34 <denkenz> And it ip forwards packets from this one to the default interface
Jan 17 23:29:42 <denkenz> which could even be wlan, ethernet, etc
Jan 17 23:30:43 <denkenz> there are more advanced usecases like having the remote side defining the gprs contexts
Jan 17 23:30:47 <denkenz> but just ignore those for now
Jan 17 23:34:55 <padovan> Good, I will also look to the gsmdial code, that could help.
Jan 17 23:39:56 <padovan> denkenz: by the gprs context you mean the AT+CGDCONT command?
Jan 17 23:40:09 <denkenz> yep
Jan 17 23:55:48 <padovan> denkenz: and then the ppp negotiation enter in action after after AT+CGATT=1? or is AT+CGATT=1 already part of pp negotiation?
Jan 17 23:59:46 <padovan> ok, I think I get it.
Jan 18 00:03:18 <padovan> denkenz: but from what I saw in gsmdial we need to create a context, or at least a fake one.
Jan 18 00:03:44 <denkenz> nope
Jan 18 00:03:49 <padovan> otherwise we can't achive the PPP negotiation phase.
Jan 18 00:03:51 <denkenz> we're not running against a modem in the DUN case
Jan 18 00:04:22 <denkenz> There's no CGATT or CGACT needed
Jan 18 00:04:47 <denkenz> Correct me if I'm wrong but the BT DUN profile spec mandates the use of ATD*99 which is a legacy thing
Jan 18 00:05:33 <padovan> let me check
Jan 18 00:08:16 <denkenz> According to 27.007 the ATD*99 also performs the attach
Jan 18 00:09:35 <padovan> Great.
Jan 18 00:12:40 <denkenz> However, remember that we're playing the modem
Jan 18 00:12:47 <denkenz> so we don't really need to attach ;)
Jan 18 00:13:25 <padovan> Ok.
Jan 18 00:14:20 <padovan> So I can't base on gsmdial, it always send the CGATT and CGDCONT
Jan 18 00:14:49 <padovan> ATD*99 is sent on the cgdcont_cb there.
Jan 18 00:16:01 <denkenz> so hack gsmdial
Jan 18 00:16:20 <denkenz> you can always add yet another option to skip cgdcont ;)
Jan 18 00:16:50 <padovan> Yeah, that works. :)
Jan 18 00:22:34 <padovan> do you know all the commands that should be skipped. It will save some time searching that.
Jan 18 00:27:23 <denkenz> just look at BT DUN spec directly
Jan 18 00:27:30 <denkenz> i think the only relevant one is ATD
Jan 18 00:27:39 <padovan> Ok
Jan 18 01:25:51 <fhashmi> hello room
Jan 18 01:26:23 <fhashmi> yesterday ofono was able to detect my huawei modem
Jan 18 01:26:34 <fhashmi> but today its not detecting it
Jan 18 01:26:59 <fhashmi> dmesag show that it is connected
Jan 18 01:27:27 <fhashmi> and i also get crossponding /dev/ttyUSB0-1
Jan 18 01:27:40 <fhashmi> any ideas whats going on ???
Jan 18 01:29:45 <padovan> fhashmi: are you using oFono from git?
Jan 18 01:29:56 <fhashmi> yes
Jan 18 01:32:12 <fhashmi> what do you think ?
Jan 18 01:34:18 <padovan> If you are sure that the only thing you changed is oFono, you can run a git bisect and find the bad commit.
Jan 18 01:34:55 <fhashmi> i did not even change oFono
Jan 18 01:35:02 <fhashmi> its wired
Jan 18 01:35:08 <fhashmi> wierd
Jan 18 01:44:37 <fhashmi> i figured it out
Jan 18 02:50:57 <kristenc> denkenz: ping
Jan 18 02:51:09 <denkenz> kristenc: pong
Jan 18 02:51:57 <kristenc> for wake on SMS - all that is needed to support that is for the kernel driver to resume at interrupt, ofono will not need anything special to support this, correct?
Jan 18 02:52:37 <denkenz> I assume so
Jan 18 02:52:49 <kristenc> ok, thank you.
Jan 18 02:53:31 <holtmann> What is wake on SMS?
Jan 18 02:54:22 <kristenc> holtmann: apparently, someone sends you an SMS, and your system wakes up.
Jan 18 02:54:36 <holtmann> Any specific product in mind?
Jan 18 02:54:43 <kristenc> yes.
Jan 18 02:55:05 <holtmann> I think I know what that is.
Jan 18 02:55:16 <holtmann> So this is a bit more trickier.
Jan 18 02:55:45 <holtmann> First, the "bios" needs to keep the modem alive in S3. And the modem need to stay connected to the network.
Jan 18 02:56:13 <holtmann> However to NOT wake up the host and oFono on every single cell change etc., you need to program the modem with proper wakeup parameters.
Jan 18 02:56:22 <holtmann> That needs to be done most likely in the oFono MAL for that modem.
Jan 18 02:56:36 <holtmann> And then that should be it.
Jan 18 02:56:38 <kristenc> so ofono will need to have driver changes to support configuring this feature.
Jan 18 02:56:58 <holtmann> If you wanna do this efficiently and not have random wakeups.
Jan 18 02:57:08 <holtmann> But all these changes are in the MAL drivers. Not in the core.
Jan 18 02:58:18 <kristenc> I think we don't have to worry about S3 - but I need to get more information.  I may mail you later.
Jan 18 02:58:45 <holtmann> Sure. I have dealt with this already some time ago. Just send me an email with the modem details and hardware platform.
Jan 18 02:58:52 <kristenc> ok, thank you.
Jan 18 02:59:09 <holtmann> We just never got any specific specs and AT commands since it was all just talk at that time.
Jan 18 02:59:30 <holtmann> And they were assuming Windows code first and that of course would not really work out.
**** ENDING LOGGING AT Tue Jan 18 02:59:57 2011