Hi, On Mon, 2005-01-10 at 17:44 +0100, Duncan Sands wrote: > (1) cxacru_blocking_completion, cxacru_timeout_kill and cxacru_start_wait_urb > will have to go. I think Josep put them in because in linux 2.4 there was no > way to cancel the generic versions in message.c on disconnect. In 2.6 any > urbs > that are in flight when the device is disconnected are shot down automatically > so this is no longer an issue.
Josep isn't guilty here, this stuff is all mine (he supported a set of userspace tools similar to modem_run for speedtouch, and a patch to the pre-2.6.10 speedtch.c which entered the new usb_atm.c). The reason to add those functions was also different: I tried to make it behave closer to the Windows driver, than Josep's tool. Namely, upon loading the firmware the modem is switched to the "cm" mode where it responds to each message, with the first byte in the reply being the same request code (one of cxacru_cm_request) as in the message to the modem, and the second byte being the status code (one of cxacru_cm_status). According to the usbsnoop log, the Windows driver in this mode a) accesses 0x01/0x81 endpoints via interrupt pipes (rather than bulk pipes when loading firmware) b) submits with the sending urb with the request _after_ the receiving urb to read the modem response to this request while, quite naturally, the sending urb should complete before the receiving one Neither a) nor b) is possible with the generics in message.c, so I added the three functions you mentioned and the supporting data members to struct cxacru_instance (buffers, urbs, completions and a semaphore for the mutex). > (2) What does the cm in cxacru_cm stand for? I'd prefer a more > self-explanatory > version of the name. It denotes that this function is used to send CM_REQUEST_* to the modem and receive CM_STATUS_* back :) The names of CM_* constants in turn come from running "strings | grep '^CM_' | tac" on the Windows driver. Presumably they've been put there for debugging purposes, which was suggested by the Conexant driver for Linux distributed by some modem vendors. I suspect CM is to mean "command". I'm not particularly attached to this name, can change it to whatever looks more comprehensible. > (3) Setting the MAC address in cxacru_got_firmware. This one worries me: we > create > the ATM device when the device is probed. The firmware is loaded at some > later time > (in a kernel thread, because it would take too long for khubd). At that > point the > MAC address is changed. What if this change in the MAC address confuses user > space > tools or other parts of the kernel? I can't judge right now if it's a problem for the ATM layer, I'll have to take a closer look. However the MAC address is unavailable until the firmware is loaded anyway. Cheers, Roman. ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
