Re: [patch] USB after second suspend/resume on ThinkPads.

On 0618T1515, John Baldwin wrote:
> On Wednesday, June 18, 2014 2:46:09 pm Edward Tomasz Napierała wrote:
> > On 0618T1303, John Baldwin wrote:
> > > On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
> > > > On 0618T0947, John Baldwin wrote:
> > > > > On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
> > > > > > Hi.  Patch below should fix a problem where USB stops working after
> > > > > > _second_ suspend/resume, which happens on various ThinkPad models.
> > > > > > Please test, and report both success stories and failures.  If nothing
> > > > > > comes up, I'll commit it in a week or so.
> > > > > 
> > > > > Good find.  Have you thought about a more generic fix for this wherein you 
> > > > > track power resources and flip them on during resume in ACPI before doing
> > > > > DEVICE_RESUME() on the root bus?
> > > > 
> > > > Thing is, after resume this device claims to be on already.  The following
> > > > simple hack was enough to make it work:
> > > 
> > > Ahh, I think I see.  Try this instead:
> > > 
> > > Index: sys/dev/acpica/acpi_powerres.c
> > > ===================================================================
> > > --- acpi_powerres.c	(revision 267550)
> > > +++ acpi_powerres.c	(working copy)
> > > _at__at_ -645,7 +645,7 _at__at_ acpi_pwr_switch_power(void)
> > >  			      acpi_name(rp->ap_resource), status));
> > >  	    /* XXX is this correct?  Always switch if in doubt? */
> > >  	    continue;
> > > -	} else if (rp->ap_state == ACPI_PWR_UNK)
> > > +	} else
> > >  	    rp->ap_state = cur;
> > >  
> > >  	/*
> > > _at__at_ -689,7 +689,7 _at__at_ acpi_pwr_switch_power(void)
> > >  			      acpi_name(rp->ap_resource), status));
> > >  	    /* XXX is this correct?  Always switch if in doubt? */
> > >  	    continue;
> > > -	} else if (rp->ap_state == ACPI_PWR_UNK)
> > > +	} else
> > >  	    rp->ap_state = cur;
> > >  
> > >  	/*
> > > 
> > > (We were ignoring what _STA told us and believed it was ON because we had
> > >  cached that state previously.)
> > 
> > Works!
> 
> Hmmm.  If we go this route, ap_state is actually useless and should just be
> removed.  Here is an updated version that does that.  If this works as well

Works as well.