On Mon, Apr 16, 2012 at 06:03:50AM +0000, Xu, Andiry wrote: > > -----Original Message----- > > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > > Sent: Saturday, April 14, 2012 12:13 AM > > To: Andiry Xu > > Cc: linux-usb@xxxxxxxxxxxxxxx; Xu, Andiry; Alan Stern > > Subject: Re: [RFC] xHCI: keep track of ports being resumed and indicate in > > hub_status_data > > > > On Sat, Apr 14, 2012 at 02:54:30AM +0800, Andiry Xu wrote: > > > This commit adds a bit-array to xhci bus_state for keeping track of > > > which ports are undergoing a resume transition. If any of the bits > > > are set when xhci_hub_status_data() is called, the routine will return > > > a non-zero value even if no ports have any status changes pending. > > > This will allow usbcore to handle races between root-hub suspend and > > > port wakeup. > > > > Hi Andiry, > > > > Thanks for doing this! The patch looks fine, but I have one question: > > > > > --- a/drivers/usb/host/xhci.h > > > +++ b/drivers/usb/host/xhci.h > > > @@ -1362,6 +1362,8 @@ struct xhci_bus_state { > > > u32 suspended_ports; > > > u32 port_remote_wakeup; > > > unsigned long resume_done[USB_MAXCHILDREN]; > > > + /* which ports have started to resume */ > > > + unsigned long resuming_ports; > > > > Is there a particular reason why you chose unsigned long for this when > > the other two bitmasks for port suspend states (suspended_ports and > > port_remote_wakeup) are u32? > > > > After double check, I found there is reason to use unsigned long. > set_bit/clear_bit requires a unsigned long pointer parameter. Passing > a u32 pointer to it causes compile warning, at least on x86 platrform. > So I think we should keep using unsigned long. Ah, ok, makes sense. Let me figure out which branch to apply this to and I'll send it off to Greg. 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
