Access to SIM card when Modem is not "Powered"

Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

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?

-- 
Pekka.Pessi mail at nokia.com

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

Hi denis,

2010/3/19 Denis Kenzior <denkenz@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

RE: Access to SIM card when Modem is not "Powered"

[Bastian, Waldo]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

2010/3/29 Denis Kenzior <denkenz@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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

2010/3/29 Bastian, Waldo <waldo.bastian@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

Re: Access to SIM card when Modem is not "Powered"

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Hi Aki,

> > 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.

why do we need this at all? Can't your kernel driver take care of this?
And obvious second question is why your kernel driver is not integrated
with the RFKILL subsystem?

Regards

Marcel

Re: Access to SIM card when Modem is not "Powered"

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

Hi Denis,

2010/3/30 Denis Kenzior <denkenz@gmail.com>:
>> 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.

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.

-- 
Pekka.Pessi mail at nokia.com

Re: Access to SIM card when Modem is not "Powered"

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Hi Pekka,

> 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().

So I think I finally understood.  What you're trying to achieve is modem 
presence detection / removal.  The equivalent of what udev / modemconf plugins 
do for oFono.  Except that your modem is always present and you need to power 
it up / down.

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:

- Create an oFono plugin to listen to an external daemon and create/destroy 
the modem object appropriately
- Create an oFono plugin that will replace the external daemon and 
create/destroy the modem object appropriately
- Implement this properly in the kernel driver and signal device presence via 
netlink / udev / etc

Regards,
-Denis

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]

2010/3/30 Marcel Holtmann <marcel@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

Re: Access to SIM card when Modem is not "Powered"

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Hi,

2010/3/30 Marcel Holtmann <marcel@holtmann.org>:
>> 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.

RF is controlled using ISI protocol and the PN_MTC service. Like
sending AT+CFUN=1/4 in the ste modem plugin's enable() and disable()
ops.

I suppose we'll do the same, then, too.

Cheers,
Aki

Re: Access to SIM card when Modem is not "Powered"

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

2010/3/30 Denis Kenzior <denkenz@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).

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.

> - Create an oFono plugin to listen to an external daemon and create/destroy
> the modem object appropriately

This is what we were doing previously with N900: sscd would power up
the modem, and we would find out about it via netlink in the isimodem
driver.

> - Create an oFono plugin that will replace the external daemon and
> create/destroy the modem object appropriately

... and this seems like the best way forward here now.

> - Implement this properly in the kernel driver and signal device presence via
> netlink / udev / etc

I don't think this makes sense, really.

Cheers,
Aki

Re: Access to SIM card when Modem is not "Powered"

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 4622 bytes --]

Hi Pekka,

> >> > 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) If the modem reboots, then handle this inside the isimodem plugin of
oFono. No reason to involve userspace here. If the handset gets turned
off, then the modem object just goes away.

2) What do you mean by this. They are asynchronous.

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?

> >> 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.

This is no reason to not integrate Phonet with RFKILL. RFKILL can kill
the radio interface or the whole device. So if it chooses to take the
device off the Phonet "bus", then that is fine as well.

Regards

Marcel

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Hi Aki,

> 2010/3/30 Denis Kenzior <denkenz@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

Re: Access to SIM card when Modem is not "Powered"

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

2010/3/30 Denis Kenzior <denkenz@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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 5809 bytes --]

2010/3/30 Marcel Holtmann <marcel@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?

> This is no reason to not integrate Phonet with RFKILL. RFKILL can kill
> the radio interface or the whole device. So if it chooses to take the
> device off the Phonet "bus", then that is fine as well.

How do you plan to rfkill USB modem with ttyACM*? If you don't, do you
plan to allow ofono application to effectively say AT+CFUN=0 via the
API? Whatever you plan, we can use same mechanism with isimodem.

-- 
Pekka.Pessi mail at nokia.com

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]

Hi Pekka,

> >> 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.

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?

> 
> > 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... 

> >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.

> 
> 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...

> 
> > 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?

> 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?

> 
> > 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 properties we first make sure 
the user can actually use them intelligently,  that there is an actual (not 
just perceived) use case.

Regards,
-Denis

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 5932 bytes --]

Hi Denis,

2010/3/31 Denis Kenzior <denkenz@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 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
out-of-ofono.

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.

-- 
Pekka.Pessi mail at nokia.com

Re: Access to SIM card when Modem is not "Powered"

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

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	

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]

Hi Pekka,

> 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.

So the core exits once modems have been powered down and plugins unloaded.  We 
established that already.  I already considered the powered to false 
immediately semantic and discarded it in favor of the current one.  Please 
present an actual argument / use case why you think powered going immediately 
to false is better than the current implementation.

> 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.)

Register / Deregister refer to something else entirely actually, and the 
modems that do allow Deregister still keep RX/TX circuit on for emergency 
calls.

I think you're expecting oFono to provide more information that it actually 
wants or needs to.  In the end it is up to the modem driver to decide what 
powered off means.  Most simply keep the TX/RX circuits off and the SIM powered 
up, others (like calypso) physically power off the modem.  But even oFono 
doesn't know nor care.

> 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.

You're not helping your case here ;)  Why should oFono care about this use 
case?

In the end I'm fine if you want to implement ofono_modem_unregister that takes 
the modem object off DBus and resets the driver but keeps the attributes 
around.  I know Marcel wanted this anyway for something else.

> You don't seem to handle modem resets at all. Once atdriver gets so
> far, other hardware will benefit, too.

As you mentioned earlier, modem resets are handled by setting the modem 
powered=off then true.  

