USB device_driver_handle

In the USB docs (line 288) in the explanation of the Service_USB Device has gone (r0 = 2) it notes that this service call is no longer used and to use Service_DeviceDead instead. To avoid confusion can you change the note to explain that in the Service_DeviceDead service call you need only match r3 with the device name to determine that the device has been removed.

Why?

Service_DeviceDead is called with r2 = device_driver_handle and r3 = device_name. This implies that you need the device_driver_handle together with the device_name to identify which device has died. But this isn’t true because each device in DeviceFS has to have a unique name (which it needs to set up system variables).

Someone thought it was necessary so added it to DeviceFS_CallDevice getHandles2 (reason code 1<<31+7) which returns device_driver_handle in r6 however if it was necessary this call would not be good enough as you need a file handle to call it and a device which only used the control endpoint wouldn’t have a file handle to use. device_driver_handle is not stream dependant – its the value returned from DeviceFS_Register.

So rather than creating a new DeviceFS_CallDevice call to read device_drive_handle I think its easier to clarify that it is not needed. I think r6 in getHandles2 shouldn’t have been added and should be deprecated.

Service_DeviceDead is called with r2 = device_driver_handle and r3 = device_name. This implies that you need the device_driver_handle together with the device_name to identify which device has died.

Isn’t device_driver_handle needed because (PRM 2-433) Service_DeviceDead can be sent with R3=0 when the top level driver vanishes? Presumably there are situations where that’s what you’re interested in, rather than the device itself vanishing (which as you say can be uniquely matched by name). I don’t think the idea is to match both R2 and R3.

I’m not aware of the history behind GetHandles2, but it’s reasonably recent, perhaps Thomas or Jeffrey can confirm my hunch?

I thought my proposal was ignored so I’ve added a new call to read the handle.

1) All subdevices are deregistered before the main device is deregistered so you will always get r3=name devicedead followed by r3=0 devicedead so if you only use r2 you’ll get 2 devicedeads. The only way to recognise a devicedead if you are only using control endpoints is via r3=name because the device drivers handle is only accessible if you have a stream handle USBManual.pdf may help in understanding what handle does what – its work in progress.
2) USBDriver only implements 1 subdevice per maindevice
3) It turns out that device_drivers_handle is useful with DeviceFS_CallDevice – it avoids the search DeviceFS makes for the handle using the name. But you can’t get at it unless you open a stream as gethandles2 requires a stream handle. So I’ve added a DeviceFS_CallDevice call to read the device driver handle from the driver name.