Andrzej Zaborowski | 1 Jul 04:18 2010
Picon

Re: [PATCH] test-stkutil: Fix always true condition.

On 30 June 2010 14:31, Andrzej Zaborowski <andrew.zaborowski <at> intel.com> wrote:
> ---
>  unit/test-stkutil.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

Please disregard this patch, I'm going to send a new one.  This one
causes the tests to fail.

Best regards
_______________________________________________
ofono mailing list
ofono <at> ofono.org
http://lists.ofono.org/listinfo/ofono
Zhang, Zhenhua | 1 Jul 07:42 2010
Picon

RE: Crash in at_gprs_context_remove()

Hi Kalle,

Kalle Valo wrote:
> Hi,
> 
> (gdb) bt
> #0  0x00007ffff790b642 in IA__g_atomic_int_exchange_and_add
>    (atomic=0x0, val=-1) at
> /build/buildd/glib2.0-2.25.8/glib/gatomic-gcc.c:30 #1 
> 0x00000000004325a3 in g_at_ppp_unref (ppp=0x0) at
>    gatchat/gatppp.c:448 #2  0x0000000000448e12 in
> at_gprs_context_remove (gc=0x6e2f50) at
> drivers/atmodem/gprs-context.c:260 #3  0x00000000004923c9 in

As Denis has pointed out, we can add a check for gcd->ppp in at_gprs_context_remove() to avoid this crash.

When I tried to activate & deactivate context on my Huawei EM770W modem, I see kernel module usb_serial warning.

------------[ cut here ]------------
WARNING: at /build/buildd/linux-2.6.31/drivers/usb/serial/usb-serial.c:460
serial_ioctl+0x99/0xa0 [usbserial]()
Hardware name: 7661BL4
Modules linked in: tun option usbserial usb_storage hidp aes_i586 aes_generic ppdev binfmt_misc bridge
stp bnep btusb joydev snd_hda_codec_analog pcmcia snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb snd_seq_dummy uvcvideo videodev v4l1_compat snd_seq_oss
yenta_socket rsrc_nonstatic ricoh_mmc pcmcia_core iwlagn iwlcore mac80211 sdhci_pci sdhci psmouse
serio_raw snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211
thinkpad_acpi led_class nvram snd soundcore snd_page_alloc heci(C) lp parport usbhid dm_raid45 xor
fbcon tileblit font bitblit softcursor ohci1394 e1000e ieee1394 i915 drm i2c_algo_bit video output
intel_agp agpgart
(Continue reading)

Zhang, Caiwen | 1 Jul 11:52 2010

How about offering a raw way for SMS

Hi all,

Ofono stack encodes SMS before send it.  User may need send some special SMS. Such as send a v-card via SMS.

It need to add user data header to indicate it is a v-card. Ofono currently does not support this feature. How about

offering an API for user to sending raw PDU directly?  such as:

         void SendRawMessage(string pdu)

So,  user can encode it by himself and send the PDU. It can also applied to sending message with validity period/status report

requirement and so on.

 

Similarly,  how about sending out the raw PDU when dispatch incoming message?  There are many kinds of

SMS, such as voice mail notification, MMS notification, push mail notification etc.  How about sending out the raw

PDU to upper layer and depending on upper layer to decode and decide how to process it?

 

Thanks,

Caiwen





