upowerd grabs my FTDI USB serial port adapter

[Svein Seldal]

Binary package hint: upower

Running on natty on amd64. upower 0.9.9-4.

I have a development board with a build-in generic FTDI USB Serial port adapter (USB VID:PID 0403:6001). When I plug this into my computer, upowerd grabs (opens) the serialport and thus prevent me from using the serial port.

[Svein Seldal (sveinse)]

This bug is due to a udev rule in /lib/udev/rules.d/95-upower-wup.rules.

This udev rule erroneously assumes that USB VID:PID 0403:6001 is assigned to "Watts Up? Pro" from Watts Up Inc. The VID:PID is rather assiged to a FT232 USB Serial adapter chip from FTDI Inc. The FT232 is a generic electronic part which is default configured with the said VID and PID. This part is used in a lot of development boards and different kind of products. It cannot be assumed that this VID and PID belongs to the Watts Up Pro product.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Poole (mdpoole)]

According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586751, this was fixed in 0.9.5-5 -- apparently it has regressed (I see upowerd grab my /dev/ttyUSB0, which is not a Watts Up device, and never let go).

[Laurent Pinchart (laurent-pinchart-ideasonboard)]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586751 mentions commit 163d5fc3 which was supposed to fix the problem.

commit 163d5fc355670722ce45893e5af60ea4bde06a82
Author: Richard Hughes <email address hidden>
Date: Mon Sep 20 16:22:45 2010 +0100

    Do not continue to poll the serial port if there is no Watts Up Pro adaptor

diff --git a/src/linux/up-device-wup.c b/src/linux/up-device-wup.c
index 73bb8e5..bf5dbb8 100644
--- a/src/linux/up-device-wup.c
+++ b/src/linux/up-device-wup.c
@@ -376,11 +376,7 @@ up_device_wup_coldplug (UpDevice *device)

        /* coldplug */
        egg_debug ("coldplug");
- up_device_wup_refresh (device);
-
- /* hardcode true, as we'll retry later if busy */
- ret = TRUE;
-
+ ret = up_device_wup_refresh (device);
 out:
        return ret;
 }

However, up_device_wup_refresh() returns TRUE unconditionally, and has always done so since 163d5fc3. It looks like the "fix" has never been tested. This doesn't look like a regression.