> -----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. Thanks, Andiry -- 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
