This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #30 from John Dallaway <john@dallaway.org.uk> 2010-10-21 09:57:39 BST ---
(In reply to comment #29)
> (In reply to comment #28)
> 
> > I'm concerned that usbs_serial_start() will now block until a connection has
> > been established and endpoints have been configured. How will this affect
> > the
> > implementation multiple function devices over a single USB port where 
> > multiple
> > usbs_*_start() functions may need to be called? I'm thinking that it should
> > be
> > possible to present both a mass storage device and a serial device (for
> > example) over a single physical interface. 
> 
> I don't think this scenario is supported by the USB spec - a single end device
> can only ever implement a single class driver, as identified by the device
> descriptor.  To get multiple class drivers running behind a single USB
> connector, you would need to emulate a USB hub and hang the class drivers off
> the back of that - one per virtual USB slave device.
> 
> While such a feature would be nice to have, it would need quite a bit of extra
> work and may require additional features which are not present on the currently
> supported hardware.

Chris, thanks for your reply. I had assumed that this is how (eg) USB docking
stations work. Perhaps they use a vendor-specific class.

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?

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

I'm just wanting to check we have all bases covered here.

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]