linux-kernel - Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

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:	Sat, 29 Sep 2012 18:34:54 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	Matt Porter <mporter@...com>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Benoit Cousson <b-cousson@...com>,
	Sekhar Nori <nsekhar@...com>, Tony Lindgren <tony@...mide.com>,
	Russell King <linux@....linux.org.uk>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	omar.luna@...aro.org
Subject: Re: [PATCH v2 0/7] uio_pruss cleanup and platform support


cc Omar

Hi Matt

On Fri, 28 Sep 2012, Matt Porter wrote:

> The AM33xx support requires some help in hwmod due to the following
> comment in arch/arm/mach-omap2/omap_hwmod.c:
> 	/*
> 	 * If an IP block contains HW reset lines and any of them are
> 	 * asserted, we let integration code associated with that
> 	 * block handle the enable.  We've received very little
> 	 * information on what those driver authors need, and until
> 	 * detailed information is provided and the driver code is
> 	 * posted to the public lists, this is probably the best we
> 	 * can do.
> 	 */
> 
> The approach to deal with the hardware reset (for at least the pruss
> hwmod) was to add a generic omap property to properly define this
> hardware. The implementation simply deasserts any rst lines that
> are called out in the property when the omap_device is
> instantiated. This is not the ideal implementation as the sequence is
> a bit wrong for pruss since the busy check during the hard reset
> will fail, even though it fails in a benign manner. Ideally, we would
> want the implementation to observe the ti,deassert-hard-reset property
> and use that in omap_hwmod.c:_enable() *after* the module is unidled
> and the clocks active. However, this is actually functional for purposes
> of getting the uio_pruss driver up and running.

Could you please sync with Omar on the hard reset handling?  He posted 
some patches that change the hard reset code.  Perhaps you can align on an 
approach with him?

A few general comments: if some new per-IP block flag is needed to control 
this, the best place for it right now would be the hwmod data in 
arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT.  At some point 
soon, the hard reset handling will be split between a PRM driver and some 
hwmod bus driver, and it seems best to deal with the DT binding question 
at that time.  That way we don't wind up with a legacy binding that has to 
be supported over the long term.


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