**** BEGIN LOGGING AT Mon Nov 08 02:59:57 2010
Nov 08 10:33:59 <trashead> Can anyone help me to understand "How atoms are enabled/disabled for a particular modem?"
Nov 08 11:45:37 <trashead> How atoms are enabled/disabled for a particular modem?
Nov 08 12:05:19 <tmzt> trashead: look at the plugin
Nov 08 14:10:52 <trashead_> [sushil@sofos test]$ ./enable-modem  Traceback (most recent call last):   File "./enable-modem", line 14, in <module>     path = modems[0][0] IndexError: list index out of range 
Nov 08 14:11:13 <trashead_> Can anyone help me in running ./enable-modem for phonesim...?
Nov 08 14:11:25 <trashead_> I've already copy pasted the error!
Nov 08 14:11:57 <trashead_> Anyone here?
Nov 08 14:12:33 <osw> what does list-modems say?
Nov 08 14:13:08 <trashead_> Don't know!
Nov 08 14:13:18 <trashead_> Should I try to print
Nov 08 14:14:35 <trashead_> ?
Nov 08 14:17:22 <denkenz> you have no modems that ofono detects
Nov 08 14:17:51 <trashead_> I've compiled the phonesim..
Nov 08 14:17:58 <denkenz> If you want phonesim, I suggest you look at plugins/phonesim.conf
Nov 08 14:18:20 <trashead_> Where should I put the phonesim.conf?
Nov 08 14:18:43 <trashead_> I've already placed it under /etc/phonesim.conf
Nov 08 14:19:08 <denkenz> And install that into the $prefix/etc/ofono directory, where prefix is what you passed into --sysconfdir while running configure
Nov 08 14:19:33 <denkenz> If you're using ./bootstrap-configure that is /etc.  If you're configuring yourself, then that is likely /usr/local/etc/ofono
Nov 08 14:19:49 <trashead_> I ran ./bootstrap-configure
Nov 08 14:20:52 <denkenz> And have you configured phonesim.conf properly?
Nov 08 14:22:06 <trashead_> And the phonesim.conf is already present there!
Nov 08 14:22:07 <trashead_> [phonesim] Address=127.0.0.1 Port=12345 
Nov 08 14:22:18 <trashead_> Cat command output I've pasted...
Nov 08 14:22:28 <trashead_> All 3 lines are uncommented!
Nov 08 14:27:01 <denkenz> Then try restarting ofonod
Nov 08 14:30:18 <trashead_> Thanks its working...
Nov 08 14:58:30 <trashead_> Can anyone help me understand how to enable/disable atoms for a particular modem?
Nov 08 15:12:32 <denkenz> The driver controls which atoms are enabled
Nov 08 15:13:10 <denkenz> so look into any driver in plugins/ and look for the ofono_{atom}_create calls
Nov 08 16:46:39 <balrog-k1n> denkenz: if BDN is enabled in EFust/EFest, don't we need to check EFbdn still?
Nov 08 16:46:56 <balrog-k1n> EFbdn is only read if it is enabled in EFsst now
Nov 08 16:47:31 <denkenz> AFAIK the 3G specs only mention EFust / EFest for checking the enablement
Nov 08 16:47:43 <denkenz> The EFbdn has to be checked for the 2G case
Nov 08 16:48:25 <denkenz> Is there a specific case you're concerned about?
Nov 08 16:48:27 <balrog-k1n> denkenz: ok, i'm a little confused about 2G vs. 3G
Nov 08 16:48:41 <balrog-k1n> 31.102 should be 3g, right?
Nov 08 16:48:50 <denkenz> Well, just check the flow between 31.102 (3g) and 51.011 / 11.11 (2G)
Nov 08 16:49:08 <denkenz> The 2G specs talk about making sure that EFbdn / EFfdn is not invalidated
Nov 08 16:49:20 <denkenz> Or was it EFadn, one of those :)
Nov 08 16:51:55 <denkenz> I suppose we could be extra pedantic and make sure that EFbdn / EFfdn are *actually* on the SIM
Nov 08 16:53:40 <balrog-k1n> denkenz: no, i guess you're right.  i was just worried that there was a difference between 2g and 3g initialisation in sim.c
Nov 08 16:55:35 <balrog-k1n> denkenz: should there be an internal api so other atoms (like sms or cb) can check if a capability is active? (like sms download or cb download)
Nov 08 16:56:08 <denkenz> You mean through EFest or something?
Nov 08 16:56:26 <balrog-k1n> yeah
Nov 08 16:57:03 <balrog-k1n> the SMS download envelope should be sent if it's active in EFsst/EFust/EFest only
Nov 08 16:57:19 <denkenz> Sounds like a good idea
Nov 08 16:57:30 <denkenz> I think the sim already exposes sst / est tables AFAIK
Nov 08 16:57:51 <denkenz> If not, feel free to suggest something
Nov 08 16:58:20 <balrog-k1n> ah yes, it does, i didn't check include/sim.h, only src/ofono.h
Nov 08 16:59:03 <balrog-k1n> it exposes the CPHS service table anyway
Nov 08 16:59:17 <balrog-k1n> not the EFsst/EFust thing, it seems
Nov 08 16:59:54 <denkenz> Yeah, so lets add those
Nov 08 16:59:59 <balrog-k1n> ok
Nov 08 17:00:15 <denkenz> Or do a direct lookup if the service numbers are the same between 2G & 3G
Nov 08 17:00:37 <denkenz> But doesn't look like they are
Nov 08 17:00:53 <balrog-k1n> yes, looks like they are different
Nov 08 17:01:46 <balrog-k1n> to save calls maybe the api should be is_capability_active(sim, ust_constant, est_constant, sst_constant)
Nov 08 17:02:38 <denkenz> I think you can skip the est constant
Nov 08 17:02:50 <denkenz> That's only needed for BDN/FDN
Nov 08 17:03:07 <balrog-k1n> ah right
Nov 08 17:15:29 <denkenz> balrog-k1n: "If there are only watches with non-NULL
Nov 08 17:15:29 <denkenz> callback, it'll call all of them and not reset application."
Nov 08 17:15:48 <denkenz> what's the purpose of this one?
Nov 08 17:18:01 <balrog-k1n> denkenz: it first tries to see if we have change handlers for all the files that changed
Nov 08 17:18:28 <balrog-k1n> if there is any that is not handled, we recreate all the atoms and this way take the change into account
Nov 08 17:19:06 <denkenz> hmm, can't we assume that if it isn't handled, then ignore it? (flushing the cache anyway)
Nov 08 17:19:27 <balrog-k1n> like if EFest had changed for example, we probably have no way to handle that other than recreate atoms
Nov 08 17:19:45 <balrog-k1n> denkenz: if a file can be ignored than we can just not watch it at all
Nov 08 17:21:09 <denkenz> Hmm, so EFest is a bizarre case
Nov 08 17:21:44 <balrog-k1n> or if the card suddenly says that EFphase changed
Nov 08 17:22:23 <denkenz> I'm pretty sure that most of these would be done as a UICC reset, not just a file change notification
Nov 08 17:24:06 <denkenz> But yes, the SIM can change the EFbdn / EFfdn status based on a STK refresh
Nov 08 17:25:14 <denkenz> However, we can't assume that we have control of the terminal response, e.g. the "not reset application" part
Nov 08 17:25:35 <denkenz> We might just get a SATN and that's it
Nov 08 17:30:58 <balrog-k1n> denkenz: if we "reset application" we're always safe because everything gets reinitialised
Nov 08 17:31:20 <denkenz> yeah, I know, reset is basically sim remove, sim insert
Nov 08 17:31:27 <balrog-k1n> i gotta go, let's talk about it later
Nov 08 17:32:02 <denkenz> sure, you know where to find me ;)
Nov 08 17:35:39 <denkenz> balrog-k1n: Actually I think I just got what you're trying to accomplish, and I think your approach is the right one, but lets talk about it a bit more
Nov 08 17:47:25 <padovan> denkenz: In which situations we will want a silent modem reset?
Nov 08 17:47:44 <denkenz> padovan: Basically if the modem firmware shits itself
Nov 08 17:48:07 <denkenz> The user should not be presented with a PIN basically
Nov 08 17:48:54 <denkenz> The oFono task is pretty straight forward, just need to re-init the atoms
Nov 08 17:49:37 <padovan> Do we monitor firmware behaviour already? to know when call the reset?
Nov 08 17:50:44 <padovan> i.e., how does oFono trigger the reset?
Nov 08 17:51:00 <denkenz> padovan: The modem will have an unsolicited notification of some sort
Nov 08 17:51:08 <denkenz> either through an AT command, or GPIO or something 
Nov 08 17:51:26 <denkenz> so the driver just needs to inform the core of this
Nov 08 17:52:17 <denkenz> Basically the core needs to reset its state and try to get back to the original state
Nov 08 17:52:33 <denkenz> so if e.g. the modem was online, then after the 'silent reset' we need to try to get back to the online state
Nov 08 17:54:42 <padovan> the driver notification to the core is not done yet, right?
Nov 08 17:56:35 <denkenz> Nope
Nov 08 17:56:50 <denkenz> That's where the magic has to happen basically
Nov 08 17:58:48 <mikeleib> denkenz: going to dublin for conf?
Nov 08 17:58:59 <denkenz> mikeleib: yep
Nov 08 17:59:21 <mikeleib> awesome
Nov 08 17:59:29 <mikeleib> denkenz: want to talk to peeps about ofono-qt bindings?
Nov 08 17:59:53 <denkenz> sure
Nov 08 17:59:57 <mikeleib> sooper
Nov 08 18:00:07 * mikeleib forwards thread to denkenz
Nov 08 18:44:30 <pessi> denkenz: state 4 is "incoming"?
Nov 08 18:47:08 <pessi> hmph.
Nov 08 19:06:33 <denkenz> pessi: I didn't look into the patch, just making sure the terminology was consistent
Nov 08 19:07:57 <pessi> denkenz: I'll do s/alerting/incoming/
Nov 08 19:09:22 <pessi> hmhmh... if driver returns CME error 14 to cpin? is it up to driver or core to retry?
Nov 08 19:12:23 <denkenz> error 14 is sim not ready?
Nov 08 19:14:02 <pessi> sim busy
Nov 08 19:14:26 <pessi> zte returns it initially but retry works
Nov 08 19:14:45 <denkenz> Right now my feeling is that it should be the driver
Nov 08 19:14:58 <denkenz> On most 'sane' hardware the insertion notification tells us when the sim is ready
Nov 08 19:15:07 <denkenz> so CPIN? returning CME errors should not happen
Nov 08 19:15:29 <denkenz> If this becomes a burden, then we can consider moving it into the core
Nov 08 19:15:33 <pessi> most hardware is insane
Nov 08 19:16:38 <denkenz> I know, but the hacks are also all different
Nov 08 19:23:45 <padovan> denkenz: I still don't have enough info about the reset trigger. Who in the driver will list such unsolicited notification? How to if that is really unsolicited?
Nov 08 19:24:03 <padovan> I'm completely lost on that.
Nov 08 19:24:51 <denkenz> padovan: I have to go back to the docs to figure out how this works, but for now just assume the driver "knows"
Nov 08 19:25:04 <denkenz> padovan: It doesn't really matter how
Nov 08 19:25:27 <denkenz> I think it is a GPIO line trigger
Nov 08 19:26:40 <padovan> denkenz: ok, so you prefer to have the reset stuff in the core first than in the drivers?
Nov 08 19:26:54 <denkenz> yeah, the core is the interesting part
Nov 08 19:27:04 <denkenz> For the driver, feel free to invent something
Nov 08 19:27:06 <denkenz> e.g. with phonesim
Nov 08 19:27:43 <denkenz> just add a button which sends some message and resets everything
Nov 08 19:28:47 <padovan> Ok.
Nov 08 19:50:46 <denkenz> Getting crowded in here
Nov 08 19:52:53 <demarchi> denkenz: about the tty support, how is the interaction between the dbus interface and the modem?
Nov 08 19:53:19 <demarchi> denkenz: i mean, how to talk to modem to enable/disable the tty?
Nov 08 19:55:26 <denkenz> demarchi: Same was as any other atom talking to the driver
Nov 08 19:56:07 <denkenz> demarchi: A good example would be set_online on the modem driver, or set_fast_dormancy on the radio settings driver
Nov 08 19:57:20 <denkenz> For that one radio_settings atom is a good starting point btw
Nov 08 19:57:47 <denkenz> We essentially just want an atom with query & set tty methods
Nov 08 19:58:01 <demarchi> denkenz: humn.. thanks, i'm starting to look at it
Nov 08 20:02:11 <padovan> denkenz: during reset, all atom need to be removed. Is that a complete remove of the atom like the modem remove we have today?
Nov 08 20:02:38 <padovan> and then we have to probe everything again?
Nov 08 20:03:11 <denkenz> padovan: I think so, we need to assume that we have to re-power up the modem and re-online it
Nov 08 20:03:26 <denkenz> assuming that was the old state
Nov 08 20:04:08 <denkenz> The atom probing is not a big deal actually, atoms will get re-added by the virtual of set_powered and set_online
Nov 08 20:04:23 <denkenz> s/virtual/virtue
Nov 08 20:05:36 <denkenz> maybe later on we can play tricks with optimizations, but for now it seems the safest approach
Nov 08 20:42:41 <padovan> denkenz: ok, should not be hard, I'll start with reset button in phonesim. Trigger it in the phonesim plugin and the reset everything in the core.
**** ENDING LOGGING AT Tue Nov 09 02:59:57 2010