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. >> 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. Huh? How do you plan to rfkill a modem behind serial line (over bluetooth? over USB? over SSI?)? Should we add a kernel driver for all the modems? How do you plan to solve the interaction between ofonod at commands and the rfkill driver? Phonet is just a glorified serial line with binary protocol. Kernel drivers do not care what is at the other end of that serial line. There are gpio lines to wake up the thing at the end of serial line; gpio lines have their own kernel driver. That is all we need from kernel. -- Pekka.Pessi mail at nokia.com _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
