misc: atmel-secumod: Driver for Atmel "security module".

From: David Mosberger <[email protected]>

SAMA5D2 (and perhaps other SOCs) implements a secure module which hosts a battery-backed SRAM with is sectioned into three different areas with different properties: a 4KiB auto-erasable secure RAM, a 1KiB non-auto-eraseable secure RAM, and 32 bytes of (non-secure) RAM.

This driver provides (minimal) access to these RAM areas through sysfs. For example, adding this to the DTS:

	secumod at fc040000 {
		compatible = "atmel,sama5d2-secumod";
		reg = <0xfc040000 0x4000>;
		status = "okay";

		#address-cells = <1>;
		#size-cells = <1>;

		secram_auto_erasable at f8044000 {
			reg = <0xf8044000 0x1000>;
		};
		secram at f8045000 {
			reg = <0xf8045000 0x400>;
		};
		ram at f8045400 {
			reg = <0xf8045400 0x20>;
		};
	};

would provide binary files "ram", "secram", and "secram_auto_erasable" in directory /sys/bus/platform/devices/fc040000.secumod. This files can then be read or written with any user-level tool.

The driver is minimal in the sense that it doesn't provide (yet) a way to manage scrambling keys etc.

Signed-off-by David Mosberger <[email protected]>

---
 arch/arm/boot/dts/sama5d2.dtsi |  19 ++++
 drivers/misc/Kconfig           |   7 ++
 drivers/misc/Makefile          |   1 +
 drivers/misc/atmel-secumod.c   | 224 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 251 insertions(+)
 create mode 100644 drivers/misc/atmel-secumod.c

arch/arm/boot/dts/sama5d2.dtsi +19 -0

index 89d4de8..d4bd3b6 100644
@@ -1239,6 +1239,25 @@
 				clocks = <&pioA_clk>;
 			};
 
