Hello,
First off, thank you very much for writing back to me..
I have included my comments (answers to your questions) within the
message..
On Tue, 23 Sep 2003, Greg KH wrote:
> 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...
That is a really good question I think it is brain damaged at the least..
The formal explanation (excuse) by Cypress is that it was done to ease
compatibility with Windoze... If this is really true, I guess it explains
the brain damage. They are claiming that the device will only be embedded
within products that would otherwise be in the HID class, and is not
intended to be used as a stand-alone device. They cited the example of the
exact product that I was working with; the Delorme GPS... Last time I
checked, a GPS does _NOT_ belong in the HID class, it is a SERIAL device
that sends NEMA messages. And by the way, you can still access the
actual serial data before it goes through the Cypress device if you
construct a special cable (which the company does not sell).
>
> > 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?
These are interrupt transfer endpoints, yet anoter jacked up way of doing
things.. (Tons of bus chatter sending empty packets at a syncronous time
base for an asyncronous data protocol.) This thing must have been designed
some close family member of the boss.
>
> > 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.
Well, in this case, I think that they probably should be there as who
knows what devices might need to have them, and if half of it is there
already (interrupt_in), why not... Also, (hopefully) it will keep things a
little more consistent if other programmers choose to use them instead of
rolling their own.. (Not that it is that much work, but it still looks
better.) I will break this out into a seperate patch and let the people in
charge decide... ;)
Sorry about the patch thing. For some reason
I didn't think of reading the linux/Documentation because I was not
actually posting to a list at vger, somehow I got to thinking that the
mailing list I was posting to was not the direct 'connection' to the
kernel.. I think I should have gotten some sleep after my 26 hour
programming session before I posted.
>
> 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 did manage to get around to looking at them, and I agree that I could do
as you suggested, but as I said above, it seemed cleaner to me to finish
what was already started in the usb-serial.c.
>
> > 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?
Sorry about not being more specific about this one.
I was referring to the structures (URBs) that usb-serial creates when it
is asked to do the detection.
>
> > 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?
Yes, to control the serial line settings, one 5 byte feature report can be
read or written to set or read the serial configuration.
By the way, what I said about the above statement was wrong... It works
fine, as it turns out there was a problem with the firmware on the device
I was testing on. I replaced the device and all works fine. I just feel
that there should be a macro or something to roll up a feature report.
Until 5 days ago, I knew nothing about USB. I have never even looked at
the USB stuff in the kernel before. Frankly I have avoided it at all cost
until now. The one thing that changed my mind was the nice documentation I
found at usb.org. I ended up reading it from cover to cover. Now that I
understand it, I really like it, except for these jokers that bend the
rules and do stuff like the device I am dealing with now.
The real problem I was running into was I had to build the
usb_control_msg() by reading the USB bit level communication stuff, there
was not anything obvious to me that I could use.. Im sure there is such
stuff floating around in the code, but with myself being new at it, it was
an up-hill battle.
>
> 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.)
That would be nice, it would surely make it easier on people like me that
are new to working with the USB code.
>
> > 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.
I have the driver working perfectly at this point, I will be cleaning it
up a bit and I will submit it as soon as I am done.
I have already started research for my second driver..
It is a device called the PMD-1208LS
http://www.measurementcomputing.com/cbicatalog/cbiproduct_new.asp?dept_id=352&pf_id=1535
Yes... It is in the HID class again...
For this one, I was thinking of making some sort of a subclass of the
'input' stuff... Maybe input/io.. as in /dev/input/io0 /dev/input/io1..
What do you think?
I was thinking of setting up the device so that the user could fseek to
the register that the want, for example a raw open/read to the device
would read every input in sequence, and the control registers at the end.
Then throw in a few ioctls to set/read the control registers as well, give
the users a choice.... Any thoughts?
Thanks again,
-Neil Whelchel-
>
> 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
