linux-kernel - Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Nov 2014 18:47:42 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	balbi@...com, George Cherian <george.cherian@...com>
CC:	gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is
 fully handled

On 11/18/2014 10:17 PM, Felipe Balbi wrote:
> while this helps the situation it doesn't solve the problem I'm having
> with testusb on BBB when host port is connected to peripheral port on
> the same BBB.

Exactly. On the same device. I see the same problem if I connect host
to peripheral port on am335x-evm (as well as on BBB). I don't see this
if I connect cross-connect am335x-evm and BBB (no matter who plays
host).

> I still have:
> 
> # ./testusb -t 13 -c 10 -s 2048 -a
> unknown speed   /dev/bus/usb/002/004    0
> [  114.811407] usbtest 2-1:3.0: set altsetting to 0 failed, -71
> /dev/bus/usb/002/004 test 13 --> 71 (error 71)
> [  114.862387] CAUTION: musb: Babble Interrupt Occurred
> [  114.868132] usb 2-1: USB disconnect, device number 4
> [  114.961491] musb-hdrc musb-hdrc.1.auto: Restarting MUSB to recover from Babble
> [  115.430829] usb 2-1: new high-speed USB device number 5 using musb-hdrc
> [  115.573471] zero gadget: high-speed config #3: source/sink
> [  115.584014] usbtest 2-1:3.0: Linux gadget zero
> [  115.588682] usbtest 2-1:3.0: high-speed {control in/out bulk-in bulk-out} tests (+alt)
> 
> I think the driver is mis-detecting Babble. A babble only occurs when
> the device side tries to move data without the host asking for anything.

You receive a "set altsetting to 0 failed, -71" before you see the
babble. So either host or the device is not responding well. Too bad
both is on the same HW.

It might be, that the host is in sleep and it is not ready early enough.
I think that this somehow PM related because If I disable
CONFIG_PM_RUNTIME I don't see the problem anymore. So the babble event
looks valid even if under strange conditions.

And yes, the patch fixes the endless "Babble Interrupt" message and it
makes sense to keep the interrupts disabled until the device recovers
from the babble trouble.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/