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-next>] [day] [month] [year] [list]
Date:	Tue,  5 Jun 2012 13:23:13 -0700
From:	Bryan Freed <bfreed@...omium.org>
To:	linux-kernel@...r.kernel.org
Cc:	keescook@...omium.org, marco.stornelli@...il.com,
	grant.likely@...retlab.ca, anton.vorontsov@...aro.org,
	Bryan Freed <bfreed@...omium.org>
Subject: [PATCH v2] pstore/ram: Add ramoops support for the Flattened Device Tree.

When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT interface.

Signed-off-by: Bryan Freed <bfreed@...omium.org>
---
 Documentation/ramoops.txt |   19 +++++++++++++++-
 fs/pstore/ram.c           |   50 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 4ba7db2..9ed3ab7 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
 Sergiu Iordache <sergiu@...omium.org>
 
-Updated: 17 November 2011
+Updated: 5 June 2012
 
 0. Introduction
 
@@ -37,7 +37,7 @@ corrupt, but usually it is restorable.
 
 2. Setting the parameters
 
-Setting the ramoops parameters can be done in 2 different manners:
+Setting the ramoops parameters can be done in 3 different manners:
  1. Use the module parameters (which have the names of the variables described
  as before).
  2. Use a platform device and set the platform data. The parameters can then
@@ -70,6 +70,21 @@ if (ret) {
 	return ret;
 }
 
+ 3. Use the Flattened Device Tree to set the platform data.  For example:
+  arch/arm/boot/dts/$BOARD.dts:
+        ramoops {
+                compatible = "ramoops";
+                reg = <0x41f00000 0x00100000>;
+                record-size = <0x00020000>;
+                dump-oops = <1>;
+                ecc = <0>;
+        };
+ The "reg = <0x41f00000 0x00100000>" line specifies a mem_size of 1MB at
+  mem_address 0x41f00000.
+ The "record-size = <0x00020000>" line specifies a record size of 128KB.
+ The "dump-oops = <1>" line tells us to dump oopses as well as panics.
+ The "ecc = <0>" line tells us to turn off ECC protection.
+
 3. Dump format
 
 The data dump begins with a header, currently defined as "====" followed by a
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 9123cce..1b44be3 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -32,6 +32,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/pstore_ram.h>
+#include <linux/of_address.h>
 
 #define RAMOOPS_KERNMSG_HDR "===="
 #define MIN_MEM_SIZE 4096UL
@@ -199,10 +200,44 @@ static struct ramoops_context oops_cxt = {
 	},
 };
 
+static int __init of_ramoops_platform_data(struct device_node *node,
+					struct ramoops_platform_data *pdata)
+{
+	const __be32 *addrp;
+	const __be32 *prop;
+	u64 size;
+
+	addrp = of_get_address(node, 0, &size, NULL);
+	if (addrp == NULL)
+		return -EINVAL;
+	pdata->mem_address = of_translate_address(node, addrp);
+	pdata->mem_size = size;
+
+	prop = of_get_property(node, "record-size", NULL);
+	if (!prop)
+		return -EINVAL;
+	pdata->record_size = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "dump-oops", NULL);
+	if (!prop)
+		pdata->dump_oops = 0;
+	else
+		pdata->dump_oops = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "ecc", NULL);
+	if (!prop)
+		pdata->ecc = 0;
+	else
+		pdata->ecc = be32_to_cpup(prop);
+
+	return 0;
+}
+
 static int __init ramoops_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct ramoops_platform_data *pdata = pdev->dev.platform_data;
+	struct ramoops_platform_data of_pdata;
 	struct ramoops_context *cxt = &oops_cxt;
 	int err = -EINVAL;
 	int i;
@@ -213,6 +248,14 @@ static int __init ramoops_probe(struct platform_device *pdev)
 	if (cxt->max_count)
 		goto fail_out;
 
+	if (pdev->dev.of_node) {
+		if (of_ramoops_platform_data(pdev->dev.of_node, &of_pdata)) {
+			pr_err("Invalid ramoops device tree data\n");
+			goto fail_out;
+		}
+		pdata = &of_pdata;
+	}
+
 	if (!pdata->mem_size || !pdata->record_size) {
 		pr_err("The memory size and the record size must be "
 			"non-zero\n");
@@ -329,11 +372,18 @@ static int __exit ramoops_remove(struct platform_device *pdev)
 	return -EBUSY;
 }
 
+static const struct of_device_id ramoops_of_match[] = {
+	{ .compatible = "ramoops", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ramoops_of_match);
+
 static struct platform_driver ramoops_driver = {
 	.remove		= __exit_p(ramoops_remove),
 	.driver		= {
 		.name	= "ramoops",
 		.owner	= THIS_MODULE,
+		.of_match_table = ramoops_of_match,
 	},
 };
 
-- 
1.7.7.3

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