[PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Florian Steinel]

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

---
 plugins/ofono.rules |   15 +++++++++++
 plugins/udev.c      |   70 ++++++++++++++++++++++-----------------------------
 2 files changed, 45 insertions(+), 40 deletions(-)

diff --git a/plugins/ofono.rules b/plugins/ofono.rules
index 0575362..abae06a 100644
--- a/plugins/ofono.rules
+++ b/plugins/ofono.rules
@@ -1,11 +1,26 @@
 # do not edit this file, it will be overwritten on update
 
 ACTION!="add|change", GOTO="ofono_end"
+
+SUBSYSTEM!="tty", GOTO="ofono_typ_end"
+KERNEL!="ttyUSB[0-9]*", GOTO="ofono_typ_end"
+
+# HUAWEI E176
+ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="00", ENV{OFONO_TYP}="PRIMARY"
+ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="01", ENV{OFONO_TYP}="SECONDARY"
+# HUAWEI E1552
+# TODO: Add ID_MODEL_ID aka idProduct for E1552
+#ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="00", ENV{OFONO_TYP}="PRIMARY"
+#ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="02", ENV{OFONO_TYP}="SECONDARY"
+
+LABEL="ofono_typ_end"
+
 SUBSYSTEM!="usb", GOTO="ofono_end"
 ENV{DEVTYPE}!="usb_device", GOTO="ofono_end"
 
 # HUAWEI Technology
 ATTRS{idVendor}=="12d1", ENV{OFONO_DRIVER}="huawei"
+# HUAWEI EM770
 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1404", ENV{OFONO_DRIVER}="em770"
 
 # Novatel Wireless
diff --git a/plugins/udev.c b/plugins/udev.c
index bdac4fd..d52a758 100644
--- a/plugins/udev.c
+++ b/plugins/udev.c
@@ -89,24 +89,6 @@ static const char *get_serial(struct udev_device *udev_device)
 	return serial;
 }
 
-static const char *get_usb_num(struct udev_device *udev_device)
-{
-	struct udev_list_entry *entry;
-	const char *num = NULL;
-
-	entry = udev_device_get_properties_list_entry(udev_device);
-	while (entry) {
-		const char *name = udev_list_entry_get_name(entry);
-
-		if (g_strcmp0(name, "ID_USB_INTERFACE_NUM") == 0)
-			num = udev_list_entry_get_value(entry);
-
-		entry = udev_list_entry_get_next(entry);
-	}
-
-	return num;
-}
-
 #define MODEM_DEVICE		"ModemDevice"
 #define DATA_DEVICE		"DataDevice"
 #define GPS_DEVICE		"GPSDevice"
@@ -219,7 +201,8 @@ static void add_hso(struct ofono_modem *modem,
 static void add_huawei(struct ofono_modem *modem,
 					struct udev_device *udev_device)
 {
-	const char *devnode, *num;
+	struct udev_list_entry *entry;
+	const char *devnode, *serial_typ = NULL;
 	int primary, secondary;
 
 	primary = ofono_modem_get_integer(modem, "PrimaryRegistered");
@@ -228,32 +211,39 @@ static void add_huawei(struct ofono_modem *modem,
 	if (primary && secondary)
 		return;
 
-	num = get_usb_num(udev_device);
+	entry = udev_device_get_properties_list_entry(udev_device);
+	while (entry) {
+		const char *name = udev_list_entry_get_name(entry);
 
-	/*
-	 * Here is is assumed that that usb port number 0 is the control
-	 * port and port 2 is the event port. This assumption will surely
-	 * be false with some devices and better heuristics is needed.
-	 */
-	if (g_strcmp0(num, "00") == 0) {
-		if (primary != 0)
-			return;
+		if (g_strcmp0(name, "OFONO_TYP") == 0) {
+			serial_typ = udev_list_entry_get_value(entry);
 
-		devnode = udev_device_get_devnode(udev_device);
-		ofono_modem_set_string(modem, "Device", devnode);
+			if (g_strcmp0(serial_typ, "PRIMARY") == 0) {
+				if (primary != 0)
+					return;
 
-		primary = 1;
-		ofono_modem_set_integer(modem, "PrimaryRegistered", primary);
-	} else if (g_strcmp0(num, "02") == 0) {
-		if (secondary != 0)
-			return;
+				devnode = udev_device_get_devnode(udev_device);
+				ofono_modem_set_string(modem, "Device", devnode);
 
-		devnode = udev_device_get_devnode(udev_device);
-		ofono_modem_set_string(modem, "SecondaryDevice", devnode);
+				primary = 1;
+				ofono_modem_set_integer(modem, "PrimaryRegistered", primary);
+			}
+
+			if (g_strcmp0(serial_typ, "SECONDARY") == 0) {
+				if (secondary != 0)
+					return;
+
+				devnode = udev_device_get_devnode(udev_device);
+				ofono_modem_set_string(modem, "SecondaryDevice", devnode);
+
+				secondary = 1;
+				ofono_modem_set_integer(modem, "SecondaryRegistered",
+							secondary);
+			}
 
-		secondary = 1;
-		ofono_modem_set_integer(modem, "SecondaryRegistered",
-					secondary);
+		}
+
+		entry = udev_list_entry_get_next(entry);
 	}
 
 	if (primary && secondary)
-- 
1.6.4.4

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Kalle Valo]

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

Hi Florian,

thank you for the patch.

I'm curious, did you test ofono with Huawei E176? Did it work? Did you
have any problems?

Florian Steinel <Florian.Steinel@gmail.com> writes:

> diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> index 0575362..abae06a 100644
> --- a/plugins/ofono.rules
> +++ b/plugins/ofono.rules
> @@ -1,11 +1,26 @@
>  # do not edit this file, it will be overwritten on update
>  
>  ACTION!="add|change", GOTO="ofono_end"
> +
> +SUBSYSTEM!="tty", GOTO="ofono_typ_end"
> +KERNEL!="ttyUSB[0-9]*", GOTO="ofono_typ_end"
> +
> +# HUAWEI E176
> +ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="00", ENV{OFONO_TYP}="PRIMARY"
> +ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="01", ENV{OFONO_TYP}="SECONDARY"
>
> +# HUAWEI E1552
> +# TODO: Add ID_MODEL_ID aka idProduct for E1552
> +#ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="00", ENV{OFONO_TYP}="PRIMARY"
> +#ENV{ID_VENDOR_ID}=="12d1", ENV{ID_MODEL_ID}=="1003", ENV{ID_IFACE}=="02", ENV{OFONO_TYP}="SECONDARY"
> +
> +LABEL="ofono_typ_end"

I think adding usb ids to the rules file for each Huawei product is a
maintenance problem. There are so many devices out there, that handling
the usb ids for all of them is difficult.

I personally would prefer a solution which would dynamically probe the
ports and choose them based on results. I believe modemmanager does
something like this, but I haven't looked in detail.

But Denis and Marcel should comment here, they know best.

-- 
Kalle Valo

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Marcel Holtmann]

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

Hi Kalle,

> I personally would prefer a solution which would dynamically probe the
> ports and choose them based on results. I believe modemmanager does
> something like this, but I haven't looked in detail.

we should do something like auto-detect at some point, but there are
limits in it.

Regards

Marcel

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Kalle Valo]

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

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Kalle,

Hallo Marcel,

>> I personally would prefer a solution which would dynamically probe the
>> ports and choose them based on results. I believe modemmanager does
>> something like this, but I haven't looked in detail.
>
> we should do something like auto-detect at some point, but there are
> limits in it.

So what's the best option to go forward?

And related to this, can we rely on the port numbering order provided by
udev? For example, on my Huawei E1552 port 0 is the main chat port and
port 2 is the "event" port. Is it certain that port numbering will be
the same across all distributions and kernels?

-- 
Kalle Valo

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Daniel Oliveira Nascimento]

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

I was testing this driver with Huawei E220 modem. Here it appears in port 1 
too. I just patched ofono with the following patch and it works. But I don't 
have a modem that appears in port 2 to test. In ModemManager [1] seems that 
they try to detect the second device in functions supports_device and 
probe_second_timeout, and it seems to be the best approach here too.

[1] http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/mm-
plugin-huawei.c

