Merge tag 'staging-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

Pull staging tree changes from Greg Kroah-Hartman:
 "Here is the big staging tree pull request for the 3.5-rc1 merge
  window.

  Loads of changes here, and we just narrowly added more lines than we
  added:
   622 files changed, 28356 insertions(+), 26059 deletions(-)

  But, good news is that there is a number of subsystems that moved out
  of the staging tree, to their respective "real" portions of the
  kernel.

  Code that moved out was:
	- iio core code
	- mei driver
	- vme core and bridge drivers

  There was one broken network driver that moved into staging as a step
  before it is removed from the tree (pc300), and there was a few new
  drivers added to the tree:
	- new iio drivers
	- gdm72xx wimax USB driver
	- ipack subsystem and 2 drivers

  All of the movements around have acks from the various subsystem
  maintainers, and all of this has been in the linux-next tree for a
  while.

  Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"

Fixed up various trivial conflicts, along with a non-trivial one found
in -next and pointed out by Olof Johanssen: a clean - but incorrect -
merge of the arch/arm/boot/dts/at91sam9g20.dtsi file.  Fix up manually
as per Stephen Rothwell.

* tag 'staging-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (536 commits)
  Staging: bcm: Remove two unused variables from Adapter.h
  Staging: bcm: Removes the volatile type definition from Adapter.h
  Staging: bcm: Rename all "INT" to "int" in Adapter.h
  Staging: bcm: Fix warning: __packed vs. __attribute__((packed)) in Adapter.h
  Staging: bcm: Correctly format all comments in Adapter.h
  Staging: bcm: Fix all whitespace issues in Adapter.h
  Staging: bcm: Properly format braces in Adapter.h
  Staging: ipack/bridges/tpci200: remove unneeded casts
  Staging: ipack/bridges/tpci200: remove TPCI200_SHORTNAME constant
  Staging: ipack: remove board_name and bus_name fields from struct ipack_device
  Staging: ipack: improve the register of a bus and a device in the bus.
  staging: comedi: cleanup all the comedi_driver 'detach' functions
  staging: comedi: remove all 'default N' in Kconfig
  staging: line6/config.h: Delete unused header
  staging: gdm72xx depends on NET
  staging: gdm72xx: Set up parent link in sysfs for gdm72xx devices
  staging: drm/omap: initial dmabuf/prime import support
  staging: drm/omap: dmabuf/prime mmap support
  pstore/ram: Add ECC support
  pstore/ram: Switch to persistent_ram routines
  ...

1 files changed, 11 insertions, 5 deletions

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 8fb1ba7fe7bf..4ba7db231cb2 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
 Sergiu Iordache <sergiu@chromium.org>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
 0. Introduction
 
@@ -30,6 +30,11 @@ variable while setting 0 in that variable dumps only the panics.
 The module uses a counter to record multiple dumps but the counter gets reset
 on restart (i.e. new dumps after the restart will overwrite old ones).
 
+Ramoops also supports software ECC protection of persistent memory regions.
+This might be useful when a hardware reset was used to bring the machine back
+to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat
+corrupt, but usually it is restorable.
+
 2. Setting the parameters
 
 Setting the ramoops parameters can be done in 2 different manners:
@@ -38,7 +43,7 @@ Setting the ramoops parameters can be done in 2 different manners:
  2. Use a platform device and set the platform data. The parameters can then
  be set through that platform data. An example of doing that is:
 
-#include <linux/ramoops.h>
+#include <linux/pstore_ram.h>
 [...]
 
 static struct ramoops_platform_data ramoops_data = {
@@ -46,6 +51,7 @@ static struct ramoops_platform_data ramoops_data = {
         .mem_address            = <...>,
         .record_size            = <...>,
         .dump_oops              = <...>,
+        .ecc                    = <...>,
 };
 
 static struct platform_device ramoops_dev = {
@@ -71,6 +77,6 @@ timestamp and a new line. The dump then continues with the actual data.
 
 4. Reading the data
 
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.