+			secumod at fc040000 {
+				compatible = "atmel,sama5d2-secumod";
+				reg = <0xfc040000 0x4000>;
+				status = "okay";
+
+				#address-cells = <1>;
+				#size-cells = <1>;
+
+				secram_auto_erasable at f8044000 {
+					reg = <0xf8044000 0x1000>;
+				};
+				secram at f8045000 {
+					reg = <0xf8045000 0x400>;
+				};
+				ram at f8045400 {
+					reg = <0xf8045400 0x20>;
+				};
+			};
+
 			tdes at fc044000 {
 				compatible = "atmel,at91sam9g46-tdes";
 				reg = <0xfc044000 0x100>;

drivers/misc/Kconfig +7 -0

index 006242c..74a8ee5 100644
@@ -84,6 +84,13 @@ config ATMEL_TCB_CLKSRC_BLOCK
 	  TC can be used for other purposes, such as PWM generation and
 	  interval timing.
 
+config ATMEL_SECUMOD
+       tristate "Atmel Secure Module driver"
+       depends on ARCH_AT91
+       help
+         Select this to get support for the secure module (SECUMOD) built
+	 into the SAMA5D2 chips.
+
 config DUMMY_IRQ
 	tristate "Dummy IRQ handler"
 	default n

drivers/misc/Makefile +1 -0

index 7d5c4cd..e1f661d 100644
@@ -9,6 +9,7 @@ obj-$(CONFIG_AD525X_DPOT_SPI)	+= ad525x_dpot-spi.o
 obj-$(CONFIG_INTEL_MID_PTI)	+= pti.o
 obj-$(CONFIG_ATMEL_SSC)		+= atmel-ssc.o
 obj-$(CONFIG_ATMEL_TCLIB)	+= atmel_tclib.o
+obj-$(CONFIG_ATMEL_SECUMOD)	+= atmel-secumod.o
 obj-$(CONFIG_BMP085)		+= bmp085.o
 obj-$(CONFIG_BMP085_I2C)	+= bmp085-i2c.o
 obj-$(CONFIG_BMP085_SPI)	+= bmp085-spi.o

drivers/misc/atmel-secumod.c new file +224 -0

new file mode 100644
index 0000000..5ac1a18
@@ -0,0 +1,224 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+
+#include <asm/io.h>
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY	0x0014
+
+struct ram_area {
+	struct list_head next;
+	void *regs;	/* ioremapped RAM area */
+	size_t size;	/* size in bytes */
+	struct bin_attribute attr;
+};
+
+struct secumod_device {
+	struct spinlock lock;
+	void __iomem *regs;		/* ioremapped SECUMOD registers */
+	struct platform_device *pdev;
+	struct list_head ram_areas;
+};
+
+static ssize_t
+secumod_ram_write(struct file *filp, struct kobject *kobj,
+		  struct bin_attribute *attr,
+		  char *buf, loff_t off, size_t count)
+{
+	struct ram_area *ram = attr->private;
+	struct device *dev = kobj_to_dev(kobj);
+	struct platform_device *pdev = to_platform_device(dev);
+	struct secumod_device *secumod = platform_get_drvdata(pdev);
+
+	if (off < 0 || off >= ram->size)
+		return -EINVAL;
+	if (off + count > ram->size)
+		count = ram->size = off;
+
+	if (count > 0) {
+		spin_lock(&secumod->lock);
+		memcpy_toio(ram->regs + off, buf, count);
+		spin_unlock(&secumod->lock);
+	}
+	return count;
+}
+
+static ssize_t
+secumod_ram_read(struct file *filp, struct kobject *kobj,
+		 struct bin_attribute *attr,
+		 char *buf, loff_t off, size_t count)
+{
+	struct ram_area *ram = attr->private;
+	struct device *dev = kobj_to_dev(kobj);
+	struct platform_device *pdev = to_platform_device(dev);
+	struct secumod_device *secumod = platform_get_drvdata(pdev);
+
+	if (off < 0 || off >= ram->size)
+		return -EINVAL;
+	if (off + count > ram->size)
+		count = ram->size = off;
+
+	if (count > 0) {
+		spin_lock(&secumod->lock);
+		memcpy_fromio(buf, ram->regs + off, count);
+		spin_unlock(&secumod->lock);
+	}
+	return count;
+}
+
+static void
+secumod_register_ram(struct secumod_device *secumod,
+		     const char *name, unsigned long addr, size_t size)
+{
+	struct device *dev = &secumod->pdev->dev;
+	struct ram_area *ram;
+	int ret;
+
+	ram = devm_kzalloc(dev, sizeof(*ram), GFP_KERNEL);
+	if (!ram) {
+		dev_err(dev, "Out of memory for RAM area %s\n", name);
+		return;
+	}
+	INIT_LIST_HEAD(&ram->next);
+	ram->size = size;
+	ram->regs = ioremap_nocache(addr, size);
+	ram->attr.attr.name = name;
+	ram->attr.attr.mode = S_IRUGO | S_IWUSR;
+	ram->attr.private = ram;
+	ram->attr.size = size;
+	ram->attr.read = secumod_ram_read;
+	ram->attr.write = secumod_ram_write;
+	ret = device_create_bin_file(dev, &ram->attr);
+	if (ret) {
+		dev_err(dev, "Failed to register RAM area %s (%d)", name, ret);
+		return;
+	}
+	spin_lock(&secumod->lock);
+	list_add_tail(&ram->next, &secumod->ram_areas);
+	spin_unlock(&secumod->lock);
+	pr_info("atmel-secumod: RAM 0x%08lx-0x%08lx (%s)\n",
+		addr, addr + size - 1, name);
+}
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (struct secumod_device *secumod)
+{
+	unsigned long start, stop;
+
+	start = jiffies;
+	while (!(readl(secumod->regs + SECUMOD_RAMRDY) & 1))
+		msleep_interruptible(1);
+	stop = jiffies;
+	if (stop != start)
+		pr_info("atmel-secumod: it took %u msec for SECUMOD "
+			"to become ready...\n", jiffies_to_msecs(stop - start));
+}
+
+static int
+secumod_probe(struct platform_device *pdev)
+{
+	struct secumod_device *secumod;
+	struct device_node *child;
+	struct resource *regs;
+	u32 addr, size;
+	const void *pv;
+	int len;
+
+	secumod = devm_kzalloc(&pdev->dev, sizeof(*secumod), GFP_KERNEL);
+	if (!secumod) {
+		dev_err(&pdev->dev, "out of memory\n");
+		return -ENOMEM;
+	}
+	spin_lock_init(&secumod->lock);
+	INIT_LIST_HEAD(&secumod->ram_areas);
+
+	if (!pdev->dev.of_node) {
+		dev_err(&pdev->dev, "Missing of_node attribute\n");
+		return -ENODEV;
+	}
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!regs) {
+		dev_err(&pdev->dev, "Missing secumod resources.\n");
+		return -ENODEV;
+	}
+	secumod->pdev = pdev;
+	secumod->regs = devm_ioremap_resource(&pdev->dev, regs);
+
+	platform_set_drvdata(pdev, secumod);
+
+	for_each_child_of_node(pdev->dev.of_node, child) {
+		pv = of_get_property(child, "reg", &len);
+		if (!pv ||
+		    of_n_addr_cells(child) != 1 ||
+		    of_n_size_cells(child) != 1) {
+			dev_err(&pdev->dev, "Node %s missing \"reg\" property "
+				"or incorrect address/size count.",
+				child->name);
+			return -ENODEV;
+		}
+		addr = be32_to_cpup(pv);
+		size = be32_to_cpup(pv + 4);
+		secumod_register_ram(secumod, child->name, addr, size);
+	}
+	secumod_wait_ready(secumod);
+	return 0;
+}
+
+static int
+secumod_remove(struct platform_device *pdev)
+{
+	struct secumod_device *secumod = platform_get_drvdata(pdev);
+	struct ram_area *ram;
+
+	spin_lock(&secumod->lock);
+	list_for_each_entry(ram, &secumod->ram_areas, next)
+		device_remove_bin_file(&pdev->dev, &ram->attr);
+	spin_unlock(&secumod->lock);
+	return 0;
+}
+
+static const struct of_device_id secumod_dt_ids[] = {
+	{
+		.compatible = "atmel,sama5d2-secumod"
+	},
+	{
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, secumod_dt_ids);
+
+static struct platform_driver secumod_driver = {
+	.driver = {
+		.name = "atmel-secumod",
+		.of_match_table = of_match_ptr(secumod_dt_ids),
+	},
+	.probe		= secumod_probe,
+	.remove		= secumod_remove
+};
+module_platform_driver(secumod_driver);
+
+MODULE_AUTHOR("David Mosberger <[email protected]>");
+MODULE_DESCRIPTION("Atmel SAMA5D2 secure module driver");
+MODULE_LICENSE("GPL v2");

Signature · 7 lines

1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

I know this does more than that but I think those thre sections should be registered using the nvmem framework. The sysfs file creation and accesses then comes for free.

Another idea is also to expose it using a genpool so it can be accessed as sram from inside the kernel.

Quoted 3 lines · Alexandre Belloni

I know this does more than that but I think those thre sections should be registered using the nvmem framework. The sysfs file creation and accesses then comes for free.

I think Finn's patches would have to go in for that first, since the existing nvram code is a mess. Even with Finn's patches in, I think it could go either way.

I'm not exactly sure how some of the features of the security module would be used: key management, auto erasing, there is a strange "backup mode" vs "normal mode" which is not well documented, etc. So I think it may well end up being sufficiently different to warrant a separate driver.

Quoted 3 lines

Another idea is also to expose it using a genpool so it can be accessed as sram from inside the kernel.

That may be a fine idea, but as far as our application is concerned, we need user-level access to the battery-backed RAM.

Best regards,

--david

Quoted 7 lines · David Mosberger

Quoted 3 lines · Alexandre Belloni

I know this does more than that but I think those thre sections should be registered using the nvmem framework. The sysfs file creation and accesses then comes for free.

Quoted 3 lines

I think Finn's patches would have to go in for that first, since the existing nvram code is a mess. Even with Finn's patches in, I think it could go either way.

I think Alexandre is speaking of the nvmem subsystem (not nvram). Documentation/devicetree/bindings/nvmem Documentation/nvmem
drivers/nvmem

Quoted 5 lines

I'm not exactly sure how some of the features of the security module would be used: key management, auto erasing, there is a strange "backup mode" vs "normal mode" which is not well documented, etc. So I think it may well end up being sufficiently different to warrant a separate driver.

nvmem is not a subsystem I am familiar with, so it's not immediately clear to me what your driver would look like if re-written that way.

Maybe it would become simpler. But if you did end up needing a separate misc driver as well, maybe use of the nvmem framework would actually increase complexity.

It would depend on your requirements. But I would focus on the actual requirement rather than uncertain future possibilities.

Quoted 1 line

Quoted 5 lines

Quoted 2 lines

Another idea is also to expose it using a genpool so it can be accessed as sram from inside the kernel.

That may be a fine idea, but as far as our application is concerned, we need user-level access to the battery-backed RAM.

Right. I don't see how adding a memory allocator would help either.

Quoted 10 lines · Finn Thain

Quoted 7 lines · David Mosberger

Quoted 3 lines · Alexandre Belloni

I know this does more than that but I think those thre sections should be registered using the nvmem framework. The sysfs file creation and accesses then comes for free.

Quoted 9 lines

Quoted 3 lines

I think Finn's patches would have to go in for that first, since the existing nvram code is a mess. Even with Finn's patches in, I think it could go either way.

I think Alexandre is speaking of the nvmem subsystem (not nvram). Documentation/devicetree/bindings/nvmem Documentation/nvmem
drivers/nvmem

absolutely.

Quoted 23 lines

Quoted 5 lines

I'm not exactly sure how some of the features of the security module would be used: key management, auto erasing, there is a strange "backup mode" vs "normal mode" which is not well documented, etc. So I think it may well end up being sufficiently different to warrant a separate driver.

nvmem is not a subsystem I am familiar with, so it's not immediately clear to me what your driver would look like if re-written that way.

Maybe it would become simpler. But if you did end up needing a separate misc driver as well, maybe use of the nvmem framework would actually increase complexity.

It would depend on your requirements. But I would focus on the actual requirement rather than uncertain future possibilities.

Quoted 6 lines

Quoted 3 lines

Another idea is also to expose it using a genpool so it can be accessed as sram from inside the kernel.

That may be a fine idea, but as far as our application is concerned, we need user-level access to the battery-backed RAM.

Quoted 2 lines

Right. I don't see how adding a memory allocator would help either.

While the immediate need is to use that sram from userspace, I think this is valuable to already think that at some point we will need to be able to partition and access that sram from the kernel.

Hi David,

Sorry for the late review (I know you've posted new versions but I want to comment on this one).

Quoted 46 lines · On Sun, 31 Jan 2016 12:34:09 +0100 Alexandre Belloni…

Quoted 10 lines · Finn Thain

Quoted 7 lines · David Mosberger

Quoted 3 lines · Alexandre Belloni

I know this does more than that but I think those thre sections should be registered using the nvmem framework. The sysfs file creation and accesses then comes for free.

Quoted 9 lines

Quoted 3 lines

I think Finn's patches would have to go in for that first, since the existing nvram code is a mess. Even with Finn's patches in, I think it could go either way.

I think Alexandre is speaking of the nvmem subsystem (not nvram). Documentation/devicetree/bindings/nvmem Documentation/nvmem
drivers/nvmem

absolutely.

Quoted 23 lines

Quoted 5 lines

I'm not exactly sure how some of the features of the security module would be used: key management, auto erasing, there is a strange "backup mode" vs "normal mode" which is not well documented, etc. So I think it may well end up being sufficiently different to warrant a separate driver.

nvmem is not a subsystem I am familiar with, so it's not immediately clear to me what your driver would look like if re-written that way.

Maybe it would become simpler. But if you did end up needing a separate misc driver as well, maybe use of the nvmem framework would actually increase complexity.

It would depend on your requirements. But I would focus on the actual requirement rather than uncertain future possibilities.

Quoted 6 lines

Quoted 3 lines

Another idea is also to expose it using a genpool so it can be accessed as sram from inside the kernel.

That may be a fine idea, but as far as our application is concerned, we need user-level access to the battery-backed RAM.

Quoted 9 lines

Quoted 2 lines

Right. I don't see how adding a memory allocator would help either.

While the immediate need is to use that sram from userspace, I think this is valuable to already think that at some point we will need to be able to partition and access that sram from the kernel.

Well, I think we're reaching this point right now: I have to implement "freeze" mode (entering a deep sleep mode by cutting all power domains except VDDBU), and in order to do that I need to access BUREGs which are part of the secu-sram you're trying to expose here.

Two comments on the nvmem approach:
1/ first of all it's not really a non-volative memory: if you loose VDDBU you also loose the whole SRAM content.
2/ I need to be able to reserve the BUREG region (at least part of it) for in kernel usage (need to store the SDRAM address I should jump to when exiting freeze mode).

Quoted 11 lines

Well, I think we're reaching this point right now: I have to implement "freeze" mode (entering a deep sleep mode by cutting all power domains except VDDBU), and in order to do that I need to access BUREGs which are part of the secu-sram you're trying to expose here.

Two comments on the nvmem approach:
1/ first of all it's not really a non-volative memory: if you loose VDDBU you also loose the whole SRAM content.
2/ I need to be able to reserve the BUREG region (at least part of it) for in kernel usage (need to store the SDRAM address I should jump to when exiting freeze mode).

Forget this aspect. As Alexandre pointed out, the nvmem framework provides an in-kernel API, so reserving space for the "freeze" mode implementation is doable. But need to use the securam for advanced stuff (like executing code from there) then the SRAM driver approach is more future-proof IMO.

Signed-off-by David Mosberger <[email protected]>

---
 .../devicetree/bindings/nvmem/atmel-secumod.txt    |  46 ++++++++
 arch/arm/boot/dts/sama5d2.dtsi                     |  20 ++++
 drivers/nvmem/Kconfig                              |   7 ++
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/atmel-secumod.c                      | 122 +++++++++++++++++++++
 5 files changed, 197 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +46 -0

new file mode 100644
index 0000000..0bb7638
@@ -0,0 +1,46 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain registers location and length of the RAM, followed
+       by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+    secumod at fc040000 {
+            compatible = "atmel,sama5d2-secumod";
+            reg = <0xf8044000 0x1420
+                   0xfc040000 0x4000>;
+            status = "okay";
+
+            #address-cells = <1>;
+            #size-cells = <1>;
+
+            secram_auto_erasable at 0000 {
+                    reg = <0x0000 0x1000>;
+            };
+            secram at 1000 {
+                    reg = <0x1000 0x400>;
+            };
+            ram at 1400 {
+                    reg = <0x1400 0x20>;
+            };
+    };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+	ram {
+		...
+		nvmem-cells = <&ram>;
+		nvmem-cell-names = "calibration";
+	};

arch/arm/boot/dts/sama5d2.dtsi +20 -0

index 78996bd..5856d6a 100644
@@ -1178,6 +1178,26 @@
 				clocks = <&pioA_clk>;
 			};
 
+			secumod at fc040000 {
+				compatible = "atmel,sama5d2-secumod";
+				reg = <0xf8044000 0x1420
+				       0xfc040000 0x4000>;
+				status = "okay";
+
+				#address-cells = <1>;
+				#size-cells = <1>;
+
+				secram_auto_erasable at 0000 {
+					reg = <0x0000 0x1000>;
+				};
+				secram at 1000 {
+					reg = <0x1000 0x400>;
+				};
+				ram at 1400 {
+					reg = <0x1400 0x20>;
+				};
+			};
+
 			tdes at fc044000 {
 				compatible = "atmel,at91sam9g46-tdes";
 				reg = <0xfc044000 0x100>;

drivers/nvmem/Kconfig +7 -0

index ca52952..3d34fbb 100644
@@ -102,4 +102,11 @@ config NVMEM_VF610_OCOTP
 	  This driver can also be build as a module. If so, the module will
 	  be called nvmem-vf610-ocotp.
 
+config NVMEM_ATMEL_SECUMOD
+       tristate "Atmel Secure Module driver"
+       depends on ARCH_AT91
+       help
+         Select this to get support for the secure module (SECUMOD) built
+	 into the SAMA5D2 chips.
+
 endif

drivers/nvmem/Makefile +2 -0

index 45ab1ae..9cbd950 100644
@@ -22,3 +22,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID)	+= nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y		:= sunxi_sid.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)	+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y		:= vf610-ocotp.o
+obj-$(CONFIG_NVMEM_ATMEL_SECUMOD)	+= nvmem-atmel-secumod.o
+nvmem-atmel-secumod-y		:= atmel-secumod.o

