From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E6B91DE27D for ; Thu, 27 Mar 2008 02:09:25 +1100 (EST) In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com> References: <200803101606.39184.laurentp@cse-semaphore.com> <200803251823.32039.laurentp@cse-semaphore.com> <200803251914.24021.laurentp@cse-semaphore.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: OF compatible MTD platform RAM driver ? Date: Wed, 26 Mar 2008 16:06:45 +0100 To: Laurent Pinchart Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > So we're left with two main options. > > - Reusing the nvram device type from the Device Support Extensions. This wouldn't bring you anything. A device_type is only used internally by OF, to decide what device nodes support which OF programming model. If you only have a flat device tree, "device_type" should be used only as a workaround for older kernels that require it. > - Using another device node with a compatible value set to > "linear-ram" (or > something similar). This would support both volatile and non-volatile > devices, and a property could be added to specify if the device is > volatile > or not. "memory-mapped-memory" perhaps :-) Or, just "memory". Although that one might play havoc with some not-quite-correct main memory probing code. Segher