<div>
<p>Hi all,</p>
<p>Ofono stack encodes SMS before send 
it.&nbsp; User may need send some special SMS. Such as send a v-card via SMS. 
</p>
<p>It need to add user data header to 
indicate&nbsp;it is a v-card. Ofono currently 
does not support this feature. How about </p>
<p>offering an API for user to sending 
raw PDU directly?&nbsp; 
such as:</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;void SendRawMessage(string pdu)</p>
<p>So,&nbsp; user can encode it by himself and send the PDU. It can 
also applied to sending message with validity period/status report 
</p>
<p>requirement and so on.</p>
<p>&nbsp;</p>
<p>Similarly,&nbsp; how about sending out the raw PDU 
when&nbsp;dispatch&nbsp;incoming&nbsp;message?&nbsp; There are many kinds 
of</p>
<p>SMS, such as voice mail notification, MMS notification, 
push mail notification etc.&nbsp; How about sending out the raw </p>
<p>PDU to upper layer and depending on upper layer to decode 
and decide how to process it? </p>
<p>&nbsp;</p>
<p>Thanks,</p>
<p>Caiwen<br><br><br><br><br><br></p>
</div>
Marcel Holtmann | 1 Jul 12:01 2010

Re: How about offering a raw way for SMS

Hi Caiwen,

please don't piggy-back on other threads. For new questions/discussion,
please start a brand new thread.

> Ofono stack encodes SMS before send it.  User may need send some
> special SMS. Such as send a v-card via SMS. 
> 
> It need to add user data header to indicate it is a v-card. Ofono
> currently does not support this feature. How about 
> 
> offering an API for user to sending raw PDU directly?  such as:
> 
>          void SendRawMessage(string pdu)
> 
> So,  user can encode it by himself and send the PDU. It can also
> applied to sending message with validity period/status report 
> 
> requirement and so on.
> 
>  
> 
> Similarly,  how about sending out the raw PDU
> when dispatch incoming message?  There are many kinds of
> 
> SMS, such as voice mail notification, MMS notification, push mail
> notification etc.  How about sending out the raw 
> 
> PDU to upper layer and depending on upper layer to decode and decide
> how to process it? 

this is exactly what we NOT wanna do. There will be one entity that does
PDU encoding and decoding and this will be oFono. The reason behind this
is that keeping copies of PDU encoder/decoder around in every single
application is pretty much a really bad idea. We want it in one central
place with a large set of unit tests and proper long term testing. This
helps improving quality and ensures security and stability.

Having upper layers dealing with raw PDU is a design mistake that has
been made in the past way too many times. And this stops with oFono now.

So if you wanna send vCards or something similar, then you need to
extend oFono with interfaces to send vCards. Same goes for receiving
functionality.

Regards

Marcel

Zhang, Zhenhua | 1 Jul 15:41 2010
Picon

RE: Crash in at_gprs_context_remove()

Hi,

