This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001024] STM32 USB driver and proposed USB API change
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Wed, 20 Oct 2010 19:27:20 +0100
- Subject: [Bug 1001024] STM32 USB driver and proposed USB API change
- Auto-submitted: auto-generated
- References: <bug-1001024-104@http.bugs.ecos.sourceware.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 #29 from Chris Holgate <chris@zynaptic.com> 2010-10-20 19:27:14 BST ---
(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.
--
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.