I have a patch for Option B (with Option A still there
in comments). I'll clean it up and then run it by you.
~Randy
> -----Original Message-----
> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 16, 2000 2:47 PM
> To: Dunlap, Randy
> Cc: 'Ken Scott'; '[EMAIL PROTECTED]'
> Subject: Re: [linux-usb] Monitor with embedded hub
>
>
> 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).
>
> 39 bytes is not really anymore significant than 13 bytes and
> it doesn't
> assume we won't see hubs with more than 16 ports.
>
> We can safely assume devices can handle sending less data than we can
> handle. This is what Windows does.
>
> If you have a patch for option B, I'll be more than happy to use that.
> If not, I'll develop one today.
>
> JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]