Re: [PATCH 0/2] musb-fixes for v4.9-rc2

From: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
Cc: Bin Liu <b-liu-l0cyMroinI0@public.gmane.org>,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Subject: Re: [PATCH 0/2] musb-fixes for v4.9-rc2
Date: Fri, 04 Nov 2016 10:31:38 +0200	[thread overview]
Message-ID: <87r36rk5n9.fsf@linux.intel.com> (raw)
In-Reply-To: <20161103205902.GB21430-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161021 00:18]:
>> > > * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [161020 12:37]:
>> > > > [  186.457519] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_bcon (90, <VBusValid), retry #3, port1 0008010c
>> > > > 
>> > > > And that's the end, since now it does not react on hub plug/unplug.
>> > > > 
>> > > > Also all that VBUS_ERROR conditions are strange as hub is powered separately
>> > > > and power lines from phy are not used.
>> > > 
>> > > Hmm yeah. I'd like to be able to reproduce this. Can you email me
>> > > your .config (again)? You have things in host mode with a powered
>> > > hub plus few devices with no USB gadgets configured?
>> > 
>> > Well I found your earlier .config so presumably that did not change.
>> > Below patch seems to do the trick for me, but I need to test more.
>> > 
>> > Care to test if it helps for you? Please test with v4.9-rc2 and the
>> > following two fixes heading in Greg's usb-linus branch:
>> > 
>> > cacaaf80c3a6 ("usb: musb: Call pm_runtime from musb_gadget_queue")
>> > d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe lock order error")
>> 
>> tested with v4.9-rc3 which have these included.
>
> OK thanks.
>
>> > I'll send a proper patch if that works for you.
>> 
>> Unfortunately it's still the same. Direct connection (without hub) remains
>> untested as there's not enough power to supply display:
>> usb 2-1: USB disconnect, device number 2
>> usb 2-1: new high-speed USB device number 3 using musb-hdrc
>> usb 2-1: New USB device found, idVendor=17e9, idProduct=0335
>> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> usb 2-1: Product: MIMO
>> usb 2-1: Manufacturer: DisplayLink
>> usb 2-1: SerialNumber: 1071007195
>> usb 2-1: rejected 1 configuration due to insufficient available bus power
>> usb 2-1: no configuration chosen from 1 choice
>
> Hmm yeah playing with a hub connected devices don't always enumerate.
> When that happens, I get this:
>
> usb 1-1: reset high-speed USB device number 45 using musb-hdrc
> usb 1-1: reset high-speed USB device number 45 using musb-hdrc
> usb 1-1: reset high-speed USB device number 45 using musb-hdrc
> usb 1-1: USB disconnect, device number 45
> usb 1-1: new high-speed USB device number 47 using musb-hdrc
> usb 1-1: new high-speed USB device number 48 using musb-hdrc
> ...
>
> And that keeps on going until I reconnect the hub.

Sounds like VBUS dropping to me. Remember, MUSB is really anal about
VBUS levels. If it drops enough for the PHY to report one of those 4
VBUS levels, then MUSB just gives up.

What we used to do back at Nokia was disable reporting of some of those
VBUS levels at the PHY driver.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]