From: Segher Boessenkool <segher@kernel.crashing.org>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org,
Rune Torgersen <runet@innovsys.com>,
linux-mtd@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Wed, 26 Mar 2008 16:06:45 +0100 [thread overview]
Message-ID: <b06db7bb4932d14f8af9547abdfc9d0d@kernel.crashing.org> (raw)
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Wed, 26 Mar 2008 16:06:45 +0100 [thread overview]
Message-ID: <b06db7bb4932d14f8af9547abdfc9d0d@kernel.crashing.org> (raw)
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
> 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
next prev parent reply other threads:[~2008-03-26 15:09 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-10 15:06 OF compatible MTD platform RAM driver ? Laurent Pinchart
2008-03-10 17:00 ` Rune Torgersen
2008-03-10 17:00 ` Rune Torgersen
2008-03-11 0:45 ` David Gibson
2008-03-11 0:45 ` David Gibson
2008-03-11 10:39 ` Laurent Pinchart
2008-03-11 10:39 ` Laurent Pinchart
2008-03-11 22:40 ` David Gibson
2008-03-25 14:36 ` Laurent Pinchart
2008-03-25 15:29 ` Sergei Shtylyov
2008-03-25 15:51 ` Laurent Pinchart
2008-03-25 16:23 ` Sergei Shtylyov
2008-03-25 16:44 ` Laurent Pinchart
2008-03-25 17:02 ` Sergei Shtylyov
2008-03-25 17:23 ` Laurent Pinchart
2008-03-25 17:37 ` Sergei Shtylyov
2008-03-25 17:56 ` Rune Torgersen
2008-03-25 17:56 ` Rune Torgersen
2008-03-25 18:14 ` Laurent Pinchart
2008-03-25 18:14 ` Laurent Pinchart
2008-03-26 12:53 ` Sergei Shtylyov
2008-03-26 12:53 ` Sergei Shtylyov
2008-03-27 9:13 ` Laurent Pinchart
2008-03-27 9:13 ` Laurent Pinchart
2008-03-27 10:03 ` David Gibson
2008-03-27 10:03 ` David Gibson
2008-03-27 12:23 ` Sergei Shtylyov
2008-03-27 12:23 ` Sergei Shtylyov
2008-03-28 0:07 ` David Gibson
2008-03-28 0:07 ` David Gibson
2008-03-28 12:31 ` Sergei Shtylyov
2008-03-28 12:31 ` Sergei Shtylyov
2008-03-27 14:31 ` Laurent Pinchart
2008-03-27 14:31 ` Laurent Pinchart
2008-03-28 0:09 ` David Gibson
2008-03-30 18:15 ` Segher Boessenkool
2008-03-30 18:15 ` Segher Boessenkool
2008-03-30 21:16 ` Paul Mackerras
2008-03-30 22:39 ` Segher Boessenkool
2008-03-31 0:42 ` Paul Mackerras
2008-03-31 0:59 ` Segher Boessenkool
2008-03-31 1:24 ` Segher Boessenkool
2008-03-31 8:21 ` Laurent Pinchart
2008-03-31 8:21 ` Laurent Pinchart
2008-03-31 12:21 ` Segher Boessenkool
2008-03-26 15:06 ` Segher Boessenkool [this message]
2008-03-26 15:06 ` Segher Boessenkool
2008-03-26 15:40 ` Sergei Shtylyov
2008-03-26 15:40 ` Sergei Shtylyov
2008-03-27 9:24 ` Laurent Pinchart
2008-03-27 9:24 ` Laurent Pinchart
2008-03-30 18:12 ` Segher Boessenkool
2008-03-30 18:12 ` Segher Boessenkool
2008-03-26 15:09 ` Segher Boessenkool
2008-03-26 15:09 ` Segher Boessenkool
2008-03-11 15:00 ` Rune Torgersen
2008-03-11 15:00 ` Rune Torgersen
2008-03-11 22:41 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b06db7bb4932d14f8af9547abdfc9d0d@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=ben@simtec.co.uk \
--cc=david@gibson.dropbear.id.au \
--cc=laurentp@cse-semaphore.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=runet@innovsys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.