drivers/nvmem/atmel-secumod.c new file +68 -0

new file mode 100644
index 0000000..a6b4574
@@ -0,0 +1,122 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+static struct regmap_config secumod_regmap_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4
+};
+
+static struct nvmem_config econfig = {
+	.name = "secumod",
+	.owner = THIS_MODULE,
+};
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY	0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (void *regs)
+{
+	unsigned long start, stop;
+
+	start = jiffies;
+	while (!(readl(regs + SECUMOD_RAMRDY) & 1))
+		msleep_interruptible(1);
+	stop = jiffies;
+	if (stop != start)
+		pr_info("nvmem-atmel-secumod: it took %u msec for SECUMOD "
+			"to become ready...\n", jiffies_to_msecs(stop - start));
+	else
+		pr_info("nvmem-atmel-secumod: ready\n");
+}
+
+static int secumod_remove(struct platform_device *pdev)
+{
+	struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+	return nvmem_unregister(nvmem);
+}
+
+static int secumod_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;

drivers/nvmem/atmel-secumod.c new file +36 -0

+
+	secumod_regmap_config.max_register = resource_size(res) - 1;
+
+	regmap = devm_regmap_init_mmio(dev, base, &secumod_regmap_config);
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "%s: regmap init failed\n", __func__);
+		return PTR_ERR(regmap);
+	}
+	econfig.dev = dev;
+	nvmem = nvmem_register(&econfig);
+	if (IS_ERR(nvmem))
+		return PTR_ERR(nvmem);
+
+	platform_set_drvdata(pdev, nvmem);
+
+	return 0;
+}
+
+static const struct of_device_id secumod_of_match[] = {
+	{ .compatible = "atmel,sama5d2-secumod",},
+	{/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, secumod_of_match);
+
+static struct platform_driver secumod_driver = {
+	.probe = secumod_probe,
+	.remove = secumod_remove,
+	.driver = {
+		.name = "atmel,sama5d2-secumod",
+		.of_match_table = secumod_of_match,
+	},
+};
+module_platform_driver(secumod_driver);
+MODULE_AUTHOR("David Mosberger <[email protected]>");
+MODULE_DESCRIPTION("Atmel Secumod driver");
+MODULE_LICENSE("GPL v2");

Signed-off-by David Mosberger <[email protected]>

---
 .../devicetree/bindings/nvmem/atmel-secumod.txt    |  46 ++++++++
 drivers/nvmem/atmel-secumod.c                      | 125 +++++++++++++++++++++
 2 files changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +0 -0

new file mode 100644
index 0000000..85db709

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +20 -0

+                    reg = <0x0000 0x1000>;
+            };
+            secram at 1000 {
+                    reg = <0x1000 0x400>;
+            };
+            ram at 1400 {
+                    reg = <0x1400 0x20>;
+            };
+    };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+	ram {
+		...
+		nvmem-cells = <&ram>;
+		nvmem-cell-names = "RAM";
+	};