Zhang, Zhenhua wrote:
> Hi Kalle,
> 
> Kalle Valo wrote:
>> Hi,
>> 
>> (gdb) bt
>> #0  0x00007ffff790b642 in IA__g_atomic_int_exchange_and_add   
>> (atomic=0x0, val=-1) at
>> /build/buildd/glib2.0-2.25.8/glib/gatomic-gcc.c:30 #1
>>    0x00000000004325a3 in g_at_ppp_unref (ppp=0x0) at
>> gatchat/gatppp.c:448 #2  0x0000000000448e12 in
>> at_gprs_context_remove (gc=0x6e2f50) at
>> drivers/atmodem/gprs-context.c:260 #3  0x00000000004923c9 in 
> 
> As Denis has pointed out, we can add a check for gcd->ppp in
> at_gprs_context_remove() to avoid this crash.
> 
> When I tried to activate & deactivate context on my Huawei
> EM770W modem, I see kernel module usb_serial warning.
> 
> ------------[ cut here ]------------
> WARNING: at
> /build/buildd/linux-2.6.31/drivers/usb/serial/usb-serial.c:460
> serial_ioctl+0x99/0xa0 [usbserial]()
> Hardware name: 7661BL4
> Modules linked in: tun option usbserial usb_storage hidp
> aes_i586 aes_generic ppdev binfmt_misc bridge stp bnep btusb
> joydev snd_hda_codec_analog pcmcia snd_hda_intel snd_hda_codec
> snd_hwdep snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb
> snd_seq_dummy uvcvideo videodev v4l1_compat snd_seq_oss
> yenta_socket rsrc_nonstatic ricoh_mmc pcmcia_core iwlagn
> iwlcore mac80211 sdhci_pci sdhci psmouse serio_raw
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device cfg80211 thinkpad_acpi led_class nvram snd
> soundcore snd_page_alloc heci(C) lp parport usbhid dm_raid45
> xor fbcon tileblit font bitblit softcursor ohci1394 e1000e
> ieee1394 i915 drm i2c_algo_bit video output intel_agp agpgart
> Pid: 5180, comm: ofonod Tainted: G         C 2.6.31-16-generic
> #53-Ubuntu Call Trace:
> [<c014518d>] warn_slowpath_common+0x6d/0xa0
> [<fa3ab689>] ? serial_ioctl+0x99/0xa0 [usbserial]
> [<fa3ab689>] ? serial_ioctl+0x99/0xa0 [usbserial]
> [<c01451d5>] warn_slowpath_null+0x15/0x20
> [<fa3ab689>] serial_ioctl+0x99/0xa0 [usbserial]
> [<c0386414>] ? tty_buffer_flush+0x54/0xe0
> [<fa3ab5f0>] ? serial_ioctl+0x0/0xa0 [usbserial]
> [<c03801b7>] tty_ioctl+0x77/0x620
> [<c0380140>] ? tty_ioctl+0x0/0x620
> [<c01f518c>] vfs_ioctl+0x1c/0x90
> [<c01f0726>] ? putname+0x26/0x40
> [<c01f54b1>] do_vfs_ioctl+0x71/0x310
> [<c01f57af>] sys_ioctl+0x5f/0x80
> [<c01e5939>] ? sys_open+0x29/0x40
> [<c010336c>] syscall_call+0x7/0xb
> ---[ end trace ac231b55ebb1fdca ]---
> 
> When I shutdown the oFono, kernel reports:
> 	tty_port_close_start: tty->count = 1 port count = 0.
> 
> Any ideas?

I observed the warning shows up when /dev/ttyUSB2 send us any intermediate result. If I remove gprs atom and
recreate it in huawei_disconnect, the kernel warning is gone. Does anyone see the same problem in other
Huawei modem? If not, I assume it's a problem only for EM770 modem. (I don't have other Huawei modem at hand)

Thanks,
Zhenhua

>> 
>> --
>> Kalle Valo
>> _______________________________________________
>> ofono mailing list
>> ofono@...
>> http://lists.ofono.org/listinfo/ofono
> 
> 
> 
> Regards,
> Zhenhua

Regards,
Zhenhua

Denis Kenzior | 1 Jul 16:00 2010
Picon

Re: [PATCH 3/5] test-server: Add PPP server support

Hi Zhenhua,

>> static void server_destroy(gpointer user)
>>  <at>  <at>  -706,15 +825,11  <at>  <at>  static void server_destroy(gpointer user)
>>
>> static void set_raw_mode(int fd)
>> {
>> -	struct termios options;
>> -
>> -	tcgetattr(fd,&options);
>> -
>> -	/* Set TTY as raw mode to disable echo back of input characters
>> -	 * when they are received from Modem to avoid feedback loop */
>> -	options.c_lflag&= ~(ICANON | ECHO | ECHOE | ISIG); +	struct
>> termios ti;
>>
>> -	tcsetattr(fd, TCSANOW,&options);
>> +	tcflush(fd, TCIOFLUSH);
>> +	cfmakeraw(&ti);
>> +	tcsetattr(fd, TCSANOW,&ti);
>> }
>>
>> static gboolean create_tty(const char *modem_path)
>
> I found above changes does not contain latest git tree. The part of change is necessary when I tried to use
bluetooth serial proxy between two machines. Without cfmakeraw, the server responses:
> 	'\r\nOK\r\n'
> would change to:
> 	'\n\nOK\n\n'
>
> And this issue doesn't exist if both server and client on the same machine.

