linux-kernel - RE: [PATCH v4 08/11] tty: add pruss SUART driver

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:	Wed, 27 Apr 2011 16:49:02 +0530
From:	"Nori, Sekhar" <nsekhar@...com>
To:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	Greg KH <gregkh@...e.de>
CC:	Greg KH <greg@...ah.com>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Watkins, Melissa" <m-watkins@...com>,
	"sachi@...tralsolutions.com" <sachi@...tralsolutions.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 08/11] tty: add pruss SUART driver

On Wed, Apr 27, 2011 at 10:53:38, Subhasish Ghosh wrote:
> >> There should be no build time dependency with this patch
> >> (the above patch just changes which pool of SRAM the
> >> allocation happens from)
> >>
> >> But, this brings out an important dependency of the patch
> >> calling platform specific sram allocator functions. There
> >> has been SRAM allocator consolidation work done by Russell
> >> and as a result the SRAM allocator API for DaVinci will
> >> actually change.
> 
> I earlier had an implementation where I would get the sram memory addresses
> through the .resource structure and ioremap it in the driver.

This is wrong since it assumes the whole SRAM is available
for usage by your driver. We already have an allocator
for SRAM.

> 
> >>The driver should probably just get sram
> >> space through platform data so that it doesn't depend on the
> >> platform specific sram allocation function.
> 
> Are you suggesting that I go back to that implementation.

No, the platform code should use the SRAM allocator and
pass on the allocated memory to the driver.

Thanks,
Sekhar

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