From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: Access to SIM card when Modem is not "Powered"
Date: Tue, 30 Mar 2010 08:45:02 -0700 [thread overview]
Message-ID: <1269963903.11714.254.camel@localhost.localdomain> (raw)
In-Reply-To: <80fd4e751003300834t57552977r2355e01810ff8964@mail.gmail.com>
[-- 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
next prev parent reply other threads:[~2010-03-30 15:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-19 17:24 Access to SIM card when Modem is not "Powered" Pekka Pessi
2010-03-19 18:18 ` Denis Kenzior
2010-03-29 18:29 ` Pekka Pessi
2010-03-29 18:40 ` Bastian, Waldo
2010-03-30 11:39 ` Pekka Pessi
2010-03-30 14:22 ` Marcel Holtmann
2010-03-29 18:53 ` Denis Kenzior
2010-03-30 11:36 ` Pekka Pessi
2010-03-30 4:50 ` Denis Kenzior
2010-03-30 15:34 ` Pekka Pessi
2010-03-30 15:45 ` Marcel Holtmann [this message]
2010-03-30 16:40 ` Pekka Pessi
2010-03-30 18:02 ` Marcel Holtmann
2010-03-30 22:55 ` Pekka Pessi
2010-03-30 23:24 ` Denis Kenzior
2010-04-01 9:14 ` Pekka Pessi
2010-04-01 12:44 ` Aki Niemi
2010-04-01 15:09 ` Denis Kenzior
2010-04-01 15:07 ` Denis Kenzior
2010-04-12 14:08 ` Pekka Pessi
2010-04-15 21:54 ` Denis Kenzior
2010-03-30 17:26 ` Aki Niemi
2010-03-30 16:13 ` Denis Kenzior
2010-03-30 17:37 ` Aki Niemi
2010-03-30 18:05 ` Denis Kenzior
2010-03-30 18:27 ` Aki Niemi
2010-03-30 11:57 ` Aki Niemi
2010-03-30 14:19 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1269963903.11714.254.camel@localhost.localdomain \
--to=marcel@holtmann.org \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox