On Fri, Dec 21, 2001 at 10:26:46AM -0800, Angderson, Charyll wrote:
> 
> 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 this is data that is coming across a user to kernel space boundary,
then you need to use the __u8, __u16, __u32, etc. typedefs.  See the
Linux Device Drivers book for more information about this.  I'm just
trying to prevent you from using your own #defines or typedefs, when
there already are ones that you should use.  It's a style issue, and
doesn't fix your problem (yet :).

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

No.  You can ask for 64 bytes, but the device only returns 12.  That's
legal, and usually happens :)

> 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. 

So then usb_bulk_msg() would be fine for this instance.

> 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. 

Nice.  Any plans on releasing the code for this driver?

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