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 for Android: free password hash cracker in your pocket

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

Message-ID: <529C9343.3010000@linutronix.de>
Date:	Mon, 02 Dec 2013 15:03:47 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Roger Quadros <rogerq@...com>
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 02:44 PM, Roger Quadros wrote:
> "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.

If u-boot configured USB into something not smart-idle and the reset
would bring it back then the reset should remain.
If you could tell hwmod not use smart-idle nor smart-standby and you
make sure that the suspend code manually puts the device into suspend
via forceidle then I think could get rid of the "do-not-reset-thingy".

> 
> cheers,
> -roger
> 

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/