Signed-off-by David Mosberger <[email protected]>

---
 .../devicetree/bindings/nvmem/atmel-secumod.txt    |  47 +++++++
 drivers/nvmem/Kconfig                              |   7 +
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/atmel-secumod.c                      | 143 +++++++++++++++++++++
 4 files changed, 199 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +7 -0

new file mode 100644
index 0000000..d65cad5
@@ -0,0 +1,47 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +19 -0

+            };
+            secram at 1000 {
+                    reg = <0x1000 0x400>;
+            };
+            ram at 1400 {
+                    reg = <0x1400 0x20>;
+            };
+    };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+	ram {
+		...
+		nvmem-cells = <&ram>;
+		nvmem-cell-names = "RAM";
+	};

Signed-off-by David Mosberger <[email protected]>

---
  .../devicetree/bindings/nvmem/atmel-secumod.txt    |  47 +++++++
  drivers/nvmem/Kconfig                              |   7 +
  drivers/nvmem/Makefile                             |   2 +
  drivers/nvmem/atmel-secumod.c                      | 143 +++++++++++++++++++++
  4 files changed, 199 insertions(+)

create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt create mode 100644 drivers/nvmem/atmel-secumod.c

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +0 -0

new file mode 100644
index 0000000..d65cad5

Documentation/devicetree/bindings/nvmem/atmel-secumod.txt new file +45 -0

+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain RAM location and length, followed
+       by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+    secumod at fc040000 {
+            compatible = "atmel,sama5d2-secumod";
+            reg = <0xf8044000 0x1420>, <0xfc040000 0x4000>;
+            reg-names = "SECURAM", "SECUMOD";
+            status = "okay";
+
+            #address-cells = <1>;
+            #size-cells = <1>;
+            ranges;
+
+            secram-auto-erasable at 0 {
+                    reg = <0x0000 0x1000>;
+            };
+            secram at 1000 {
+                    reg = <0x1000 0x400>;
+            };
+            ram at 1400 {
+                    reg = <0x1400 0x20>;
+            };
+    };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+	ram {
+		...
+		nvmem-cells = <&ram>;
+		nvmem-cell-names = "RAM";
+	};

drivers/nvmem/Kconfig +0 -0

index 3041d48..88b21e3 100644

drivers/nvmem/Kconfig +4 -0

+       help
+         Select this to get support for the secure module (SECUMOD) built
+	 into the SAMA5D2 chips.
+
  endif

index 0000000..fc5a96b

drivers/nvmem/atmel-secumod.c new file +0 -0

drivers/nvmem/atmel-secumod.c new file +9 -0

+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY	0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,