linux-kernel - Re: [PATCH v3 0/6] 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]

Message-ID: <20121004124253.GC11149@beef>
Date:	Thu, 4 Oct 2012 08:42:53 -0400
From:	Matt Porter <mporter@...com>
To:	Philipp Zabel <pza@...gutronix.de>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>, Sekhar Nori <nsekhar@...com>,
	Ben Gardiner <bengardiner@...ometrics.ca>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Russell King <linux@....linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 0/6] uio_pruss cleanup and platform support

On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
> Hi Matt,
> 
> On 10/3/12, Matt Porter <mporter@...com> wrote:
> > This series enables uio_pruss on DA850 and removes use of the
> > private SRAM API by the driver. The driver previously was not
> > enabled by any platform and the private SRAM API was accessing
> > an invalid SRAM bank.
> 
> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
> "Add device tree support for on-chip SRAM" ?

Yes.

> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
> could be useful to map the L3RAM on Davinci.
> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
> uio_pruss driver could then use the gen_pool_find_by_phys() (or
> of_get_named_gen_pool() for initialization from device tree) to
> retrieve the struct gen_pool*.
> 
> This way you could avoid handing it over via platform data and you could
> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.

I did miss the gen_pool_find_by_phys() call in that series. That does
look useful. I actually mentioned your series in an earlier posting
since I like it, but since the initialization of the driver was inherently
tied to DT it's not usable for DaVinci that's just starting to convert
to DT and needs !DT support as well.

I do see it moving to your driver exclusively, but I wanted to make this
series focused on only getting rid of the private SRAM API using the
existing pdata framework that's already there. I think once
gen_pool_find_by_phys() goes upstream we can switch to that and get the
address from a resource in the !DT case. I guess we should see if Sekhar
would like to see this happen in two steps or just have us depend on
the gen_pool_find_by_phys() patch now.

BTW, I was going to post a patch for your driver to allow
configurability of the allocation order, but have been busy with other
things.  We'll eventually need that when switching to it as the
hardcoded page size order isn't going to work for all cases.

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