David Brownell wrote:
> Make that <linux/usb/midi.h> or maybe <linux/usb/audio.h> ... in
> fact, several pending patches move <linux/usb_*.h> files into that
> subdirectory, so watch out when this is ready to submit.
Ok thanks. How can I track where those patches are up to? I'm
pulling from Linus at the moment.
> This still have some debris left over from gadget zero, like mentions
> of having two configurations, using endpoint names rather than just
> the endpoints, and even comments describing itself as being gadget zero.
> Best to clean that stuff up more; gadget zero did a bunch of stuff
> mostly to make sure that APIs get tested, or to work with earlier
> versions of the gadget framework, and your driver can be smaller.
Agreed, a certain amount is still there due to fear of breaking what
I don't understand. I might have some more questions when I go through
it more closely, but I have to say your doco has been excellent.
> I don't think this is a case where usb_ep_alloc_buffer() and friends
> are desired ... such buffers are normally not cacheable.
Ok - so just kmalloc is the go here?
> You should have driver code to support high speed controllers, e.g. the
> high speed descriptors including the device qualifier.
Can do, although I have no way to test this at the moment. If anyone else
out there with suitable hardware would like to have a play with this,
that would be great.
>> +static const struct USB_MIDI_OUT_JACK_DESCRIPTOR(1) jack_out_emb_desc = {
>
> What's with the SHOUTING in a struct name? Those are nasty macros.
> All the struct names should be lowercase.
Yeah I was afraid that would cause some offense. I went with the "ugly macro
hacks should look ugly" theory, I didn't want to hide this from attention.
I'm more than happy to make the macro names lower case and include the struct
keyword in the name and definition:
#define struct_usb_midi_out_jack_descriptor(p) \
struct { \
__u8 bLength; \
__u8 bDescriptorType; \
__u8 bDescriptorSubtype; \
__u8 bJackType; \
__u8 bJackID; \
__u8 bNrInputPins; \
struct usb_midi_source_pin pins[p]; \
__u8 iJack; \
} __attribute__ ((packed))
You can see what I'm trying to do here - I want to make it easy to define
descriptors with any number of source pins, as static const data. Would
the cosmetic changes above be sufficient? I can think of other alternatives
that I like even less - all suggestions welcome.
> Note that this attachment got mangled a bit too (STATE_SYSEX_2 line wrapped).
Bad thunderbird! Grr..
Thanks, this is all useful feedback. Cheers,
- Ben.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
