Cc: Arnd Bergmann
Cc: Ben Herrenschmidt
Cc: linux-usb@vger.kernel.org
Signed-off-by: Matthew Leach
Signed-off-by: Will Deacon
---
drivers/usb/musb/musb_core.c | 12 ++--
drivers/usb/musb/musb_io.h | 21 -
2 files changed, 6 insertions(+), 27 deletions(-)
diff
Balbi
Cc: Arnd Bergmann
Cc: Ben Herrenschmidt
Cc: linux-usb@vger.kernel.org
Signed-off-by: Matthew Leach
Signed-off-by: Will Deacon
---
drivers/usb/musb/tusb6010.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
On Sat, Sep 03, 2016 at 12:16:29AM +0200, Peter Zijlstra wrote:
> On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote:
> > >
> > > Actually, that's not entirely true (although presumably it works okay
> > > for most archite
Hi all,
Although I don't think this is a new issue, booting mainline on my vexpress
a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
CPU being constantly 20-50% loaded. A bit of investigation shows that this
is due to the runtime-pm callbacks trying to autosuspend USB, des
Hi Alan,
On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
> > Consequently, I see a kworker thread on each CPU consuming a significant
> > amount of the system resources. Worse, if I enable something like kmemleak
> > (wh
On Thu, May 22, 2014 at 07:14:40PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
>
> > > Anyway, there are two possible ways of handling this. One is to avoid
> > > changing the error code to -EBUSY when the device in question is a root
> >
