On Mon, Sep 22, 2003 at 05:44:49PM -0700, Neil Whelchel wrote:
> Hello,
> I am in the middle of writing a driver for the Cypress M8. This is a
> way-too-goofy USB to serial converter.
> I have a fairly clear understanding of what I need to do to make it work,
> but here is where I run into issues...
>
> The device is a 'USB to serial converter' but it is in the HID class...
Ick, HID? why...
> According to its documentation, it has three endpoints.
> 0 For reading or writing the serial parameters. (Feature report)
> 1 For reading data from the serial port (Input report)
> 2 For writing data to the serial port (Output report)
What kind of endpoints are these? Bulk?
> Do I put the driver in the input directory and use the hid-core functions,
> or do I put it in the serial directory and use the usb-serial functions?
>
> At the time being, I have it in the serial directory and I am using the
> usb-serial functions. I added a few lines of code to the hid-core.c file
> to get it to ignore the device.
I think this looks like the correct thing to do for now.
> At this point all is well, and my driver in the serial directory picks it
> up and registers the serial device.. The way I understand the USB
> specification, you can use the interrupt_in_pipe for reading input reports
> and the interrupt_out_pipe for writing output reports However,
> usb-serial.c is missing the functions to do interrupt out transfers.. So,
> off I went and added them...
> (I included the diffs below...) I am not sure if this is correct however..
> Is there a reason that there is on support for interrupt out transfers in
> the usb-serial?
No one has needed them before :)
Next time try sending diffs with "-u" like
Documentation/SubmittingPatches suggests. It's easier for us to read
them that way.
But why not just create the urbs for these endpoints yourself? Why does
the usb-serial core have to do it for you? You have access to the whole
device descriptor so you can pick out the pieces that you need if you
want to. That's what other drivers have done that have "special"
endpoint needs. The usb-serial core just happens to handle a narrow
range of endpoint needs that some usb-serial drivers use. If your
device doesn't fit this model, it's real easy to just ignore it and do
your own endpoint management (look at the io_edgeport and io_ti drivers
for examples of this.)
> I am now able to read and decode the data from endpoint 1, and I can
> send data to the serial port via endpoint 2, but here is
> where I really get stuck and the main reason I am writing to you..
>
> In usb-serial.c the iface_desc->desc.bNumEndpoints shows up as 2, not 3...
> I am working on the following assumptions any of which are likely to be
> wrong...
What does /proc/bus/usb/devices say with this device plugged in?
> Ok, so endpoint 0 is a control endpoint and it doesn't show up on the
> list...
What list?
> So I need to use a function like usb_control_msg() to talk to it.
> If so, I need to construct a feature report and send it off which means
> that I need some #defines from ../input/hid.h (which seems a messy way of
> doing things to me) and I need something like...
> ---------------------------------------------------------------------------
> // The feature report needs to be 5 bytes
> // For now I am sending a test feature report to put the device in a known
> // sane state (9600 baud, no parity, one stop bit 8 bits (8N1))
> __u8 feature[5]={
> 0x80,
> 0x25,
> 0x00,
> 0x00,
> 0x03
> };
>
> usb_control_msg (port->serial->dev, usb_sndctrlpipe (port->serial->dev, 0),
> HID_REQ_SET_REPORT, USB_DIR_OUT | USB_RECIP_INTERFACE |
> USB_TYPE_CLASS,
> 0x0300, 0, feature, 5, 500);
> ---------------------------------------------------------------------------
> The above call is always failing.. I am not sure if I have everything the
> way that I need it or not, the USB documentation is unclear to me if the
> actual data needs to be in some sort of a packet or not.. Are there any
> examples of sending a feature report to a device? Should I really be using
> the hid-core stuff instead?
> This will be my first (of hopefully many to come) contributions to the
> Linux kernel...
What does the device use the HID feature reports for? To control line
settings? Does it send HID reports back to the driver that it has to
parse?
I agree that rolling your own HID requests isn't very nice, and yes,
including a file from a few directories over isn't that big of a deal to
get the proper #defines and such. It's easier than having two copies of
them in the kernel tree. It's probably the only way to do this until
the HID core gets split out of the input layer (as others have discussed
in the past.)
> If I am on the right track with the patches and the driver, what do I need
> to do to get them to the right people to be included in the kernel?
Read Documentation/SubmittingPatches and send it here and CC: me.
Hope this helps,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
