On Tue, 2004-09-28 at 08:58 +0200, Duncan Sands wrote: > I did a version myself six months ago, but I never got round to polishing and > sending it... So thanks for doing this - at least it will push me to finish > my version!
:) > I notice that you are uploading the firmware on interface 2 from the > probe call on interface 1. (Doing things which take a long time like this > in the probe call is a big no-no by the way). This works OK in 2.6, but > I'm not sure that everything is set up OK for interface 2 at this time > in 2.4 (in any case you need to claim interface 2). This is a possible > reason for the problem you are seeing. At various times I've also tried it in the probe for interface 2, and tried claiming interface 2 and tried _enabling_ interface 2 by calling usb_set_interface(2,0)... none of which make much difference. > Let me make some quick comments: > > > Can anyone point out what I've done wrong? > > > > (Don't look too hard -- I'll clean it up when it actually _works_) > To avoid subtle nastiness, you almost certainly need to add a reference count > to the structure. Agreed. That was one of the things I intended to cover by the 'I'll clean it up when it actually works' caveat. > Also, is there really any point in monitoring the line status? > That's one thing that could be done perfectly well from user space. It's cheap and easy to do it in the kernel; it doesn't involve running a daemon. Listening to the interrupt endpoint is probably better done in- kernel, I think. > The extraction should not be done in the kernel. It should have been done in > advance in userspace (using some kind of small extraction tool). Yeah, I was coming to that conclusion too, and it fairly neatly solves the problem of how to fetch the firmware too -- we can package a version of the 'standalone extracter' with something to automatically download the firmware. > I hope you realise that you are blocking the entire USB subsystem here? > It is not OK to spend large amounts of time in the probe call: there is > only one task that handles all hub events, probing etc (yes, I know this > is silly - it should be fixed in 2.7). Yeah, I know that. Bug me when it works :) > The urb's completion handler may still be running on a different CPU at this point... Details, details... :) The interrupt handling stuff is just thrown together as a first effort and not really considered very deeply yet. It compiles -- it can get more attention when the firmware actually loads. But thanks for the feedback. Now, should I forget this and wait for your version? Could I have a copy of what you did, and work from that instead? Did it at least manage to get as far as loading the firmware of the poxy thing? :) It would be useful if we could force a reset and load the firmware _again_ when the module is loaded and the modem is in an unknown state. Is that possible? -- dwmw2 ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
