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: <alpine.DEB.2.02.1312021444530.18363@utopia.booyaka.com>
Date:	Mon, 2 Dec 2013 15:00:03 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	Roger Quadros <rogerq@...com>
cc:	Michael Trimarchi <michael@...rulasolutions.com>,
	Lee Jones <lee.jones@...aro.org>, sameo@...ux.intel.com,
	tomi.valkeinen@...com, Felipe Balbi <balbi@...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, stable@...r.kernel.org,
	Benoit Cousson <bcousson@...libre.com>,
	"tony@...mide.com" <tony@...mide.com>
Subject: Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems
 on OMAP4 Panda

On Mon, 2 Dec 2013, Roger Quadros wrote:

> It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the 
> hwmod data [1].
> 
> Question is do we do it in the driver of leave it to hwmod?

It should be done by hwmod (or more broadly, some OMAP bus code).  That 
way the device can be brought to a known state even if there's no driver 
present (e.g., if the driver was built as a module).

> The other concern about i660 is in this comment [1]
> 
> 	/*
> 	 * During system boot; If the hwmod framework resets the module
> 	 * the module will have smart idle settings; which can lead to deadlock
> 	 * (above Errata Id:i660); so, dont reset the module during boot;
> 	 * Use HWMOD_INIT_NO_RESET.
> 	 */
> 
> But if you look at the errata document [2], Advisory 1.108, it doesn't 
> say that we can't be in smart-idle, but only that we should put the 
> module in force-idle, before cutting the module's functional clock.

Yes, that looks to be correct.  There shouldn't be any problem with the 
module being in smart-idle mode if the PRCM doesn't try to put it into a 
low-power mode.  It already has the HWMOD_SWSUP_SIDLE flag set, so seems 
to me it should work fine without HWMOD_INIT_NO_RESET, if i660 is the only 
issue.

Most of the IP blocks that are marked with HWMOD_INIT_NO_RESET are only 
that way due to laziness, or lack of time, etc., and should be closely 
reviewed.


- Paul
--
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/