linux-kernel - Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

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]

Message-ID: <529C8ED0.6060805@ti.com>
Date:	Mon, 2 Dec 2013 15:44:48 +0200
From:	Roger Quadros <rogerq@...com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:	Michael Trimarchi <michael@...rulasolutions.com>,
	Felipe Balbi <balbi@...com>, <lee.jones@...aro.org>,
	<sameo@...ux.intel.com>, <tomi.valkeinen@...com>,
	Stefan Roese <sr@...x.de>, <ljkenny.mailinglists@...il.com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems
 on OMAP4 Panda

On 12/02/2013 03:39 PM, Sebastian Andrzej Siewior wrote:
> On 12/02/2013 02:35 PM, Roger Quadros wrote:
>>> It refers to "Errata Id:i660" why it is required. Once you figured what
>>> why it has been added you could have an idea if it is okay to remove it
>>> and if the reset you do here might lead to it (I dunno).
>>>
>>
>> Keshava no longer works @TI. I have no other means to check why it was added
>> other than doing dome tests and making sure nothing breaks if we remove it.
>>
>> So far, things are going fine for about 50 or so boots divided between OMAP3 and 4
>> platforms. If more people can test and give feedback it'd be great.
> 
> Hmm. Can't you lookup the errata he revers to?
> 

Sure, but it was not making sense why RESET was avoided.
It doesn't say anything about not using RESET. In fact it says that RESET _is_ the
recovery procedure.

Pasting the errata description below for easy reference.

"Errata id: i660
DESCRIPTION
In the following configuration :
• USBHOST module is set to smart-idle mode
• PRCM asserts idle_req to the USBHOST module. (This typically happens when the system is going to
a low power mode : all ports have been suspended, the master part of the USBHOST module has
entered the standby state, and SW has cut the functional clocks.)
• an USBHOST interrupt occurs before the module is able to answer idle_ack, typically a remote wakeup
IRQ.
Then the USB HOST module will enter a deadlock situation where it is no more accessible nor functional.
The only way to recover will be to perform a software reset of the module.

WORKAROUND
The best workaround consists in switching the module to force idle mode right before cutting the
module's FCLK.
• the bus has reached the suspend state.
• write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has been taken into
account in case of posted writes.
• cut the FCLK
• Idle_req will be asserted and idle_ack answered within one L3 clock cycle.
Upon resume or remote wakeup, switch back the module to smart-idle.
This workaround reduces the failure window to only one L3 clock cycle. The probability for an interrupt to
fire at this exact time is considered extremely low, and the case has never been hit on board."

Based on this, I don't see anything wrong in Resetting the module at probe or at boot.

cheers,
-roger
--
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/