Hi Sarah, On Mon, Mar 07, 2011 at 02:11:52PM -0800, Sarah Sharp wrote: > The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub. > The xHCI driver keeps track of which ports are suspended, which ports have > a suspend change bit set, and what time the port will be done resuming. > It keeps track of the first two by setting a bit in a u32 variable, > suspended_ports or port_c_suspend. The xHCI driver currently assumes we > can have up to 256 ports under a roothub, so it allocates an array of 8 > u32 variables for both suspended_ports and port_c_suspend. It also > allocates a 256-element array to keep track of when the ports will be done > resuming. > > Since we can only have 31 roothub ports, we only need to use one u32 for > each of the suspend state and change variables. We simplify the bit math > that's trying to index into those arrays and set the correct bit, if we > assume wIndex never exceeds 30. (wIndex is zero-based after it's > decremented from the value passed in from the USB core.) Finally, we > change the resume_done array to only hold 31 elements. > Would not it be safer to use DECLARE_BITMAP() and __set_bit()/ __clear_bit() instead? It is probably cheaper than doing bit operations by hand and more resilient to changes to the maximum number of children. It will also allow using find_first_bit/find_next_bit when checking if any of the ports are suspended, and so forth. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
