**** BEGIN LOGGING AT Wed Aug 18 02:59:57 2010 Aug 18 05:35:54 denkenz: What is SimReady property for? And on which interface? Aug 18 05:36:08 holtmann: Damn was about to go to sleep :P Aug 18 05:36:19 holtmann: Mainly for ConnMan or others mesing with the Online property Aug 18 05:36:23 I just woke up ;) Aug 18 05:36:39 holtmann: We need some sort of indication when oFono has queried the PIN Aug 18 05:36:46 And it is safe to set Online Aug 18 05:37:00 It is on the SIM interface, right? Aug 18 05:37:01 Until the PIN is queried we simply tell the application to bugger off Aug 18 05:37:11 Probably, but could be on Modem as well Aug 18 05:37:15 e.g. OnlineAvailable Aug 18 05:37:59 More thought required, I just threw it out there Aug 18 05:38:10 The alternative is for ConnMan to track IMSI Aug 18 05:38:24 Once that is known you know Online is available Aug 18 05:38:34 If we just make it a generic "Ready" property on the modem interface, I am actually okay with it. Aug 18 05:39:03 Ready seems too generic, Ready for What? Aug 18 05:39:06 SimReady should be implied by having the SIM interface available. Aug 18 05:39:56 Can't, because if the PIN is locked we still can't go to Online Aug 18 05:40:05 But the SIM interface is there Aug 18 05:40:30 Once you EnterPin, there's a bit of a lag before it is safe to proceed Aug 18 05:40:59 Yeah, but then the SIM interface is present and PinRequired = True. Aug 18 05:41:13 Sure, but then you EnterPin Aug 18 05:41:19 PinRequired = none Aug 18 05:41:28 But you still don't have the IMSI Aug 18 05:41:43 Many atoms depend on that being known already when they initialize Aug 18 05:41:44 Can we make EnterPin block until it is safe. And keep PinRequired = True until we know we are good. Aug 18 05:42:08 Perhaps, but then signals get emitted for properties that we read Aug 18 05:42:24 So it looks kinda bad Aug 18 05:42:45 Might be easier to delay Online state itself until after IMSI reading Aug 18 05:43:01 e.g. only execute Online once PIN has been queried Aug 18 05:43:22 And return OK/Error then Aug 18 05:44:45 There's also the original issue these guys are hitting Aug 18 05:44:56 e.g. PropertyChanged(Powered) = True Aug 18 05:45:02 ---> SetProperty(Online) Aug 18 05:45:15 Happens so fast that we haven't even queried the PIN yet :P Aug 18 05:45:39 We could just try to delay the Online state setting until we have all details. Aug 18 05:46:18 So on a perfect modem Online = True is instant. On the crappy ones it takes some time. Aug 18 05:46:26 And we do all the magic in the background. Aug 18 05:46:47 I am really against having the UI or ConnMan being able to read 3 different properties here. Aug 18 05:47:01 Before we can do anything. Aug 18 05:47:49 The important one is the SIM Present and PinLocked properties that ConnMan should take into account. Aug 18 05:51:23 Yeah I think that delaying Online result until we know something is a good idea Aug 18 05:51:38 At least the best alternative so far Aug 18 05:53:35 The more complex we make it for ConnMan the more stupid it is. Aug 18 05:53:54 And I think ConnMan already needs to check too many properties before it can do something useful with the modem. Aug 18 05:54:03 At least in the PIN locked case. Aug 18 05:54:23 Yeah, PIN lock is a pain Aug 18 05:54:49 The only reason I said property is that ConnMan can simply listen to that one Aug 18 05:54:55 Makes things easier Aug 18 05:55:32 Not really. Aug 18 05:55:43 The more properties we have to listen to the worst this gets. Aug 18 05:56:07 You sure? With SimReady connman listens to 1 Aug 18 05:56:13 Listening to Present and PinRequired is enough. If both are fine, we must be able to call Online = True. Aug 18 05:56:22 With Present, PinRequired, etc you listen > 1 Aug 18 05:56:45 Fair enough, but then SimReady is duplicate information. Aug 18 05:56:57 Also, we don't emit PinRequired = none Aug 18 05:57:06 Which might be a mistake Aug 18 05:57:13 We might need to fix that one then. Aug 18 05:57:38 To clarify, we don't emit PinRequired = none if there is no PIN set Aug 18 05:57:57 If there is a PIN, then we emit = 'pin', then 'none' Aug 18 06:05:34 We need to emit that in the +CPIN = READY case as well. Aug 18 06:05:38 So that needs fixing. Aug 18 06:06:32 Nod, I concur, I'll fix that part tomorrow Aug 18 07:04:27 denkenz: sim ready polling was just commited to stemodem. why not huawei can't have it as well? Aug 18 07:05:14 s/not// Aug 18 11:23:23 kvalo: I can have it if someone does a patch for it. However it will only be an interim solution. Aug 18 11:23:30 s/I/It/ Aug 18 11:24:43 holtmann: I sent a patch last week but denkenz didn't take it Aug 18 11:25:31 What was the reason that he gave? Aug 18 11:26:41 he wants to have core support it instead of hacks in the driver Aug 18 11:27:13 How nasty was the Huawei hack, because that driver becomes uglier and uglier every day. Aug 18 11:27:36 The STE was simple and I made the judgment call to include it for now. Aug 18 11:27:49 We still need proper core support for this. Aug 18 11:28:50 holtmann: http://lists.ofono.org/pipermail/ofono/2010-August/003750.html Aug 18 11:29:15 holtmann: but it depends on my first patch which I need to fix: http://lists.ofono.org/pipermail/ofono/2010-August/003749.html Aug 18 11:30:00 That patch is a clear no. Aug 18 11:30:30 You are hacking around a callback that is only intended to be called from oFono core. Aug 18 11:31:26 The STE polling delays the set_powered callback. Aug 18 11:32:50 kvalo: And do have fixed the not polling forever case that Denis mentioned? Aug 18 11:33:18 no, not yet Aug 18 11:35:41 Then please do that first. Aug 18 11:36:58 sure, as soon as I get something else finished first. way too many tasks (and components) at the same time Aug 18 11:37:52 Okay. Aug 18 14:11:29 there's STE support? Aug 18 14:11:45 I have this aava brick with an STE in it. Can holtmann xfrom my brick into a phone? Aug 18 14:12:21 The oFono pieces for STE are there. Not sure how far our kernel patches are to make this work. Aug 18 14:12:36 It needs SPI-Slave support and SPI-CAIF driver. Aug 18 14:13:06 I thought UMG had that stuf Aug 18 14:13:31 it was my understanding that code was headed to or sent to lkml Aug 18 14:13:42 No idea. I stopped tracking that. Aug 18 14:13:59 writing dialer settings for the brick on my desk is rather unsatisfying Aug 18 14:14:49 I can figure. Aug 18 14:15:02 In theory that brick can be made work. Aug 18 14:15:20 I think it's a legend. I've yet to see empirical evidence Aug 18 14:16:09 I have made phone calls with it. It was just never stable. Aug 18 14:16:44 I find that to be generically true about the platform in general. But I am very surprised to hear about this phone calls with it business Aug 18 14:17:13 is this something that can be rolled out into distro Aug 18 14:17:14 It is tricky, It is not an oFono problem. It is a CAIF transport problem. Aug 18 14:17:33 * mikeleib is not real smart and doesn't even know what CAIF is Aug 18 14:17:48 google shows me lwn Aug 18 14:18:21 It is like Phonet for Nokia or GSM MUX. It is just a multiplexer. Aug 18 14:18:22 this sounds like the ttymux that the FSO people made, but with AT Aug 18 14:18:49 CAIF is more sophisticated MUX than GSM MUX. Aug 18 14:21:46 it has better ascii art in the patch-set at least Aug 18 14:23:25 is CAIF merged? Aug 18 14:25:18 Yes. Aug 18 14:25:57 so issue is plumbing CAIF between STE and SPI-slave? Aug 18 14:26:14 Yep. And especially for the Aava one. Aug 18 14:27:19 this sounds like a solvable problem. It sounds like there's no proprietary unknowns. It sounds just like it needs debugging. Is that a correct understanding? Aug 18 14:29:06 Basically. Aug 18 14:29:25 who is the right person to motivate to unbrick my telephone brick? Aug 18 14:30:05 No idea. Not me ;) Aug 18 14:30:47 holtmann: Doesn't Alan have a working kernel for that piece of HW ? Aug 18 14:31:15 He might, I never tried it. Aug 18 14:31:27 For MRST yes, for the STE CAIF specific SPI driver, I don't know. Aug 18 14:31:39 mikeleib: You may want to ask _A_ about it Aug 18 14:31:46 * mikeleib will do so Aug 18 16:51:36 sameo: do you really want to downgrade to GPRS.Powered handling? Aug 18 17:08:02 pessi: not downgrade, but fall back Aug 18 17:08:38 pessi: until all oFono drivers support Online setting, there's no other way Aug 18 17:09:22 pessi: this is what we do right now for modem enabling/disabling, so we're cheating already :) Aug 18 17:32:08 sameo: and connman_device_get_ident(), do you want a patch exposing it? Aug 18 17:33:21 ...and should it do g_strdup() or just return ident? Aug 18 17:36:24 pessi: why do you want to expose the device identifier again ? Aug 18 17:37:09 because I want to use check if current ident is same as current IMSI Aug 18 17:39:12 I see. A separate patch, yes, and no strdup needed. Aug 18 17:40:56 Hola, buenos días -- ¿tienes un momento? Aug 18 17:41:33 Hola Inaky :) Aug 18 17:41:42 shit, wrong window :) Aug 18 17:41:54 sorry guys :P **** BEGIN LOGGING AT Wed Aug 18 20:55:40 2010 Aug 18 21:41:17 denkenz: so is there a difference between what the driver would be setting as a "ready" state in the proposed sim_ready_notify function and the existing OFONO_SIM_STATE_READY state? Aug 18 22:04:00 kristenc: They are related Aug 18 22:04:30 Basically it would tell oFono core that it is safe to query SIM files which are PIN protected Aug 18 22:04:59 and go into the SIM_STATE_READY once the IMSI has been queried Aug 18 22:05:57 This one is meant more as a hint from the hardware to the core Aug 18 22:06:11 Because hw does its own caching, etc Aug 19 01:07:52 denkenz: your auto-attach patch leaves Attached un-updated Aug 19 01:11:36 pessi: Which case? Aug 19 01:24:47 successful case Aug 19 01:26:59 Gah ok I see what you mean Aug 19 01:27:07 That code is way too complicated Aug 19 01:57:24 pessi: I pushed a fix, let me know if it works Aug 19 02:45:28 denkenz: Could g_memdup() fail to alloc the memory? If we use this, we don't need to care about the failure? Aug 19 02:45:59 No don't worry about it Aug 19 02:48:26 ok, thanks **** ENDING LOGGING AT Thu Aug 19 02:59:57 2010