On Thu, May 16, 2002, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, May 14, 2002 at 10:05:40AM -0700, David Brownell wrote: > > > > Yes, as I noted separately. Move the deallocate() call and > > > > it'll behave though. > > > > > > Sorry, but to where (missed that one.) > > > > > > A patch would show it better :) > > > > See the attached ... it re-fixes that bug in those recent patches. > > > > Now a routine that's not allowed to be called with a thread context > > can't be called in_interrupt() any longer, even given buggy device > > drivers that don't disconnect() correctly. > > Sorry for the delay, got busy at work. > > Anyway, I don't understand how this patch changes anything. The call to > usb_put_dev() right below the place you patched usb_disconnect() would > do all of the cleanup that you just added to the function.
I was doing some work on this yesterday. The problem is that OHCI needs a callback to be made before it can free the memory. Since linking in and unlinking ED's under OHCI require you to stop and start (well, atleast in usb-ohci, more on this later) the HC from processing the queue, which would be a performance hit, it links it in the first time and then never unlinks it until the device is removed. So it needs a method to be notified when the device is removed to atleast start unlinking the ED's. In this case, usb-ohci has been using the deallocate() callback. That's why deallocate() needs to be moved into usb_disconnect(). It's not that it requires to be a thread context, although the current implementation requires it. This is a seperate problem, but significant nonetheless given the implementation of sohci_free_dev. The reference counting change we just merged into 2.5 doesn't guarantee that the deallocate() callback will be made in a thread context. Nor does 2.4 guarantee that because the reference counting code is essentially the same. So we need to do something similar for 2.4 as well. > Are you trying to separate the hardware specific portions of the device > from the "logical" portions? (I think this is your main point, right?) > > If so, this patch _might_ work, but I'd like to get Johannes to look at > it in light of uhci.c. uhci.c is safe since it doesn't implement a deallocate() call. usb-uhci is safe as well because of the unlink_urbs (or whatever it's called) call. I think the patch that David proposed to move deallocate() into usb_disconnect() should go into 2.5 and 2.4 since it's needed to make the code safe. That will be immediately make the code safe at the cost of some complexity in some HCD's. I have a patch I'm testing that cleans up the usb-ohci routines that David and I have been "discussing" for the past couple of days. I'd also like to see if we can handle unlinking the ED differently so it doesn't require stopping the process of that part of the schedule. This is a bit experimental so I may wait to do that. Correctness before performance. Once I've done some more testing with usb-ohci, I'll make the appropriate changes to ohci-hcd and ehci-hcd as well and send the patch out. JE _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
