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]

Date:	Mon, 2 Dec 2013 17:12:43 +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 04:03 PM, Sebastian Andrzej Siewior wrote:
> 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".
> 

We are already telling hwmod to not use smart-idle or smart-standby.
So the device is always put in no-idle,no-standby during resume and force-idle,force-standby
during suspend.

I'll send a new patch to remove "do-not-reset" flag from hwmod data and then we
don't need this patch.

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/