OK, I stand corrected. Thanks to both Nick and Johannes.
This is a case where some comments in the source code
wouldn't hurt. This is non-obvious IMO.
~Randy
___________________________________________________
|Randy Dunlap Intel Corp., DAL Sr. SW Engr.|
|randy.dunlap.at.intel.com 503-696-2055|
|NOTE: Any views presented here are mine alone |
|and may not represent the views of my employer. |
|_________________________________________________|
> -----Original Message-----
> From: Johannes Erdfelt [mailto:jerdfelt@sventech.com]
> Sent: Tuesday, April 11, 2000 9:00 AM
> To: Nick Hibma
> Cc: Dunlap, Randy; 'Karel Srsen'; linux-kernel@vger.rutgers.edu;
> 'linux-usb@suse.com'
> Subject: Re: [linux-usb] RE: USB driver
>
>
> Unfortunately this wasn't the case with me. I wrote the original patch
> to do this (which is the correct thing to do according the USB spec).
>
> The problem I was having was the device I was using didn't like it
> sending 8 byte requests when the maximum packet size of the pipe was
> larger. The device thought it was a short read and then terminated the
> transfer, or more specifically, barf when it saw the next IN since it
> was expecting a status packet.
>
> Trying to read more data than there is descriptor data should be safe
> since the last packet will be treated as a short read and the
> connection
> will end per the spec.
>
> Atleast, Windows tries to read too much and it works.
>
> JE
>
> On Tue, Apr 11, 2000, Nick Hibma <n_hibma@calcaphon.com> wrote:
> >
> > Um, not quite. The reason that one reads the first 8 bytes
> first is that
> > some devices go pop if you read let's say 128 bytes while
> there is only
> > 18 bytes in descriptors.
> >
> > Reading the first 8 bytes and then the the correct number of bytes
> > avoids this problem.
> >
> > Normally one would read the whole set of descriptors in one
> go with a
> > read for 256 bytes or so and chunk it into 8 byte packets.
> >
> > Nick
> >
> >
> > On Tue, 11 Apr 2000, Dunlap, Randy wrote:
> >
> > > Hi,
> > >
> > > When usb_new_device() is called, the maxpacketsize for the
> > > default control pipe is not known, so it's not safe to read more
> > > than 8 bytes of the device descriptor. Since bMaxPacketSize0
> > > (max packet size for the default control pipe) is in this first
> > > 8 bytes, the code can read this byte and use it for future
> > > reads of the control pipe. You can follow the code and see
> > > that a few lines later it calls usb_get_device_descriptor().
> > > This reads the entire descriptor.
> > >
> > > This shouldn't cause any problem(s) with the device you
> > > are working with if it's built properly. If you see problems,
> > > it could be a USB device silicon or firmware problem.
> > >
> > > For future linux-usb discussions, please use the
> > > linux-usb@suse.com mailing list.
> > >
> > > ~Randy
> > >
> > > > -----Original Message-----
> > > > From: Karel Srsen [mailto:Karel.Srsen@asicentrum.cz]
> > > >
> > > > Hello,
> > > > is there somebody who understands linux USB driver ?
> > > > I have one question:
> > > > there is following piece of code in drivers/usb/usb.c
> (2.3.50 kernel):
> > > >
> > > > int usb_new_device(struct usb_device *dev)
> > > > {
> > > > ...
> > > > ...
> > > > err = usb_get_descriptor(dev, USB_DT_DEVICE, 0,
> > > > &dev->descriptor, 8);
> > > > if (err < 8) {
> > > > ...
> > > > ...
> > > > }
> > > >
> > > > that's nice but in fact USB device descriptor's length
> is not 8 bytes
> > > > but 18 (0x12). Does it means that driver reads only
> leading 8 bytes
> > > > instead of whole descriptor ? I thing it's wrong, isn't
> ? Can it cause
> > > > any error ?
> > > >
> > > > I haven't subscribed this mailing list. If you decide
> to answer, send
> > > > reply to Karel.Srsen@asicentrum.cz please.
> > > >
> > > > Karel
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
> > > For additional commands, e-mail: linux-usb-help@suse.com
> > >
> > >
> >
> > --
> > n_hibma@webweaving.org
> > n_hibma@freebsd.org
> USB project
> > http://www.etla.net/~n_hibma/
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
> > For additional commands, e-mail: linux-usb-help@suse.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
> For additional commands, e-mail: linux-usb-help@suse.com
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:16 EST