Re: [Libusb-devel] usb_bulk_read - /proc/bus/usb/devices

[Johannes E. <joh...@er...>]

On Fri, May 21, 2004, Stephan Meyer <ste...@we...> wrote:
> > > Why does usb_bulk_read OR the endpoint passed as an argument with
> > > USB_ENDPOINT_IN and cause the usb_bulk_read actually use 0x81 as the endpoint.
> > > 
> > > usb_strerror() returns this:
> > > error reading from bulk endpoint 0x81: Connection timed out
> > > 
> > > usb_bulk_write() seems to work ok, no errors when writing to endpoint 0x81 or
> > > 0x01.
> > > 
> > > I am modifying the ifp.sf.net iRiver drivers to work with the newest iRiver
> > > series (iFP-7XX). I could seem to do everything a usb_bulk_read().
> > > 
> > > I don't think I know enough about USB to go one any further.
> > 
> > Because 0x81 is an input pipe. You can only read from it.
> > 
> > The fact you can write to it indicates a bug in your hardware.
> > 
> 
> Firmware bug? I don't think so because both bulk functions convert their ep argument
> into something they like (at least on Linux):
> 
> bulk_write: ep &= ~USB_ENDPOINT_IN;
> bulk_read:  ep |= USB_ENDPOINT_IN;
> 
> To repeat Joseph's question: why is this done? I think that these parameter 
> modifications produce more confusion than actually helping the user.
> Wouldn't it be much better to validate the ep addresses in both functions and 
> return an error if they are not correct?

Wouldn't it be even better if the hardware did it? That's where it
really matters.

The descriptors said endpoint 1 is an input pipe, but it accepts writes
to it.

libusb is just trying to be nice here. It's lean in this respect on
purpose. There is no security concern if the programmer tries to do
something stupid like this, so why make it more complicated by
preventing it, when the hardware should do it anyway?

JE