This is the mail archive of the ecos-patches@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 #34 from John Dallaway <john@dallaway.org.uk> 2010-10-21 22:20:33 BST ---
(In reply to comment #32)
> (In reply to comment #31)
> 
> > While I haven't looked through the spec for a while, I believe that you
> > _can_
> > have multiple class drivers on a single device without using a virtual
> > hub.  I
> > think it's called a composite device.  The descriptor arrangement is a bit
> > more complicated, but it's still possible.
> 
> Your recollection of the spec is obviously better than mine.  As you say,
> composite devices are supported and I should probably have used the Google
> before posting misleading rubbish!  However, a single device can still only
> have one control endpoint and one root descriptor, which means the scenario
> John mentioned of multiple class drivers calling usbs_start with different (or
> even the same) control endpoint data structures should never happen.
> 
> I think that supporting composite drivers is really an issue for a notional 
> USB
> class driver framework.  As far as the existing low level USB slave drivers
> are
> concerned, a USB device is just a bundle of endpoints and a bunch of arbitrary
> descriptors.  IMHO that is exactly the right level of abstraction - and any
> additional support for composite drivers should be added as an extra layer of
> abstraction between the low level USB slave driver and the class function
> drivers.

Agreed. Composite devices have one device descriptor, one configuration
descriptor and multiple interface descriptors. With the current USB slave
infrastructure it would be easy enough to implement a new composite device but
not so easy to re-use multiple existing function device packages to form a
composite device. I think this should not affect the proposal for dynamic
endpoint configuration.

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