On Thu, Mar 10, 2011 at 09:51:49PM -0800, Dmitry Torokhov wrote: > 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? I'm not sure how these bit operations could be unsafe. Can you tell me why? > It is probably cheaper than doing bit operations > by hand and more resilient to changes to the maximum number of children. The maximum number of USB children is very unlikely to change. > It will also allow using find_first_bit/find_next_bit when checking if > any of the ports are suspended, and so forth. That might be useful, but I don't think the speed is needed in that particular path. Perhaps you want to send an optimization patch after this one gets in? I'm not very inclined to change the code for the initial patch, since it passed review from the people on the Cc list months ago, and I want to try and get the USB 3.0 hub support into 2.6.39, if it's not already too late. Sarah Sharp -- 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