---
 plugins/udev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/plugins/udev.c b/plugins/udev.c
index bdac4fd..fd67583 100644
--- a/plugins/udev.c
+++ b/plugins/udev.c
@@ -244,7 +244,7 @@ static void add_huawei(struct ofono_modem *modem,
 
 		primary = 1;
 		ofono_modem_set_integer(modem, "PrimaryRegistered", primary);
-	} else if (g_strcmp0(num, "02") == 0) {
+	} else {
 		if (secondary != 0)
 			return;
 
-- 
1.6.4.2



Em Seg 31 Mai 2010, às 13:52:58, Kalle Valo escreveu:
> Marcel Holtmann <marcel@holtmann.org> writes:
> > Hi Kalle,
> 
> Hallo Marcel,
> 
> >> I personally would prefer a solution which would dynamically probe the
> >> ports and choose them based on results. I believe modemmanager does
> >> something like this, but I haven't looked in detail.
> > 
> > we should do something like auto-detect at some point, but there are
> > limits in it.
> 
> So what's the best option to go forward?
> 
> And related to this, can we rely on the port numbering order provided by
> udev? For example, on my Huawei E1552 port 0 is the main chat port and
> port 2 is the "event" port. Is it certain that port numbering will be
> the same across all distributions and kernels?

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Florian Steinel]

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

Hi Kalle,

2010/5/31, Kalle Valo <kalle.valo@canonical.com>:
> Hi Florian,
>
> thank you for the patch.
>
> I'm curious, did you test ofono with Huawei E176? Did it work? Did you
> have any problems?
I have testet ofono with Huawei E176, enabled the modem with the
enable-modem script and it doesn't register the sim-card.
The EventChannel logs:
May 30 17:29:34 server ofonod[27315]: > ATE0\r
May 30 17:29:34 server ofonod[27315]: EventChannel: <
\r\n^BOOT:20496466,0,2,0,25\r\n
May 30 17:29:34 server ofonod[27315]: < \r\nOK\r\n
May 30 17:29:34 server ofonod[27315]: EventChannel: <
\r\n^RSSI:99\r\n\r\n^SRVST:0\r\n\r\n^MODE:0,0\r\n\r\n^RSSI:10\r\n\r\n^SRVST:1\r\n\r\n^MODE:5,4\r\n\r\n^RSSI:7\r\n\r\n^BOOT:20496466,0,0,0,25\r\n\r\n^RSSI:11\r\n\r\n^BOOT:20496466,0,0,0,25\r\n\r

> I think adding usb ids to the rules file for each Huawei product is a
> maintenance problem. There are so many devices out there, that handling
> the usb ids for all of them is difficult.
>
> I personally would prefer a solution which would dynamically probe the
> ports and choose them based on results. I believe modemmanager does
> something like this, but I haven't looked in detail.

I will try to implemt the fix mentioned in this thread,

Florian Steinel

Re: [PATCH 1/1] Huawei E176: Mark primary and secondary device at ofono.rules TODO: Fix sim_add detection, add E1552 idProduct to ofono.rules

[Denis Kenzior]

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

Hi Kalle,

> Marcel Holtmann <marcel@holtmann.org> writes:
> > Hi Kalle,
> 
> Hallo Marcel,
> 
> >> I personally would prefer a solution which would dynamically probe the
> >> ports and choose them based on results. I believe modemmanager does
> >> something like this, but I haven't looked in detail.
> >
> > we should do something like auto-detect at some point, but there are
> > limits in it.
> 
> So what's the best option to go forward?
> 
> And related to this, can we rely on the port numbering order provided by
> udev? For example, on my Huawei E1552 port 0 is the main chat port and
> port 2 is the "event" port. Is it certain that port numbering will be
> the same across all distributions and kernels?
> 

I'm not the kernel expert, but the answer is probably 'no'.  However, doing 
any sort of port auto-detection inside plugins/udev.c is a bit nasty.  Best we 
can do is set all of the 2/3/4 ttys and let the plugin probe them.  I 
certainly have doubts we can do this reliably.  If we can't, then we should 
consider Florian's approach as a backup.

Regards,
-Denis