> ---------------------------------------------------------
> [BUG] possible, but not sure
Call this a USB 1.0 design bug, partially papered over in the code.
There are two adjacent variable length bitmaps. One of the notable
changes in USB 1.1 was to say the second bitmap isn't really used,
and must be filled with ones.
The code in 2.4.9 (or thereabouts) behaved reasonably here, by
declaring just one single bitmap and expecting users of that bitmap
to cope with its quirkiness. But somewhere along the line that
bit map got changed to two fixed-size bitmaps.
The checker is basically complaining about a "#define bitmap"
that lets driver code be written to reflect the reality of
two adjacent variable-size bitmaps. Quite reasonably so.
Somehow, making drivers/usb/core/hub.h go back to having a
more sensible declaration has never been high on the priority
list. Worth fixing someday, but not a "bug" in the sense of
being incorrect -- only in the sense of being confusing.
- Dave
> /home/yxie/linux-2.5.53/drivers/usb/host/ohci-hub.c:145:ohci_hub_descrip
> tor: ERROR:BUFFER:145:145:Array bounds error (off >= len)
> ((*desc).DeviceRemovable[3], len = 3, off = 3, min(off-len) = 0)
> /* two bitmaps: ports removable, and usb 1.0 legacy
> PortPwrCtrlMask */
> rh = roothub_b (ohci);
> desc->bitmap [0] = rh & RH_B_DR;
> if (ports > 7) {
> desc->bitmap [1] = (rh & RH_B_DR) >> 8;
>
> Error ---> desc->bitmap [2] = desc->bitmap [3] = 0xff;
> } else
> desc->bitmap [1] = 0xff;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:20 EST