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: <B85A65D85D7EB246BE421B3FB0FBB593024CBA9959@dbde02.ent.ti.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