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]
