| Message ID | 1536928411-12045-3-git-send-email-mathias.nyman@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xhci fixes for usb-linus | expand |
On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: > From: Anshuman Gupta <anshuman.gupta@intel.com> > > When USB bus host controller root hub resumes from autosuspend, > it immediately tries to enter auto-suspend, but there can be a > scenario when root hub is resuming its usb2 ports, in that particular > case USB host controller auto suspend fails since it is busy > to resuming its usb2 ports. > > This makes multiple failed cycles of auto-suspend until all usb2 > ports of host controller root hub do not resume. > > This patch uses USB core framework usb_hcd_start_port_resume, > usb_hcd_end_port_resume API's in order to autoresume/autosuspend > root hub properly. > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Not needed in stable? Does this fix a specific commit? thanks, greg k-h
On 14.09.2018 16:00, Greg KH wrote: > On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: >> From: Anshuman Gupta <anshuman.gupta@intel.com> >> >> When USB bus host controller root hub resumes from autosuspend, >> it immediately tries to enter auto-suspend, but there can be a >> scenario when root hub is resuming its usb2 ports, in that particular >> case USB host controller auto suspend fails since it is busy >> to resuming its usb2 ports. >> >> This makes multiple failed cycles of auto-suspend until all usb2 >> ports of host controller root hub do not resume. >> >> This patch uses USB core framework usb_hcd_start_port_resume, >> usb_hcd_end_port_resume API's in order to autoresume/autosuspend >> root hub properly. >> >> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> >> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> > > Not needed in stable? Does this fix a specific commit? > > thanks, > > greg k-h > This improves a bad initial design that prevented autosuspend by returning -EBUSY in xhci_bus_suspend() if a usb2 port was resuming. Instead increment usage count on the roothub to prevent pm from polling xhci_bus_suspend(). This is also what EHCI does. I'm not sure If this fixes a actual bug for Anshuman Gupta caused by the -EBUSY polling,(4.19 +stable), or if this is just a improvement in suspend/resume code for xhci (4.20). Anshuman Gupta, any comments? -Mathias
On Mon, Sep 17, 2018 at 11:24:20AM +0300, Mathias Nyman wrote: > On 14.09.2018 16:00, Greg KH wrote: > > On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: > > > From: Anshuman Gupta <anshuman.gupta@intel.com> > > > > > > When USB bus host controller root hub resumes from autosuspend, > > > it immediately tries to enter auto-suspend, but there can be a > > > scenario when root hub is resuming its usb2 ports, in that particular > > > case USB host controller auto suspend fails since it is busy > > > to resuming its usb2 ports. > > > > > > This makes multiple failed cycles of auto-suspend until all usb2 > > > ports of host controller root hub do not resume. > > > > > > This patch uses USB core framework usb_hcd_start_port_resume, > > > usb_hcd_end_port_resume API's in order to autoresume/autosuspend > > > root hub properly. > > > > > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > > Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> > > > > Not needed in stable? Does this fix a specific commit? > > > > thanks, > > > > greg k-h > > > > This improves a bad initial design that prevented autosuspend by > returning -EBUSY in xhci_bus_suspend() if a usb2 port was resuming. > > Instead increment usage count on the roothub to prevent pm from polling > xhci_bus_suspend(). This is also what EHCI does. > > I'm not sure If this fixes a actual bug for Anshuman Gupta caused by > the -EBUSY polling,(4.19 +stable), or if this is just a improvement in > suspend/resume code for xhci (4.20). > > Anshuman Gupta, any comments? This patch is not fixing any bug. This patch provide improvement in runtime suspend/resume path of xhci. > > -Mathias
On Wed, Sep 19, 2018 at 10:54:45AM +0530, Anshuman Gupta wrote: > On Mon, Sep 17, 2018 at 11:24:20AM +0300, Mathias Nyman wrote: > > On 14.09.2018 16:00, Greg KH wrote: > > > On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: > > > > From: Anshuman Gupta <anshuman.gupta@intel.com> > > > > > > > > When USB bus host controller root hub resumes from autosuspend, > > > > it immediately tries to enter auto-suspend, but there can be a > > > > scenario when root hub is resuming its usb2 ports, in that particular > > > > case USB host controller auto suspend fails since it is busy > > > > to resuming its usb2 ports. > > > > > > > > This makes multiple failed cycles of auto-suspend until all usb2 > > > > ports of host controller root hub do not resume. > > > > > > > > This patch uses USB core framework usb_hcd_start_port_resume, > > > > usb_hcd_end_port_resume API's in order to autoresume/autosuspend > > > > root hub properly. > > > > > > > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > > > Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> > > > > > > Not needed in stable? Does this fix a specific commit? > > > > > > thanks, > > > > > > greg k-h > > > > > > > This improves a bad initial design that prevented autosuspend by > > returning -EBUSY in xhci_bus_suspend() if a usb2 port was resuming. > > > > Instead increment usage count on the roothub to prevent pm from polling > > xhci_bus_suspend(). This is also what EHCI does. > > > > I'm not sure If this fixes a actual bug for Anshuman Gupta caused by > > the -EBUSY polling,(4.19 +stable), or if this is just a improvement in > > suspend/resume code for xhci (4.20). > > > > Anshuman Gupta, any comments? > This patch is not fixing any bug. > This patch provide improvement in runtime suspend/resume path of xhci. Great, then it shouldn't go into 4.19-final :) Mathias, can you redo this patch series and resend? thanks, greg k-h
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 7e2a531..12eea73 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -900,6 +900,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, set_bit(wIndex, &bus_state->resuming_ports); bus_state->resume_done[wIndex] = timeout; mod_timer(&hcd->rh_timer, timeout); + usb_hcd_start_port_resume(&hcd->self, wIndex); } /* Has resume been signalled for USB_RESUME_TIME yet? */ } else if (time_after_eq(jiffies, @@ -940,6 +941,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, clear_bit(wIndex, &bus_state->rexit_ports); } + usb_hcd_end_port_resume(&hcd->self, wIndex); bus_state->port_c_suspend |= 1 << wIndex; bus_state->suspended_ports &= ~(1 << wIndex); } else { @@ -962,6 +964,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, (raw_port_status & PORT_PLS_MASK) != XDEV_RESUME) { bus_state->resume_done[wIndex] = 0; clear_bit(wIndex, &bus_state->resuming_ports); + usb_hcd_end_port_resume(&hcd->self, wIndex); } @@ -1337,6 +1340,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, goto error; set_bit(wIndex, &bus_state->resuming_ports); + usb_hcd_start_port_resume(&hcd->self, wIndex); xhci_set_link_state(xhci, ports[wIndex], XDEV_RESUME); spin_unlock_irqrestore(&xhci->lock, flags); @@ -1345,6 +1349,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, xhci_set_link_state(xhci, ports[wIndex], XDEV_U0); clear_bit(wIndex, &bus_state->resuming_ports); + usb_hcd_end_port_resume(&hcd->self, wIndex); } bus_state->port_c_suspend |= 1 << wIndex; diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f0a99aa..cd46597 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1602,6 +1602,7 @@ static void handle_port_status(struct xhci_hcd *xhci, set_bit(HCD_FLAG_POLL_RH, &hcd->flags); mod_timer(&hcd->rh_timer, bus_state->resume_done[hcd_portnum]); + usb_hcd_start_port_resume(&hcd->self, hcd_portnum); bogus_port_status = true; } }