Messages in this thread | | | From | David Brownell <> | Subject | Re: BUG/OOPS: Double Lock in fsl_usb2_udc.c | Date | Thu, 29 May 2008 02:23:39 -0700 |
| |
> On Wed, 28 May 2008 15:25:31 -0700 Eugene_Bordenkircher@selinc.com wrote: > > > Looking through other drivers, I have seen them releasing the lock > > immediately before calling disconnect(), however, without being an expert > > with this driver, I'm not entirely sure that is the best option here.
Yeah, general policy is to drop the UDC spinlock whenever you call out to gadget driver code, since it may need to reenter for various reasons. (Though if drivers adopt some other locking policy that works, that should be fine too. Multiple locks don't seem to be needed.)
If this particular UDC driver doesn't let disconnect() disable the endpoints, that's a bug. All gadget drivers should clean up on disconnect; and while the UDC code ought to have aborted any pending I/Os, it should never be disabling things the gadget driver enabled.
And as for calling disconnect() before proceeding with enumeration ... if the UDC driver can sense disconnect (most often done with a GPIO hooked up to provide IRQs on VBUS edge transitions), it should do so then. But for boards that don't have VBUS sensing, then the only hook to scrub out all the old/invalid connection state is the USB reset sequence that starts enumeration. And that's what seems to be happening here.
- Dave
| |