usbd doesn't get DEVICE_DETACH? (plus patch for typo in usbd.c)

From: Johny Mattsson <lonewolf-freebsd_at_earthmagic.org>
Date: Tue, 21 Oct 2003 16:45:14 +1000
Hi all,

BACKGROUND:
After a recent purchase of a Palm Tungsten W, I've been spending a few 
hours getting the synchronization working in FreeBSD (which hasn't been 
an easy task). I've almost got it all up and running, by using a PPP 
over Serial over USB setup, but I have a small problem remaining.

THE PROBLEM:
Basically, what's happening is this: When I initiate the sync on the 
Palm, it lights up the USB port and a /dev/ucom0 is created for me. My 
usbd then launches a ppp instance for that port, as well as the service 
daemon for the Palm device. This is all well and wonderful. However, 
when the sync is complete, the Palm closes down the USB port (to be 
expected), and /dev/ucom0 is removed. The problem is that the usbd only 
sees a DRIVER_DETACH, not a DEVICE_DETACH message, and because of that, 
it doesn't execute the "detach" statement for ucom0 (in my case, to shut 
down ppp and the service daemon). The net effect is that I get a ppp 
hanging around and getting in the way for the next sync.


SPECIFIC QUESTION:
What I'd like to know is whether usbd should pick up on the implicit 
device detach in the DRIVER_DETACH event (probably won't work if there's 
more than one device hanging off the driver detaching), or if there 
should indeed be a DEVICE_DETACH arriving before the DRIVER_DETACH?

If I read usb.c correctly, it appears that when a detach event is 
posted, any events in the queue with the same cookie will be discarded. 
Is this intended behaviour, or should DEVICE_DETACH messages be left in 
the queue for normal processing? For me it would make more sense if they 
were kept, but I don't have any previous exposure to this code, so I'm 
not an authoritative voice exactly.

As can be see in the trace below, the DRIVER_DETACH event does contain 
the device name, so it would be easy to modify usbd to handle this 
scenario as well. It doesn't feel like a very elegant way to do things, 
though, and as I mentioned above, it probably can't deal with the case 
where there's more than one device handing off the detaching driver.

If someone points out what would be the preferred way of resolving this, 
I'm happy to get a patch happening.

Trace showing that there's no device-detach picked up by usbd:
====
usbd: processing event queue on /dev/usb
usbd: driver-attach event cookie=3217029324 devname=ucom0
USB_EVENT_DRIVER_ATTACH
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1066715435.318666000, Palm Handheld, Palm, 
Inc.:
   vndr=0x0830 prdct=0x0031 rlse=0x0100 clss=0x0000 subclss=0x0000 
prtcl=0x0000
   device names: ucom0
usbd: ucom0 matches ucom0
usbd: Found action 'Palm Tungsten W' for Palm Handheld, Palm, Inc. at ucom0
usbd: action 0: Palm Tungsten W
   vndr=0x0830 prdct=0x0031
   devname: ucom0
   attach='/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 
192.168.2.3 -n 255.255.255.0'
   detach='killall ppp; killall pi-csd'
usbd: Setting DEVNAME='ucom0'
usbd: Executing '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H 
sarah -a 192.168.2.3 -n 255.255.255.0'
Working in auto mode
Using interface: tun0
/usr/local/bin/pi-csd(50923): Connection Service Daemon for Palm 
Computing(tm) device active.
/usr/local/bin/pi-csd(50923): Accepting connection requests for 'sarah' 
at 192.168.2.3 with mask 255.255.255.0.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
Terminated
usbd: '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 
192.168.2.3 -n 255.255.255.0' returned 143
usbd: driver-detach event cookie=3217029324 devname=ucom0
USB_EVENT_DRIVER_DETACH
usbd: doing timeout discovery on /dev/usb0
usbd: doing timeout discovery on /dev/usb1
====

Oh, and there's a typo in usbd.c too, it's printing DETACH when the 
event is ATTACH. One-line patch to fix this is ATTACHed (pun intended).

Cheers,
/Johny
-- 
Johny Mattsson - System Designer ,-.   ,-.   ,-.  There is no truth.
http://www.earthmagic.org     _.'  `-'   `-'  There is only perception.

--- usbd.c.org	Tue Oct 21 15:49:52 2003
+++ usbd.c	Tue Oct 21 15:50:10 2003
_at__at_ -908,7 +908,7 _at__at_
 			break;
 		case USB_EVENT_DRIVER_ATTACH:
 			if (verbose)
-				printf("USB_EVENT_DRIVER_DETACH\n");
+				printf("USB_EVENT_DRIVER_ATTACH\n");
 			break;
 		case USB_EVENT_DRIVER_DETACH:
 			if (verbose)
Received on Mon Oct 20 2003 - 21:45:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:26 UTC