This is a note to let you know that I've just added the patch titled

    USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

to the 3.19-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     usb-add-flag-for-hcds-that-can-t-receive-wakeup-requests-isp1760-hcd.patch
and it can be found in the queue-3.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 Mon Sep 17 00:00:00 2001
From: Alan Stern <[email protected]>
Date: Thu, 29 Jan 2015 15:05:04 -0500
Subject: USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

From: Alan Stern <[email protected]>

commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern <[email protected]>
Tested-by: Nicolas Pitre <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/driver.c      |   12 ++++++++++++
 drivers/usb/host/isp1760-hcd.c |    3 +++
 include/linux/usb/hcd.h        |    2 ++
 3 files changed, 17 insertions(+)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1780,6 +1780,18 @@ static int autosuspend_check(struct usb_
                dev_dbg(&udev->dev, "remote wakeup needed for autosuspend\n");
                return -EOPNOTSUPP;
        }
+
+       /*
+        * If the device is a direct child of the root hub and the HCD
+        * doesn't handle wakeup requests, don't allow autosuspend when
+        * wakeup is needed.
+        */
+       if (w && udev->parent == udev->bus->root_hub &&
+                       bus_to_hcd(udev->bus)->cant_recv_wakeups) {
+               dev_dbg(&udev->dev, "HCD doesn't handle wakeup requests\n");
+               return -EOPNOTSUPP;
+       }
+
        udev->do_remote_wakeup = w;
        return 0;
 }
--- a/drivers/usb/host/isp1760-hcd.c
+++ b/drivers/usb/host/isp1760-hcd.c
@@ -2247,6 +2247,9 @@ struct usb_hcd *isp1760_register(phys_ad
        hcd->rsrc_start = res_start;
        hcd->rsrc_len = res_len;
 
+       /* This driver doesn't support wakeup requests */
+       hcd->cant_recv_wakeups = 1;
+
        ret = usb_add_hcd(hcd, irq, irqflags);
        if (ret)
                goto err_unmap;
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -146,6 +146,8 @@ struct usb_hcd {
        unsigned                amd_resume_bug:1; /* AMD remote wakeup quirk */
        unsigned                can_do_streams:1; /* HC supports streams */
        unsigned                tpl_support:1; /* OTG & EH TPL support */
+       unsigned                cant_recv_wakeups:1;
+                       /* wakeup requests from downstream aren't received */
 
        unsigned int            irq;            /* irq allocated */
        void __iomem            *regs;          /* device memory/io */


Patches currently in stable-queue which might be from [email protected] 
are

queue-3.19/usb-add-flag-for-hcds-that-can-t-receive-wakeup-requests-isp1760-hcd.patch
queue-3.19/usb-fix-use-after-free-bug-in-usb_hcd_unlink_urb.patch
queue-3.19/usb-core-buffer-smallest-buffer-should-start-at-arch_dma_minalign.patch
queue-3.19/usb-don-t-cancel-queued-resets-when-unbinding-drivers.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to