Re: Access to SIM card when Modem is not Powered
Hi Pekka, Attached. In the future, can you please use git-send-email so that I can comment on the patch much easier. So far I like the idea of disable having a hint on whether a shutdown is in progress more than an explicit shutdown method. That is also possible, but then we need also more power states (besides off and on). After taking a look, I'm even more convinced that a hint to disable is less invasive. The proposal is simply way too complicated. With a hint the driver can take the necessary steps to disable the modem (what is done by shutdown now) and return once it finishes. The ofono exit logic does not need to change at all with this approach... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Denis, 2010/3/31 Denis Kenzior denk...@gmail.com: 1) and 2) are already done through D-Bus, only thing is missing is oFono core properly supporting transitions between Powered false and true. So I just checked again, and we remove all atoms when turning off (even if off subsequently fails). So I really don't see a need to expose the transition (e.g. going up, going down) as a property. How do you want to use this information? I want to prevent core from exiting while a modem is in transitional state. Before ofonod terminates, it calls disable and waits until Powered gets false. I'd rather change Powered to false immediately (when modem shutdown starts) but still keep waiting until modem is properly powered down. 1) If the modem reboots, then handle this inside the isimodem plugin of oFono. It is already handled fine in core. isidriver calls ofono_modem_set_powered(false) when it detects that isimodem reboots. When modem is back in business, it calls ofono_modem_set_powered(true). Is there a particular reason why I should reinvent the wheel? From your earlier posts it wasn't clear that you're happy with how this works. I perceived that there was some issue... It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) No reason to involve userspace here. If the handset gets turned off, then the modem object just goes away. What is the difference between modem object not being there at all and modem object being there, but with Powered=false? Think of it conceptually as a USB device being in an off state but still on the bus. You still know the device is attached, even if it is of limited use. Remember that we use this to populate remote bluetooth devices, modems configured via modemconf and udev/netlink. This conveys presence and potential usability. That sounds sensible. With the current ofono core, removing the object path will also remove the config information. What are you using the config information for? It is possible that we should implement ofono_modem_unregister that would keep around the non-driver bits of the modem object. So far I have not done so because I saw no need... Currently I'm using config to determine if the isimodem should or should not control the modem and which phonet device it should or should not use. It is used to determine if ofonod is run with maemo5 cellular daemons or without them. 2) What do you mean by this. They are asynchronous. Not in the master branch. enable() and disable() are async, probe() and remove() are sync. probe and remove are sync for a reason, the core is going to become extremely complicated otherwise. Been there and done that, so you better have a very good reason for wanting this. How the driver knows if the disable() is called because someone just tried to set Powered=false or if ofonod is terminating? In first case, I just want modem to go standby (and flush the atoms) and keep the SIM warmed up and ready, in the second case, driver should ask modem to do proper power off and then does all the required jazz with the gpio lines. It would be help much if disable() would indicate if soft poweroff or hard poweroff is required; likewise This can be added, but the question is are you sure you need it? None of the other hardware we have would benefit from this functionality at all. This immediately raises the question of usefulness. Are you sure this isn't better accomplished by a specific plugin for your system as discussed elsewhere in this thread? You don't seem to handle modem resets at all. Once atdriver gets so far, other hardware will benefit, too. ofono_modem_set_powered() could take enum with transitional states (powering_on, powered_on, powering_off, powered_off + perhaps something like powered_standby). If you don't feel like doing it, I'm happy to contribute. Again, usecase please. How are you going to use this information? * clean handling of modem reboots * keep modem powered while ofonod is running, power it down before ofonod exits * allow applications to put modem on standby by with Powered property (however, with N900 modem, the standby is not different from the pre-sim state) 3) I don't understand this. We have pre-sim and post-sim functionality. If you RFKILL a radio it would be same as removing its object path. Or do you wanna access the SIM card while RFKILLed. What is that good for? Nobody wants to re-enter the pin code if they exit flight mode. It should be possible to spool SMSs while the device is in flight mode. Is there any good reason to keep SIM offlimits? Please note that if your enable/disable behavior only shuts the rx/tx circuits then repeating PIN entry won't be a problem. And I already commented on this elsewhere in the thread. All I ask is that before we start adding tons of
Re: Access to SIM card when Modem is not Powered
to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti: It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) But then Register()'s meaning is overloaded to mean both RF on *and* (automatically) register. This doesn't work in the manual registration case, where after landing on the other side of the Atlantic, you first need to turn RF on, then select a roaming partner from a list. In fact, Deregister() is currently not all that useful, and not even implemented in isimodem. I think it should simply be removed. What we miss from the core is a way to do asynchronous cleanup (separate from Powered). A shutdown() method in modem driver and corresponding callback, like ofono_modem_shutdown_ready(). This way we can do what ever N900 requires us to do and there is no need to touch other drivers. That sounds reasonable to me. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Aki, to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti: It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) But then Register()'s meaning is overloaded to mean both RF on *and* (automatically) register. This doesn't work in the manual registration case, where after landing on the other side of the Atlantic, you first need to turn RF on, then select a roaming partner from a list. I agree, Register is not the right one here. In fact, Deregister() is currently not all that useful, and not even implemented in isimodem. I think it should simply be removed. I'm actually fine removing it since most modems end up not supporting this either. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
2010/3/29 Denis Kenzior denk...@gmail.com: However, then powering modem down, there are problems. The N900 modem control needs to make difference between the state where the modem is no more useful and the safe-to-exit state when the power off request has been completed, modem has flushed its state to flash and given some time to safely turn off the SIM card. So if I understand correctly, you are saying that once the powered=off request has been sent down to the modem, no other requests are valid. In other words, oFono's current implementation does not remove the atoms until powered=off request succeeds (which might result in those atoms attempting operations), which is wrong. That is also a problem. The other problem is that the party controlling the modem power state is supposed to keep GPIO lines in known position for a while after the modem has indicated it has been powered down. In an N900 running maemo, a daemon called sscd does that. sscd exits only after modem has been safely powered down during reboot and shutdown. If ofonod does the controlling, it should hang around after power off for a while, too. Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). Also, if an another SetProperty(Powered) call is made while the driver is powering the modem on or off, the change is ignored. It seems to me that we need more fine grained power control than just the current boolean in the core, too. We reply with the busy error, you're correct. However, I don't really see anything better we can do here, do you have any suggestions? Keep the target state around somewhere, or call enable/disable regardless of the current state of the Powered property? -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
2010/3/29 Bastian, Waldo waldo.bast...@intel.com: Pekka Pessi wrote: I've been porting the N900 modem control code to oFono. The semantics of Powered is fine with respect of the atoms, in other words, if the modem crashes and boots itself, all the atoms are flushed nicely. When powering up, the Powered can be set to true when the modem is really up and running. Do you have an overview of the different modes and transitions that the N900 modem control is using today? Not really. What do you want to know? There are some design documents describing GPIO line usage, something about SSI used for phonet messages and how modem bootloader interacts with it, and documents about the MTC design and different MTC states. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
ti, 2010-03-30 kello 13:36 +0200, ext Pekka Pessi kirjoitti: Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). My preference would be to have these things handled as oFono plugins. That being the recommended way of course doesn't preclude some other modem needing a slave plugin that monitors the accomplishments of a separate daemon. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Pekka, That is also a problem. The other problem is that the party controlling the modem power state is supposed to keep GPIO lines in known position for a while after the modem has indicated it has been powered down. In an N900 running maemo, a daemon called sscd does that. sscd exits only after modem has been safely powered down during reboot and shutdown. If ofonod does the controlling, it should hang around after power off for a while, too. So I'm still having trouble understanding the issue. When oFono calls disable, the driver is expected to take all necessary steps to disable the modem. If that means waiting N seconds after the command has been sent, so be it. During shutdown of the daemon, oFonod waits for a grace period and waits on any devices that are being shut down. In effect it hangs around after power off. If I'm still on the wrong track, someone please explain it to me better. Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). Automatic powerup is actually possible from the driver. See HFP driver for details. We reply with the busy error, you're correct. However, I don't really see anything better we can do here, do you have any suggestions? Keep the target state around somewhere, or call enable/disable regardless of the current state of the Powered property? Note that oFono does not record the powered preferences, ConnMan is responsible for that. Sending a disable when we are already disabled would be wrong and would break some plugins. And I'm still having trouble understanding why you want this. Please give concrete use-cases. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Pekka, I've been porting the N900 modem control code to oFono. The semantics of Powered is fine with respect of the atoms, in other words, if the modem crashes and boots itself, all the atoms are flushed nicely. When powering up, the Powered can be set to true when the modem is really up and running. Do you have an overview of the different modes and transitions that the N900 modem control is using today? Not really. What do you want to know? There are some design documents describing GPIO line usage, something about SSI used for phonet messages and how modem bootloader interacts with it, and documents about the MTC design and different MTC states. this really sounds like you guys should implement RFKILL support for the Phonet subsystem. Solving this in userspace is wrong since the GPIO lines are deeply attached to specific hardware design. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Pekka, That is also a problem. The other problem is that the party controlling the modem power state is supposed to keep GPIO lines in known position for a while after the modem has indicated it has been powered down. In an N900 running maemo, a daemon called sscd does that. sscd exits only after modem has been safely powered down during reboot and shutdown. If ofonod does the controlling, it should hang around after power off for a while, too. So I'm still having trouble understanding the issue. When oFono calls disable, the driver is expected to take all necessary steps to disable the modem. If that means waiting N seconds after the command has been sent, so be it. During shutdown of the daemon, oFonod waits for a grace period and waits on any devices that are being shut down. In effect it hangs around after power off. Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). Automatic powerup is actually possible from the driver. See HFP driver for details. We reply with the busy error, you're correct. However, I don't really see anything better we can do here, do you have any suggestions? Keep the target state around somewhere, or call enable/disable regardless of the current state of the Powered property? Note that oFono does not record the powered preferences, ConnMan is responsible for that. Sending a disable when we are already disabled would be wrong and would break some plugins. And I'm still having trouble understanding why you want this. Please give concrete use-cases. Sure. I want Powered-1 that controls the atoms. Atoms should be loaded when modem is in responsive state and removed when, e.g., modem reboots. This we can do now, iow, if you connect a Nokia phone via USB, oFono can follow its state via the MTC indications it sends on top of the phonet link running over USB. I want Powered-2 that controls the modem power. When ofonod starts in N900, it should power up the internal modem. When ofonod terminates itself, it should shut down modem nicely before calling exit(). Now, enable/disable/ofono_modem_set_powered() controls both aspects; I want to separate them. It is also possible to implement Powered-2 in the probe/remove methods; however, they are quite time-consuming operations and best done from the mainloop. I am with Denis here. I am missing the point in what you are trying to achieve. The complexity you propose should not be exposed to the applications at all. This can be all handled internally. Or I am missing something essential, but right now, I don't see it. It seems to me that Marcel thinks Powered should control the RF state, too. So, a separate property for enabling he RF would be nice, too. That is what I call RFKILL and we have a proper subsystem for that. And it is different from your Power-1 and Power-2 thing? Sorry, but you really lost me now. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Aki, 2010/3/30 Denis Kenzior denk...@gmail.com: The answer is that exposing this as a property is not going to happen because it is fundamentally wrong. And in effect it already is exposed, e.g. the fact that modem object is present in oFono. You have several options here: So I think what you are saying is that if a modem object exists, it is available. That is, the HW has been powered up and initialized properly. And that the Powered property is about whether or not the modem's cellular is active (RF on/off). Powered is about whether the modem is useable. Today we don't make a distinction between tx/rx off with sim, tx/rx off without sim, or fully active. We need to look closely at whether enabling flight mode (e.g. SIM on, while TX/RX is off) makes sense. It is something we should consider, but challenging since most of the SIM attributes are exposed through atoms which won't be generally available when in Flight mode (e.g. SMSC address on SIM atom, MBDN on message waiting, etc) If this is the case, then I think it'll do. There is a corner case when the modem is borked and cannot be properly powered but needs to be taken to a care point (not that that ever happens IRL ;), and I would rather see this indicated explicitly rather than implicitly by ModemManager returning an empty list of modems. So finally someone tells me an actual use case, how hard was that? :) It is still possible to expose this information on the interface provided by your custom plugin, I'm against exposing this as a property on Modem interface. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
2010/3/30 Denis Kenzior denk...@gmail.com: We need to look closely at whether enabling flight mode (e.g. SIM on, while TX/RX is off) makes sense. It is something we should consider, but challenging since most of the SIM attributes are exposed through atoms which won't be generally available when in Flight mode (e.g. SMSC address on SIM atom, MBDN on message waiting, etc) I think this is mostly about SIM PIN. For instance, in the N900, PIN is entered very early in the boot process, but RF is activated (Powered=true in oFono) only after the desktop is fully usable. Granted, you could always prompt for the PIN only after the desktop is fully usable, but the point is, this is now the only option you have available with oFono. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
2010/3/30 Marcel Holtmann mar...@holtmann.org: So I'm still having trouble understanding the issue. When oFono calls disable, the driver is expected to take all necessary steps to disable the modem. If that means waiting N seconds after the command has been sent, so be it. During shutdown of the daemon, oFonod waits for a grace period and waits on any devices that are being shut down. In effect it hangs around after power off. Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). Automatic powerup is actually possible from the driver. See HFP driver for details. We reply with the busy error, you're correct. However, I don't really see anything better we can do here, do you have any suggestions? Keep the target state around somewhere, or call enable/disable regardless of the current state of the Powered property? Note that oFono does not record the powered preferences, ConnMan is responsible for that. Sending a disable when we are already disabled would be wrong and would break some plugins. And I'm still having trouble understanding why you want this. Please give concrete use-cases. Sure. I want Powered-1 that controls the atoms. Atoms should be loaded when modem is in responsive state and removed when, e.g., modem reboots. This we can do now, iow, if you connect a Nokia phone via USB, oFono can follow its state via the MTC indications it sends on top of the phonet link running over USB. I want Powered-2 that controls the modem power. When ofonod starts in N900, it should power up the internal modem. When ofonod terminates itself, it should shut down modem nicely before calling exit(). Now, enable/disable/ofono_modem_set_powered() controls both aspects; I want to separate them. It is also possible to implement Powered-2 in the probe/remove methods; however, they are quite time-consuming operations and best done from the mainloop. I am with Denis here. I am missing the point in what you are trying to achieve. The complexity you propose should not be exposed to the applications at all. This can be all handled internally. Or I am missing something essential, but right now, I don't see it. I'm trying to 1) load atoms only after when isimodem is up and running and reset the state of the isimodem atoms in case the isimodem reboots (or user turns off a Nokia handset connected via USB) 2) have asyncronous probe and remove 3) separate rf state and availablity of the atoms, especially the SIM atoms. With the current enable/disable/ofono_modem_set_powered, I can do 1) or 2), but not both. I can not do 3 at all. non of these should be solved via the D-Bus at all. Really this is internal modem specific details. You are approaching this wrongly. 1) and 2) are already done through D-Bus, only thing is missing is oFono core properly supporting transitions between Powered false and true. 1) If the modem reboots, then handle this inside the isimodem plugin of oFono. It is already handled fine in core. isidriver calls ofono_modem_set_powered(false) when it detects that isimodem reboots. When modem is back in business, it calls ofono_modem_set_powered(true). Is there a particular reason why I should reinvent the wheel? No reason to involve userspace here. If the handset gets turned off, then the modem object just goes away. What is the difference between modem object not being there at all and modem object being there, but with Powered=false? With the current ofono core, removing the object path will also remove the config information. 2) What do you mean by this. They are asynchronous. Not in the master branch. enable() and disable() are async, probe() and remove() are sync. How the driver knows if the disable() is called because someone just tried to set Powered=false or if ofonod is terminating? In first case, I just want modem to go standby (and flush the atoms) and keep the SIM warmed up and ready, in the second case, driver should ask modem to do proper power off and then does all the required jazz with the gpio lines. It would be help much if disable() would indicate if soft poweroff or hard poweroff is required; likewise ofono_modem_set_powered() could take enum with transitional states (powering_on, powered_on, powering_off, powered_off + perhaps something like powered_standby). If you don't feel like doing it, I'm happy to contribute. 3) I don't understand this. We have pre-sim and post-sim functionality. If you RFKILL a radio it would be same as removing its object path. Or do you wanna access the SIM card while RFKILLed. What is that good for? Nobody wants to re-enter the pin code if they exit flight mode. It should be possible to spool SMSs while the device is in flight mode. Is there any good reason to keep SIM offlimits?
Re: Access to SIM card when Modem is not Powered
Hi denis, 2010/3/19 Denis Kenzior denk...@gmail.com: I've been talking about this exact issue with Marcel but so far we have not firmly agreed on any solution. Our current thinking is to keep Powered semantics as they are, but to also add Flight mode property. This would in affect allow interaction with the SIM while the radio is off. For some modems it might not even make sense to support flight mode (e.g. HFP) We're also trying to figure out how this would interact with SIM removal / SIM dead events. I've been porting the N900 modem control code to oFono. The semantics of Powered is fine with respect of the atoms, in other words, if the modem crashes and boots itself, all the atoms are flushed nicely. When powering up, the Powered can be set to true when the modem is really up and running. However, then powering modem down, there are problems. The N900 modem control needs to make difference between the state where the modem is no more useful and the safe-to-exit state when the power off request has been completed, modem has flushed its state to flash and given some time to safely turn off the SIM card. Also, if an another SetProperty(Powered) call is made while the driver is powering the modem on or off, the change is ignored. It seems to me that we need more fine grained power control than just the current boolean in the core, too. If you have strong feelings about a particular approach feel free to discuss it here or on IRC. I'll see if I can find my irssi screen... -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Access to SIM card when Modem is not Powered
Pekka Pessi wrote: I've been porting the N900 modem control code to oFono. The semantics of Powered is fine with respect of the atoms, in other words, if the modem crashes and boots itself, all the atoms are flushed nicely. When powering up, the Powered can be set to true when the modem is really up and running. Do you have an overview of the different modes and transitions that the N900 modem control is using today? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Pekka, However, then powering modem down, there are problems. The N900 modem control needs to make difference between the state where the modem is no more useful and the safe-to-exit state when the power off request has been completed, modem has flushed its state to flash and given some time to safely turn off the SIM card. So if I understand correctly, you are saying that once the powered=off request has been sent down to the modem, no other requests are valid. In other words, oFono's current implementation does not remove the atoms until powered=off request succeeds (which might result in those atoms attempting operations), which is wrong. Right? Also, if an another SetProperty(Powered) call is made while the driver is powering the modem on or off, the change is ignored. It seems to me that we need more fine grained power control than just the current boolean in the core, too. We reply with the busy error, you're correct. However, I don't really see anything better we can do here, do you have any suggestions? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Pekka, Hi all, I think the Modem Powered property is meant to control the radios (something like at+cfun=0 vs. at+cfun=1..). Now core automatically removes all the atoms in case modem has Powered false. However, the SIM card should be accessible while the radios are off (cfun=0) so that PIN code could be entered. If the +CFUN=1 is given before PIN code is entered, the modem registers to network in limited service (emergency call only) mode. Perhaps it would be better to let the modem driver itself decide which atoms are active when it is not fully powered? I've been talking about this exact issue with Marcel but so far we have not firmly agreed on any solution. Our current thinking is to keep Powered semantics as they are, but to also add Flight mode property. This would in affect allow interaction with the SIM while the radio is off. For some modems it might not even make sense to support flight mode (e.g. HFP) We're also trying to figure out how this would interact with SIM removal / SIM dead events. If you have strong feelings about a particular approach feel free to discuss it here or on IRC. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
