Re: BUG/OOPS: Double Lock in fsl_usb2_udc.c

[David Brownell]

> On Wed, 28 May 2008 15:25:31 -0700 Eugene_Bordenkircher@xxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/