2010/3/31 Denis Kenzior <denkenz(a)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
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
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
> 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
> > 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
That sounds sensible.
> With the current ofono core, removing the object path will also
> 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
> 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
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
> (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
> > 3) I don't understand this. We have pre-sim and post-sim
> > 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 properties we first make sure
the user can actually use them intelligently, that there is an actual (not
just perceived) use case.
In principle, the current D-Bus API is ok. It could be useful to
indicate the reason why modem cannot be Powered (fatal sw or hw
failure, selftest failure) but that might be better communicated
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
Pekka.Pessi mail at nokia.com