linux-kernel - Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

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] [day] [month] [year] [list]

Message-ID: <56F386AE.5000306@synopsys.com>
Date:	Wed, 23 Mar 2016 23:18:22 -0700
From:	John Youn <John.Youn@...opsys.com>
To:	Doug Anderson <dianders@...omium.org>,
	John Youn <John.Youn@...opsys.com>
CC:	Stefan Wahren <stefan.wahren@...e.com>,
	Michael Niewoehner <linux@...ewoehner.de>,
	Tao Huang <huangtao@...k-chips.com>,
	Julius Werner <jwerner@...omium.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Caesar Wang <caesar.upstream@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Felipe Balbi <balbi@...nel.org>,
	Remi Pommarel <repk@...plefau.lt>,
	Kever Yang <kever.yang@...k-chips.com>
Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

On 3/22/2016 12:44 PM, Doug Anderson wrote:
> John,
> 
> On Tue, Mar 22, 2016 at 12:26 PM, John Youn <John.Youn@...opsys.com> wrote:
>> Thanks for the debug logs and everyones help.
>>
>> After reviewing with our hardware engineers, it seems this is likely
>> to do with the IDDIG debounce filtering when switching between
>> modes. You can see if this is enabled in your core by checking
>> GHWCFG4.IddgFltr.
>>
>> From the databook:
>>
>>     OTG_EN_IDDIG_FILTER
>>
>>     Specifies whether to add a filter on the "iddig" input from the
>>     PHY. If your PHY already has a filter on iddig for de-bounce, then
>>     it is not necessary to enable the one in the DWC_otg.  The filter
>>     is implemented in the DWC_otg_wpc module as a 20-bit counter that
>>     works on the PHY clock. In the case of the UTMI+ PHY, this pin is
>>     from the PHY. In the case of the ULPI PHY, this signal is
>>     generated by the ULPI Wrapper inside the core.
>>
>>
>> This only affects OTG cores and the delay is 10ms for 30MHz PHY clock
>> and 50ms with a 6MHz PHY clock.
> 
> Wow, nice to have it so perfectly explained!  :)
> 
> 
>> The reason we see this after a reset is that by default the IDDIG
>> indicates device mode. But if the id pin is set to host the core will
>> immediately detect it after the reset and trigger the filtering delay
>> before changing to host mode.
>>
>> This delay is also triggered by force mode. This is the origin of the
>> 25 ms delay specified in the databook. The databook did not take into
>> account that there might be a 6MHz clock so this delay could actually
>> be up to 50 ms. So we aren't delaying enough time for those cases.
>>
>> I think this explains all the problems and platform differences we are
>> seeing related to this.
>>
>> I think we can just add an IDDIG delay after a force mode, a clear
>> force mode, and any time after reset where we don't do either a force
>> or clear force mode immediately afterwards. Maybe set the delay time
>> via a core parameter or measure it once on probe. Or we can probably
>> just poll for the mode change in all of the above conditions.
> 
> The driver seems to be able to figure out the PHY clock in most cases
> in dwc2_calc_frame_interval().  It doesn't seem to handle 6MHz there,
> though.  I wonder if that's another bug?
> 

The 6 MHz is from a dedicated FS PHY operating at low speed. So that
must be the case for the platforms showing 50 ms delay.

> Polling seems fine too, though.

I'm thinking that's the way to go as it can be troublesome to figure
out the correct PHY clock speed.

Regards,
John