The above code was causing valgrind to complain, so I left it out, 
apologies for not mentioning it, had a bit of a filesystem disaster 
happen after I pushed :)

The present code seems to be completely in line with man cfmakeraw.  The 
cause is probably more subtle or has to do with the RFCOMM tty layer in 
the kernel.  Could you please investigate some more?

Regards,
-Denis
Denis Kenzior | 1 Jul 16:52 2010
Picon

Re: [PATCH] Voicecall gaps.

On 06/30/2010 08:01 AM, Pekka.Pessi@... wrote:
> From: Pekka Pessi<Pekka.Pessi@...>
>
> Missing voicecall functionality pieces from tp-ring point-of-view.
> ---
>   TODO |   27 +++++++++++++++++++++++++++
>   1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/TODO b/TODO
> index 470d4a6..e6ef20d 100644
> --- a/TODO
> +++ b/TODO
>  <at>  <at>  -265,6 +265,33  <at>  <at>  Supplementary Services
>     Complexity: C8
>
>
> +Voicecall
> +=========
> +
> +- Supplementary service notifications for remote party putting call on hold
> +  or retrieving the call or joining call to a multiparty conference.
> +
> +  Priority: Medium
> +  Complexity: C1
> +  Owner: Pekka Pessi<pekka.pessi@...>

Is this in any way related to the present ssn atom?  If it is, then you 
might want to mention this in a bit more detail here.  And are you sure 
this is a C1 task?  Considering the API changes involved, I doubt this 
is a C1 task.

> +
> +- Dial strings. Include CLIR prefixes and 2nd stage dial strings in call history.
> +
> +  Priority: Medium
> +  Complexity: C2
> +
> +- Start DTMF, Stop DTMF, feedback of sent DTMF tones.
> +
> +  Priority: Medium
> +  Complexity: C2

In general if a task is of lower complexity (e.g. C1 or C2) I'd really 
like a short description of the proposed solution in the task overview. 
  In the above two cases I'm really curious how you will manage to do 
this, in particular since AT commands do not support starting / stopping 
DTMF tones.

Please include a short strategy description or increase the complexity.

> +
> +- Add atom for assisting in local supervisory tone generation when modem
> +  does include tones in media streams.
> +
> +  Priority: Medium
> +  Complexity: C2
> +
> +

Please hold off on this one, I'm really not convinced this belongs in 
oFono just yet.

Regards,
-Denis
Marcel Holtmann | 1 Jul 17:07 2010

Re: [PATCH 2/3] huawei: Add Huawei EM770 modem support

Hi Zhenhua Zhang,

