Yes. It looks good. However, after I sent my original message, I thought
of something else. When the USB spec was created one of the reasons they
added the bLength field at the beginning was so they could extend the
descriptor in the future with more fields if necessary and still maintain
backwards compatibility.
If we see the bLength is longer than what we read. Should we try reading
again with the full length?
I guess it's not worth it since we don't know what those new fields are
anyway since we'd need to program support for them. If that comes around
then we can manually increase the amount read to compensate for the new
fields.
I didn't get a chance to test the patch, but it looks correct.
JE
On Sat, Jun 17, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> Johannes,
> Did you look over the patch yet?
>
> Gosh, even USB 2.0 still only allows 127 devices (per
> bus/controller). Why the 255?
>
> ~Randy
>
> -----Original Message-----
> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 17, 2000 9:05 AM
> To: Brad Hards
> Cc: Dunlap, Randy; '[EMAIL PROTECTED]'
> Subject: Re: [linux-usb] Monitor with embedded hub
>
>
> On Sat, Jun 17, 2000, Brad Hards <[EMAIL PROTECTED]> wrote:
> > Johannes Erdfelt wrote:
> > >
> > > On Fri, Jun 16, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> > > > I got a CTX monitor/hub this week and spent today
> > > > looking into this problem. The problem is that
> > > > the hub doesn't like to return a partial descriptor
> > > > in usb_hub_configure() [2-byte "header" is requested].
> > > >
> > > > I have made 2 workarounds for this and either one
> > > > of them works, but I'd like your opinion on them,
> > > > then one of us can make a patch to hub.c.
> > > >
> > > > A. Do the normal 2-byte header request, then handle
> > > > this error case (something like):
> > > >
> > > > if (ret == -EPIPE &&
> > > > (vendor == CTX) && (product == 0x9999)) {
> > > > /* simulate good desc & clear the stall */
> > > > bLength = 2;
> > > > bDescType = USB_DT_HUB;
> > > > if (usb_clear_halt(dev, usbrcvctrlpipe(dev, 0)))
> > > > return -1;
> > > > }
> > > > ...
> > > >
> > > > . More direct, less intrusive to the current code.
> > > >
> > > > or:
> > > >
> > > > B. Don't do a 2-byte header request; do a header request
> > > > of 13 bytes [or maybe even larger, but 13 bytes is enough
> > > > for a 16-port hub]. This requires only one get_hub_desc()
> > > > call instead of 2. Instead of the 2nd call, just
> > > > memcpy (bitmap, buffer, header->bLength).
> > > > [Think we'll ever need to support more than 16 ports on
> > > > a hub?]
> > > >
> > > > . More general solution [unless we find some hub that doesn't
> > > > like descriptor requests that are _larger_ than actual].
> > > > . Calls get_hub_desc() one time instead of 2 times.
> > > >
> > > > I tested both methods with a keyboard and floppy drive
> > > > on UHCI (both HCDs) and OHCI.
> > > >
> > > > Which method do you prefer? Do you want to make a hub.c
> > > > patch for this or have me do it? I'll be glad to send
> > > > my patches to you, of course.
> > >
> > > I like option B, but why don't we just request 39 bytes?
> > >
> > > That's 7 bytes for the base hub descriptor, 16 bytes for DeviceRemovable
> > > (127 ports) and 16 bytes for PortPwrCtrlMask (127 ports).
> >
> > Any reason why you chose 127?
> > Table 11-8 of USB Spec Rev 1.1 says "maximum of 255 ports". So that
> > should be 7+32+32 or about 71 bytes requested.
>
> Because you can only enumerate 127 devices on the bus. I wonder why that
> says
> 255. I guess we could set it to 71 without any worries as well.
>
> JE
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
