[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #33 from Chris Holgate <chris@zynaptic.com> 2010-10-21 19:47:48 BST ---
(In reply to comment #30)

> Is there any way to avoid the blocking usbs_*_start() call when using dynamic
> endpoint configuration? I was wondering if the endpoint structs should be
> retrieved within usbs_*_wait_until_configured(), which is already a blocking
> call, rather than within usbs_*_start(). usbs_*_wait_until_configured() would
> not be called from usbs_*_start(). This would make a call to
> usbs_*_wait_until_configured() essential rather than advisable but would avoid
> a hardware-dependent variation in blocking/non-blocking behaviour of
> usbs_*_start(). Does this make sense to you?

Yes - that is a cleaner way to do it.  At the moment USB class driver
implementations are a bit ad-hoc and documenting a recommended set of lifecycle
management functions as above would help to add some consistency.

> Will the driver re-use the same endpoint structures if the cable is
> disconnected and then reconnected?

Not necessarily - if the descriptors change or the host selects a different
configuration, all bets are off.  Any endpoint references held by a class
driver should be treated as going out of scope when the USB device leaves the
'configured' state.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.