-----Original Message-----
From: Greg KH [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 9:58 AM
To: Angderson, Charyll
Cc: '[EMAIL PROTECTED]'
Subject: Re: bulk read xfers returns wrong data


> 
> >> What's a "WORD" size?  Any reason you aren't using "unsigned char"?
> #define WORD      unsigned short int

Why are you doing this?  What's wrong with "unsigned char", which is
what the usb core is expecting?  Why create yet another variable #define
in your code?  What's wrong with the standard linux kernel ones (u8,
u16, u32, etc.)?

<CA> i need to interface to an existing application that has this defined.
i will  try using unsigned char, but i doubt this will help.

> >     if (usbxPtr->usbx_urb->status!=0) {
> >             err("TIMEOUT awoken %i (%s)
> > status=0x%x",current->pid,current->comm,usbxPtr->usbx_urb->status); //ca
> > debug
> >             usbx_unlink_urb(usbxPtr->usbx_urb);  // remove urb safely
> 
> >> I recommend unlinking in your callback, much easier.
> 
> are saying that i should unlink even if there are no errors? or just
moving
> this check to the callback?

Bulk read urbs do not need to be unlinked.  They are one time only.
However you are relying on the timeout, so why not just set the timeout
field in the urb and have the usb core do it for you?

<CA> i will try this

> >     switch (trans->type) {
> >     case USBX_R_BULK:
> >             dbg("usbx_submit_trans:  print buffer read ..
> > address=0x%lx", (DWORD)&buf);
> >             for (i=0; i<(trans->size/2); i++) {
> >                     dbg(" %x ",(WORD)buf[i]);
> 
> >> You should use the urb->actual_length field here.  That tells you how
> >> many bytes you received (which can be different from what you
> >> requested).  Also, what's with the "size/2" stuff?  We are transferring
> >> bytes here :)
> ok.  i was printing 2 BYTES at a time, per definition of WORD

Again, why?  But the real problem is not checking actual_length.

<CA> i will try this, but i believe that if expected length and actual
length do not match, there will be an error(?)

> >> If you want to do a bulk read that blocks until completed (or timed
> >> out) there already is a usb core function that does it called
> >> usb_bulk_msg() keeping you from having to roll your own.
> 
> in the future, i will not do this.  i will just keep doing submit_trans.
i
> didn't know how to make sure everything was completed?  do you have an
idea?

Test in the callback of the urb to see if everything worked ok?  Just
like almost all of the other Linux drivers do it? :)

Depending on your device, but most usb devices accept just posting a
read urb on the endpoint all of the time.  Then place that data into a
buffer for the userspace read() call to pick up when it wants to.  But
if you are being driven by the read() call, then a call to
usb_bulk_msg() is probably much easier.  See the usb-skeleton.c driver
for an example of this.

<CA> these are driven by IOCTL commands. 

What kind of driver and for what kind of device are you trying to write?

<CA> it's a card that can be forced to do specific USB transactions used to
test the the UHCI unit.  past tests were written for DOS.  i'm trying to
write a version for Linux. 

thanks,

greg k-h

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to