Hi David, Only a few comments from me. I hope that the people who would use this will also respond, esp. for your critical (last) questions.
On Wed, 20 Nov 2002, David Brownell wrote: | One of the "we'd like to have it" features for 2.5 is what's been | called a "gadget driver" API -- useful inside small portable | things that talk USB as a pure slave (like most ARM-based PDAs), | or other periperals that are smart enough to run Linux. Lineo's | code didn't get in to Linus' tree, so ... Boy, this looks fun. Wish I were working on it too. | I thought I'd send around a version of something I've had on the | cooker for a bit In practical terms, not only is it thin, but | this is it for the API! No library level code (think "usbcore") | is needed, just some drivers. It's full (overfull) of functional | doc; it's gotta go somewhere! The structure is simple: I like all that function doc. Good stuff. | The API is URB-like, but it turns out that most of <linux/usb.h> | is host-centric. So for now only <linux/usb_ch9.h> is shared, but | it'd be good to share more. That way when we add USB role changes, | as required by OTG (slaves can become masters), the same I/O APIs | would work on bot sides. (Except of course for control requests.) | | I'd be interested in any feedback y'all may have. Does it seem | to be a reasonble fit for hardware you're familiar with? Does | it seem like it'd be easy to work with this (given examples)? | What's broken? (Naming is of course easily changed.) Is this | even vaguely the right direction? :) I'll have to leave that for others. -- ~Randy + * (3) The hardware driver can now start enumerating. The steps it handles + * are to accept USB power and USB device address. Other steps are handled + * by the gadget driver. You mean accept USB device address when the host does set_address()? +/** + * usb_ep_alloc_request - allocate a request object to use with this endpoint + * @ep: the endpoint to be used with with the request + * @mem_flags: SLAB_* flags to use + * + * request objects must not be allocated except with this call, since they change to: * request objects must be allocated only with this call, since they +/** + * usb_set_halt - set or clear the endpoint halt feature. + * @ep: the bulk or interrupt endpoint being stalled or cleared + * @is_halted: nonzero value sets the feature, zero clears it. + * + * when a driver (or host) stalls an endpoint, it stays stalled until the + * host issues request to clear the endpoint halt feature, or the endpoint + * is disabled. + * + * returns zero, or a negative error code. + */ +static inline int +usb_ep_set_halt (struct usb_ep *ep, int is_halted) This function name sounds like it _sets_ is_halted (i.e., to 1). Maybe usb_set_halt_state() instead? +/** + * usb_get_frame - returns the current frame number + */ +static inline u16 usb_get_frame (struct usb_gadget *gadget) I would slightly prefer usb_get_frame_number(). + * usb_set_enable_sof - enables or disables start-of-frame callbacks + * + * this may be of the most interest to isochronous drivers; it arranges + * to call the driver's sof callback at the start of every frame except + * when the device has suspended. + * + * returns zero on success, else negative error code + */ +static inline int usb_set_enable_sof (struct usb_gadget *gadget, int do_call) Likewise, sounds like it enables SOF callback, not sets the state of it. However, this mostly addresses stuff that's easy to change, like you said. ### ------------------------------------------------------- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
