Re: [RFC] xHCI: keep track of ports being resumed and indicate in hub_status_data

[Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>]

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