Re: [PATCHv2] plugin: Add ste modem initd integration

[Marcel Holtmann <marcel@holtmann.org>]

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

Hi Sjur,

> > what about potential USB based CAIF devices?
> Good question, but in a Bridge Setup for a phone this will not really
> be devices that come and go.
> I belive it will still be a fixed HW setup where the Modem Init Daemon
> will have static knowledge of the
> USB modems. But I'll discuss this with my coleagues tomorrow.
> In case of true USB dongles the modem should look pretty much
> identical to MBM USB dongles.

I personally would prefer that USB devices just expose CAIF directly.
The whole handling of multiple hardcoded TTY and network interface is
only sub-optimal.

I know it is kinda nice to use standard USB class drivers, but the
flexibility that CAIF actually gives you goes away.

From my point of view, it should be similar to Phonet/ISI over USB. At
least on Linux we have a CAIF subsystem ;)

> >I would just ask to send the property changed signal for the serial
> >number before sending the signal for on/ready.
> It will require a re-design of the state machine in the Modem Init Daemon,
> but I'll check into this tomorrow.
> 
> Here is the latest version of the Dbus API:
> 
> STE Modem Init Deamon Manager
> =============================
> Service		com.stericsson.modeminit
> Interface	com.stericsson.modeminit.ModemManager

Just call it com.stericsson.modeminit.Manager. That gives you the chance
to also include other methods/signals later on if needed.

> Object path	/
> 
> Methods		array{object,dict} GetModems()
> 
> 			Get array of STE Modem objects and their state and
> 			properties (out signature 'a(oa{sv})').
> 
> 			The method should only be call once per application.
> 			Further changes shall be monitored via StateChange
> 			signals.
> 
> STE Modem
> =========
> Service		com.stericsson.modeminit
> Interface	com.stericsson.modeminit.Modem
> Object path	variable
> 
> Signals		PropertyChanged(string property, variant value)
> 
> 			This signal indicates a changed value of the given
> 			property.
> 
> Properties	string State [readonly]
> 
> 			The modems state is dynamic can can have the following
> 			values:
> 			"booting"   Modem is powered up (flashed version)
> 				    or Modem is powered up and firmware upload
> 				    is completed. (flashless version)
> 			"upgrading" Firmware upgrade on going
> 				    or Flashing manager under execution -
> 				    modem in service mode.
> 			"on"	    Modem has booted and is ready for use.
> 				    This implies that all AT channels are
> 				    available, the modem might be in
> 				    e.g. flight mode.
> 				    NOTE: Consider change name to "ready"
> 
> 			"dumping"  Modem has crashed and dump is ongoing
> 			"off"	    Modem is powered off.
> 
> 		string AtInterface[readonly]
> 
> 			CAIF Link Layer interface to be used for
> 			AT channels for a modem.

Why is there an "At" in here? I know that mainly only AT command
channels will be used, but the CAIF interface can be also used to
request debug channels and other things. So I would just call it
Interface only to say what's the interface name is to bind to.

> 		string Serial[optional,readonly]
> 
> 			Serial Number or IMEI for the Modem. The Serial will
> 			not be available until the modem can open an AT channel.

Otherwise, this looks a lot simpler and cleaner.

Regards

Marcel