> Huawei EM770W is a 3G WCDMA modem that supports HSPA/UMTS/EDGE/GPRS/GSM
> data service and WCDMA/GSM short message services. It also has voice
> call capability that supports both 2G and 3G network.
> ---
>  plugins/huawei.c    |   31 ++++++++++++++++++++++++++++++-
>  plugins/ofono.rules |    3 +++
>  plugins/udev.c      |    3 +++
>  3 files changed, 36 insertions(+), 1 deletions(-)
> 
> diff --git a/plugins/huawei.c b/plugins/huawei.c
> index e2dfd1e..0dc6ae4 100644
> --- a/plugins/huawei.c
> +++ b/plugins/huawei.c
>  <at>  <at>  -43,13 +43,24  <at>  <at> 
>  #include <ofono/gprs.h>
>  #include <ofono/gprs.h>
>  #include <ofono/gprs-context.h>
> +#include <ofono/voicecall.h>
> +#include <ofono/call-forwarding.h>
> +#include <ofono/call-settings.h>
> +#include <ofono/call-meter.h>
> +#include <ofono/call-barring.h>
> +#include <ofono/ssn.h>
> +#include <ofono/phonebook.h>
> +#include <ofono/message-waiting.h>
>  #include <ofono/log.h>
>  
>  #include <drivers/atmodem/atutil.h>
>  #include <drivers/atmodem/vendor.h>
>  
> +#define HUAWEI_MODEL_EM770W "1404"
> +
>  static const char *none_prefix[] = { NULL };
>  static const char *sysinfo_prefix[] = { "^SYSINFO:", NULL };
> +static const char *model = "";
>  
>  struct huawei_data {
>  	GAtChat *modem;
>  <at>  <at>  -205,8 +216,9  <at>  <at>  static int huawei_enable(struct ofono_modem *modem)
>  
>  	modem_device = ofono_modem_get_string(modem, "Modem");
>  	pcui_device = ofono_modem_get_string(modem, "Pcui");
> +	model = ofono_modem_get_string(modem, "Model");
>  
> -	if (modem_device == NULL || pcui_device == NULL)
> +	if (modem_device == NULL || pcui_device == NULL || model == NULL)
>  		return -EINVAL;
>  
>  	data->modem = create_port(modem_device);
>  <at>  <at>  -288,6 +300,9  <at>  <at>  static void huawei_pre_sim(struct ofono_modem *modem)
>  
>  	ofono_devinfo_create(modem, 0, "atmodem", data->pcui);
>  	data->sim = ofono_sim_create(modem, 0, "atmodem", data->pcui);
> +
> +	if (g_str_equal(model, HUAWEI_MODEL_EM770W))
> +		ofono_voicecall_create(modem, 0, "atmodem", data->pcui);
>  }
>  
>  static void huawei_post_sim(struct ofono_modem *modem)
>  <at>  <at>  -296,6 +311,7  <at>  <at>  static void huawei_post_sim(struct ofono_modem *modem)
>  	struct ofono_gprs_context *gc;
>  	struct ofono_netreg *netreg;
>  	struct ofono_gprs *gprs;
> +	struct ofono_message_waiting *mw;
>  
>  	DBG("%p", modem);
>  
>  <at>  <at>  -312,6 +328,19  <at>  <at>  static void huawei_post_sim(struct ofono_modem *modem)
>  
>  	if (gprs && gc)
>  		ofono_gprs_add_context(gprs, gc);
> +
> +	if (g_str_equal(model, HUAWEI_MODEL_EM770W)) {
> +		ofono_call_forwarding_create(modem, 0, "atmodem", data->pcui);
> +		ofono_call_settings_create(modem, 0, "atmodem", data->pcui);
> +		ofono_call_meter_create(modem, 0, "atmodem", data->pcui);
> +		ofono_call_barring_create(modem, 0, "atmodem", data->pcui);
> +		ofono_ssn_create(modem, 0, "atmodem", data->pcui);
> +		ofono_phonebook_create(modem, 0, "atmodem", data->pcui);
> +
> +		mw = ofono_message_waiting_create(modem);
> +		if (mw)
> +			ofono_message_waiting_register(mw);
> +	}
>  }
>  
>  static struct ofono_modem_driver huawei_driver = {
> diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> index 06c5c8f..3541833 100644
> --- a/plugins/ofono.rules
> +++ b/plugins/ofono.rules
>  <at>  <at>  -24,6 +24,9  <at>  <at>  ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1401",
ENV{OFONO_IFACE_NUM}=="02", E
>  ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1402", ENV{OFONO_IFACE_NUM}=="00", ENV{OFONO_HUAWEI_TYPE}="Modem"
>  ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1402", ENV{OFONO_IFACE_NUM}=="02", ENV{OFONO_HUAWEI_TYPE}="Pcui"
>  
> +ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1404", ENV{OFONO_IFACE_NUM}=="00", ENV{OFONO_HUAWEI_TYPE}="Modem"
> +ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1404", ENV{OFONO_IFACE_NUM}=="02", ENV{OFONO_HUAWEI_TYPE}="Pcui"
> +
>  ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1405", ENV{OFONO_IFACE_NUM}=="03", ENV{OFONO_HUAWEI_TYPE}="Modem"
>  ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1405", ENV{OFONO_IFACE_NUM}=="00", ENV{OFONO_HUAWEI_TYPE}="Pcui"
>  
> diff --git a/plugins/udev.c b/plugins/udev.c
> index 09ee93e..7d34b0b 100644
> --- a/plugins/udev.c
> +++ b/plugins/udev.c
>  <at>  <at>  -227,6 +227,9  <at>  <at>  static void add_huawei(struct ofono_modem *modem,
>  		const char *name = udev_list_entry_get_name(entry);
>  		type = udev_list_entry_get_value(entry);
>  
> +		if (g_str_equal(name, "ID_MODEL_ID") == TRUE)
> +			ofono_modem_set_string(modem, "Model", type);
> +

so this is the part that I don't like. I prefer we have some udev rules
that create OFONO_HUAWEI_VOICE=1 and we use that as indicator to enable
voice capabilities or not.

Regards

Marcel

Marcel Holtmann | 1 Jul 17:07 2010

Re: [PATCH 3/3] huawei: Remove call meter support for EM770

Hi Zhenhua,

> EM770W returns "COMMAND NOT SUPPORT" when we send "AT+CCWE=1" to
> initialize call meter atom. So disable it.

when re-doing patch 2/3 then please fix this properly so that this extra
patch is not needed anymore.

Regards

Marcel

Denis Kenzior | 1 Jul 18:30 2010
Picon

Re: [PATCH 1/3] stkutil: display text attributes as html

Hi Kristen,

> +
> +char *stk_text_to_html(char *text, int text_len,
> +				const unsigned char *attrs, int attrs_len)
> +{
> +	GString *string = g_string_sized_new(text_len + 1);
> +	int formats[257];  /* maximum number of chars in text + 1 */
> +	int pos = 0, i, j, attr, prev_attr;
> +	guint8 start, end, code, color, len, align;
> +
> +	/* we will need formatting at the position beyond the last char */
> +	for (i = 0; i <= text_len; i++)
> +		formats[i] = STK_TEXT_FORMAT_INIT;
> +

Please note that the same formatting can be used for EMS messages
(23.040).  These messages have a fairly large max-len (255 segments *
~153 characters)  I'd like to have this function useable for EMS
messages as well.

> +	i = 0;
> +
> +	while (i < attrs_len) {

Using a for loop would be nicer here

> +		start = attrs[i++];
> +		len = attrs[i++];
> +		code = attrs[i++];

You might want to be extra paranoid here that attrs_len is a multiple of 4.

> +
> +		if (i < attrs_len)
> +			color = attrs[i++];
> +		else
> +			color = 0;
> +
> +		if (len == 0)
> +			end = text_len;
> +		else
> +			end = start + len;
> +
> +		/* sanity check values */
> +		if (start > end || end > text_len)
> +			continue;
> +
> +		/*
> +		 * if the alignment is the same as either the default
> +		 * or the last alignment used, don't set any alignment
> +		 * value.
> +		 */
> +		if (start == 0)
> +			align = STK_DEFAULT_TEXT_ALIGNMENT;

Are attributes which do not contain start = 0 valid?  If so, you might
take extra care here.

> +		else {
> +			align = (formats[start -1] & 0xFF) &
> +					STK_TEXT_FORMAT_ALIGN_MASK;
> +			if (align == STK_TEXT_FORMAT_NO_ALIGN)
> +				align = STK_DEFAULT_TEXT_ALIGNMENT;
> +		}
> +
> +		if ((code & STK_TEXT_FORMAT_ALIGN_MASK) == align)
> +			code |= STK_TEXT_FORMAT_NO_ALIGN;
> +
> +		attr = code | (color << 8);
> +
> +		for (j = start; j < end; j++)
> +			formats[j] = attr;
> +	}
> +
> +	prev_attr = STK_TEXT_FORMAT_INIT;
> +
> +	while (pos <= text_len) {

A for loop would be more readable here in my opinion

> +		attr = formats[pos];
> +		if (attr != prev_attr) {
> +			if (prev_attr != STK_TEXT_FORMAT_INIT)
> +				end_format(string, prev_attr & 0xFF);
> +
> +			if (attr != STK_TEXT_FORMAT_INIT)
> +				start_format(string, attr & 0xFF,
> +							(attr >> 8) & 0xFF);
> +
> +			prev_attr = attr;
> +		}
> +
> +		if (pos == text_len)
> +			break;
> +
> +		switch (text[pos]) {
> +		case '\n':
> +			g_string_append(string, "<br/>");
> +			break;
> +		case '\r':
> +		{
> +			g_string_append(string, "<br/>");
> +			if ((pos + 1 < text_len) && (text[pos + 1] == '\n'))
> +				pos++;
> +		}

Fallthrough on purpose?

> +		case '<':
> +			g_string_append(string, "&lt;");
> +			break;
> +		case '>':
> +			g_string_append(string, "&gt;");
> +			break;
> +		case '&':
> +			g_string_append(string, "&amp;");
> +			break;
> +		default:
> +			g_string_append_c(string, text[pos]);
> +		}
> +		pos++;
> +	}
> +
> +	/* return characters from string. Caller must free char data */
> +	return g_string_free(string, FALSE);
> +}
> diff --git a/src/stkutil.h b/src/stkutil.h
> index ca4817e..5b3a679 100644
> --- a/src/stkutil.h
> +++ b/src/stkutil.h
>  <at>  <at>  -1635,6 +1635,27  <at>  <at>  struct stk_envelope {
>  	};
>  };
>  
> +#define STK_TEXT_FORMAT_ALIGN_MASK 0x03
> +#define STK_TEXT_FORMAT_FONT_MASK 0x0C
> +#define STK_TEXT_FORMAT_STYLE_MASK 0xF0
> +#define STK_DEFAULT_TEXT_ALIGNMENT 0x00
> +#define STK_TEXT_FORMAT_INIT -1
> +
> +/* Defined in ETSI 123 40 9.2.3.24.10.1.1 */
> +enum stk_text_format_code {
> +	STK_TEXT_FORMAT_LEFT_ALIGN = 0x00,
> +	STK_TEXT_FORMAT_CENTER_ALIGN = 0x01,
> +	STK_TEXT_FORMAT_RIGHT_ALIGN = 0x02,
> +	STK_TEXT_FORMAT_NO_ALIGN = 0x03,
> +	STK_TEXT_FORMAT_FONT_SIZE_LARGE = 0x04,
> +	STK_TEXT_FORMAT_FONT_SIZE_SMALL = 0x08,
> +	STK_TEXT_FORMAT_FONT_SIZE_RESERVED = 0x0c,
> +	STK_TEXT_FORMAT_STYLE_BOLD = 0x10,
> +	STK_TEXT_FORMAT_STYLE_ITALIC = 0x20,
> +	STK_TEXT_FORMAT_STYLE_UNDERLINED = 0x40,
> +	STK_TEXT_FORMAT_STYLE_STRIKETHROUGH = 0x80,
> +};
> +

All of these enums really belong in the .c file.  There is no other
client which can make use of them.

>  struct stk_command *stk_command_new_from_pdu(const unsigned char *pdu,
>  						unsigned int len);
>  void stk_command_free(struct stk_command *command);
>  <at>  <at>  -1643,3 +1664,5  <at>  <at>  const unsigned char *stk_pdu_from_response(const struct stk_response *response,
>  						unsigned int *out_length);
>  const unsigned char *stk_pdu_from_envelope(const struct stk_envelope *envelope,
>  						unsigned int *out_length);
> +char *stk_text_to_html(char *text, int text_len,
> +				const unsigned char *attrs, int attrs_len);

Why not const char *text?

Regards,
-Denis

Gmane