> 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.
> 

Send a patch with your proposal.  So far I like the idea of disable having a 
hint on whether a shutdown is in progress more than an explicit shutdown 
method.  

Regards,
-Denis

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

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

Re: Access to SIM card when Modem is not "Powered"

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Hi Denis,

2010/4/1 Denis Kenzior <denkenz@gmail.com>:
>> 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.
>
> Send a patch with your proposal.

Attached.

>  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).

-- 
Pekka.Pessi mail at nokia.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Added-ofono_modem_set_ready_to_shutdown-shutdown-met.patch --]
[-- Type: text/x-patch, Size: 3828 bytes --]

From 203c98e8f9932bce3a914b0255f2ad5c92c7bffe Mon Sep 17 00:00:00 2001
From: Pekka Pessi <Pekka.Pessi@nokia.com>
Date: Mon, 12 Apr 2010 17:00:35 +0300
Subject: [PATCH] Added ofono_modem_set_ready_to_shutdown(), shutdown method to driver.

Ensure all modems are ready to shutdown before terminating daemon.
---
 include/modem.h |    5 +++++
 src/modem.c     |   51 ++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/include/modem.h b/include/modem.h
index d502640..cd6bf9e 100644
--- a/include/modem.h
+++ b/include/modem.h
@@ -50,6 +50,8 @@ void ofono_modem_remove(struct ofono_modem *modem);
 void ofono_modem_set_powered(struct ofono_modem *modem, ofono_bool_t powered);
 ofono_bool_t ofono_modem_get_powered(struct ofono_modem *modem);
 
+void ofono_modem_set_ready_to_shutdown(struct ofono_modem *modem);
+
 void ofono_modem_set_name(struct ofono_modem *modem, const char *name);
 
 int ofono_modem_set_string(struct ofono_modem *modem,
@@ -85,6 +87,9 @@ struct ofono_modem_driver {
 
 	/* Populate the atoms that are available with SIM / Unlocked SIM*/
 	void (*post_sim)(struct ofono_modem *modem);
+
+	/* Prepare device for remove */
+	int (*shutdown)(struct ofono_modem *modem);
 };
 
 int ofono_modem_driver_register(const struct ofono_modem_driver *);
diff --git a/src/modem.c b/src/modem.c
index b935328..cb99303 100644
--- a/src/modem.c
+++ b/src/modem.c
@@ -40,7 +40,6 @@ static GSList *g_modem_list = NULL;
 
 static int next_modem_id = 0;
 static gboolean powering_down = FALSE;
-static int modems_remaining = 0;
 
 enum ofono_property_type {
 	OFONO_PROPERTY_TYPE_INVALID = 0,
@@ -59,6 +58,7 @@ struct ofono_modem {
 	guint			interface_update;
 	ofono_bool_t		powered;
 	ofono_bool_t		powered_pending;
+	ofono_bool_t            ready_to_shutdown;
 	guint			timeout;
 	GHashTable		*properties;
 	struct ofono_sim	*sim;
@@ -597,12 +597,8 @@ void ofono_modem_set_powered(struct ofono_modem *modem, ofono_bool_t powered)
 		}
 	}
 
-	if (powering_down && powered == FALSE) {
-		modems_remaining -= 1;
-
-		if (modems_remaining == 0)
-			__ofono_exit();
-	}
+	if (powering_down && powered == FALSE)
+		__ofono_modem_shutdown();
 }
 
 ofono_bool_t ofono_modem_get_powered(struct ofono_modem *modem)
@@ -613,6 +609,14 @@ ofono_bool_t ofono_modem_get_powered(struct ofono_modem *modem)
 	return modem->powered;
 }
 
+void ofono_modem_set_ready_to_shutdown(struct ofono_modem *modem)
+{
+	modem->ready_to_shutdown = TRUE;
+
+	if (powering_down)
+		__ofono_modem_shutdown();
+}
+
 static gboolean trigger_interface_update(void *data)
 {
 	struct ofono_modem *modem = data;
@@ -1298,10 +1302,24 @@ void ofono_modem_driver_unregister(const struct ofono_modem_driver *d)
 	}
 }
 
+static int modem_shutdown(struct ofono_modem *modem)
+{
+	const struct ofono_modem_driver *driver = modem->driver;
+
+	if (driver && driver->shutdown)
+		return driver->shutdown(modem);
+
+	modem->ready_to_shutdown = TRUE;
+	return 0;
+}
+
 void __ofono_modem_shutdown()
 {
 	struct ofono_modem *modem;
 	GSList *l;
+	gboolean already = powering_down;
+	int modems_remaining = 0;
+	int error;
 
 	powering_down = TRUE;
 
@@ -1311,11 +1329,26 @@ void __ofono_modem_shutdown()
 		if (modem->driver == NULL)
 			continue;
 
+		if (already) {
+			if (!modem->ready_to_shutdown)
+				return;
+			if (modem->powered)
+				return;
+			continue;
+		}
+
+		error = modem_shutdown(modem);
+		if (error == -EINPROGRESS) {
+			modems_remaining++;
+			continue;
+		}
+
 		if (modem->powered == FALSE && modem->powered_pending == FALSE)
 			continue;
 
-		if (set_powered(modem, FALSE) == -EINPROGRESS)
-			modems_remaining += 1;
+		error = set_powered(modem, FALSE);
+		if (error == -EINPROGRESS || error == -EALREADY)
+			modems_remaining++;
 	}
 
 	if (modems_remaining == 0)
-- 
1.6.3.3

Re: Access to SIM card when Modem is not "Powered"

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

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