[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[Stefan Wahren]

This patch series brings readonly support for the On Chip OTP cells in the 
i.MX23 and i.MX28 processor. The driver uses files (one for each cell) 
in sysfs as interface.

This series based on the second version of the patches from 
Christoph G. Baumann, but without write support which is too invasive.

The driver has been tested only with a i.MX28 board, so feedback from 
i.MX23 users are very welcome.

changes in V3:
- drop write support
- take care of i.MX23 which has less registers
- drop unnecessary header file
- move static variables into driver data
- add devicetree probing
- fix missing bank closing in error case
- use kobj from platform device for sysfs
- add SYSFS to Kconfig
- add binding file
- code cleanup

Stefan Wahren (3):
  mxs: add binding for fsl ocotp
  mxs: add driver for ocotp in i.MX23 and i.MX28
  mxs: enable ocotp for i.MX23 and i.MX28

 .../devicetree/bindings/misc/fsl,octop.txt         |   14 +
 arch/arm/boot/dts/imx23.dtsi                       |    3 +-
 arch/arm/boot/dts/imx28.dtsi                       |    3 +-
 drivers/misc/Kconfig                               |   13 +
 drivers/misc/Makefile                              |    1 +
 drivers/misc/fsl_ocotp.c                           |  332 ++++++++++++++++++++
 6 files changed, 362 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/fsl,octop.txt
 create mode 100644 drivers/misc/fsl_ocotp.c

-- 
1.7.9.5

[PATCH RFC V3 1/3] mxs: add binding for fsl ocotp

[Stefan Wahren]

This patch adds the Device tree bindings for the Freescale MXS On Chip
OTP driver.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 .../devicetree/bindings/misc/fsl,octop.txt         |   14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/fsl,octop.txt

diff --git a/Documentation/devicetree/bindings/misc/fsl,octop.txt b/Documentation/devicetree/bindings/misc/fsl,octop.txt
new file mode 100644
index 0000000..db1c510
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,octop.txt
@@ -0,0 +1,14 @@
+On-Chip OTP Memory for Freescale MX23/MX28
+
+Required properties:
+- compatible:
+  - "fsl,imx23-ocotp" for MX23
+  - "fsl,imx23-ocotp" for MX28
+- reg : Address and length of OTP controller registers
+
+Example:
+
+	ocotp: ocotp at 8002c000 {
+		compatible = "fsl,imx28-ocotp", "fsl,ocotp";
+		reg = <0x8002c000 0x2000>;
+	};
-- 
1.7.9.5

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

This patch brings readonly support for the On Chip OTP cells in the i.MX23
and i.MX28 processor. The driver uses files (one for each cell) in sysfs
as interface.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/misc/Kconfig     |   13 ++
 drivers/misc/Makefile    |    1 +
 drivers/misc/fsl_ocotp.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 346 insertions(+)
 create mode 100644 drivers/misc/fsl_ocotp.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b841180..7455efa 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
 	  bus. System Configuration interface is one of the possible means
 	  of generating transactions on this bus.
 
+config FSL_OCOTP
+        tristate "Freescale MXS On-Chip OTP Memory Support"
+        depends on ARCH_MXS && SYSFS
+        help
+          If you say Y here, you will get support for a readonly
+	  SysFS interface for the One Time Programmable memory pages that
+	  are stored on the Freescale i.MX23/i.MX28 processor.
+
+          To compile this driver as a module, choose M here: the module
+          will be called fsl_ocotp.
+
+          If unsure, it is safe to say N.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5497d02..301cd15 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-y				+= mic/
 obj-$(CONFIG_GENWQE)		+= genwqe/
 obj-$(CONFIG_ECHO)		+= echo/
 obj-$(CONFIG_VEXPRESS_SYSCFG)	+= vexpress-syscfg.o
+obj-$(CONFIG_FSL_OCOTP)           += fsl_ocotp.o
diff --git a/drivers/misc/fsl_ocotp.c b/drivers/misc/fsl_ocotp.c
new file mode 100644
index 0000000..ddb4e9b
--- /dev/null
+++ b/drivers/misc/fsl_ocotp.c
@@ -0,0 +1,332 @@
+/*
+ * Freescale On-Chip OTP driver
+ *
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Huang Shijie <b32955@freescale.com>
+ *
+ * Christoph G. Baumann <cgb@debian.org>
+ * Stefan Wahren <stefan.wahren@i2se.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/fcntl.h>
+#include <linux/mutex.h>
+#include <linux/clk.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+
+/* OCOTP registers and bits */
+#define HW_OCOTP_CTRL_SET	(0x00000004)
+#define HW_OCOTP_CTRL_CLR	(0x00000008)
+
+#define BM_OCOTP_CTRL_RD_BANK_OPEN	0x00001000
+#define BM_OCOTP_CTRL_ERROR		0x00000200
+#define BM_OCOTP_CTRL_BUSY		0x00000100
+
+struct fsl_ocotp {
+	struct attribute_group group;
+	struct mutex lock;
+	void __iomem *base_addr;
+	u32 data_offset;
+};
+
+static ssize_t fsl_ocotp_attr_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct fsl_ocotp *otp = platform_get_drvdata(pdev);
+	int timeout = 0x400;
+	int index = 0;
+	u32 value = 0;
+	u32 offset;
+
+	if (otp == NULL) {
+		dev_err(dev, "%s: no drvdata\n", __func__);
+		return 0;
+	}
+
+	while (otp->group.attrs[index]) {
+		if (strcmp(attr->attr.name, otp->group.attrs[index]->name) == 0)
+			break;
+
+		index++;
+	}
+
+	if (otp->group.attrs[index] == NULL) {
+		dev_err(dev, "%s: attr not found\n", __func__);
+		return 0;
+	}
+
+	mutex_lock(&otp->lock);
+
+	/* try to clear ERROR bit */
+	writel(BM_OCOTP_CTRL_ERROR, otp->base_addr + HW_OCOTP_CTRL_CLR);
+
+	/* check both BUSY and ERROR cleared */
+	while ((readl(otp->base_addr) &
+	       (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
+		cpu_relax();
+
+	if (unlikely(!timeout)) {
+		dev_err(dev, "%s: OCTOP busy or error\n", __func__);
+		goto error_unlock;
+	}
+
+	/* open OCOTP banks for read */
+	writel(BM_OCOTP_CTRL_RD_BANK_OPEN, otp->base_addr + HW_OCOTP_CTRL_SET);
+
+	/* approximately wait 32 hclk cycles */
+	udelay(1);
+
+	/* poll BUSY bit becoming cleared */
+	timeout = 0x400;
+	while ((readl(otp->base_addr) & BM_OCOTP_CTRL_BUSY) && --timeout)
+		cpu_relax();
+
+	if (timeout) {
+		offset = otp->data_offset + index * 0x10;
+		value = readl(otp->base_addr + offset);
+	}
+
+	/* close banks for power saving */
+	writel(BM_OCOTP_CTRL_RD_BANK_OPEN, otp->base_addr + HW_OCOTP_CTRL_CLR);
+
+	if (unlikely(!timeout)) {
+		dev_err(dev, "%s: OCTOP timeout\n", __func__);
+		goto error_unlock;
+	}
+
+	mutex_unlock(&otp->lock);
+	return sprintf(buf, "0x%x\n", value);
+
+error_unlock:
+	mutex_unlock(&otp->lock);
+	return 0;
+}
+
+static DEVICE_ATTR(HW_OCOTP_CUST0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CUST1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CUST2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CUST3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CRYPTO0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CRYPTO1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CRYPTO2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CRYPTO3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+
+static DEVICE_ATTR(HW_OCOTP_HWCAP0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_HWCAP1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_HWCAP2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_HWCAP3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_HWCAP4, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_HWCAP5, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SWCAP, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_CUSTCAP, S_IRUSR, fsl_ocotp_attr_show, NULL);
+
+static DEVICE_ATTR(HW_OCOTP_LOCK, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_OPS0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_OPS1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_OPS2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_OPS3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_UN0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_UN1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_UN2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+
+static DEVICE_ATTR(HW_OCOTP_ROM0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM4, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM5, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM6, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_ROM7, S_IRUSR, fsl_ocotp_attr_show, NULL);
+
+static DEVICE_ATTR(HW_OCOTP_SRK0, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK1, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK2, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK3, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK4, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK5, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK6, S_IRUSR, fsl_ocotp_attr_show, NULL);
+static DEVICE_ATTR(HW_OCOTP_SRK7, S_IRUSR, fsl_ocotp_attr_show, NULL);
+
+static struct attribute *imx23_ocotp_attributes[] = {
+	&dev_attr_HW_OCOTP_CUST0.attr,
+	&dev_attr_HW_OCOTP_CUST1.attr,
+	&dev_attr_HW_OCOTP_CUST2.attr,
+	&dev_attr_HW_OCOTP_CUST3.attr,
+	&dev_attr_HW_OCOTP_CRYPTO0.attr,
+	&dev_attr_HW_OCOTP_CRYPTO1.attr,
+	&dev_attr_HW_OCOTP_CRYPTO2.attr,
+	&dev_attr_HW_OCOTP_CRYPTO3.attr,
+	&dev_attr_HW_OCOTP_HWCAP0.attr,
+	&dev_attr_HW_OCOTP_HWCAP1.attr,
+	&dev_attr_HW_OCOTP_HWCAP2.attr,
+	&dev_attr_HW_OCOTP_HWCAP3.attr,
+	&dev_attr_HW_OCOTP_HWCAP4.attr,
+	&dev_attr_HW_OCOTP_HWCAP5.attr,
+	&dev_attr_HW_OCOTP_SWCAP.attr,
+	&dev_attr_HW_OCOTP_CUSTCAP.attr,
+	&dev_attr_HW_OCOTP_LOCK.attr,
+	&dev_attr_HW_OCOTP_OPS0.attr,
+	&dev_attr_HW_OCOTP_OPS1.attr,
+	&dev_attr_HW_OCOTP_OPS2.attr,
+	&dev_attr_HW_OCOTP_OPS3.attr,
+	&dev_attr_HW_OCOTP_UN0.attr,
+	&dev_attr_HW_OCOTP_UN1.attr,
+	&dev_attr_HW_OCOTP_UN2.attr,
+	&dev_attr_HW_OCOTP_ROM0.attr,
+	&dev_attr_HW_OCOTP_ROM1.attr,
+	&dev_attr_HW_OCOTP_ROM2.attr,
+	&dev_attr_HW_OCOTP_ROM3.attr,
+	&dev_attr_HW_OCOTP_ROM4.attr,
+	&dev_attr_HW_OCOTP_ROM5.attr,
+	&dev_attr_HW_OCOTP_ROM6.attr,
+	&dev_attr_HW_OCOTP_ROM7.attr,
+	NULL
+};
+
+static struct attribute *imx28_ocotp_attributes[] = {
+	&dev_attr_HW_OCOTP_CUST0.attr,
+	&dev_attr_HW_OCOTP_CUST1.attr,
+	&dev_attr_HW_OCOTP_CUST2.attr,
+	&dev_attr_HW_OCOTP_CUST3.attr,
+	&dev_attr_HW_OCOTP_CRYPTO0.attr,
+	&dev_attr_HW_OCOTP_CRYPTO1.attr,
+	&dev_attr_HW_OCOTP_CRYPTO2.attr,
+	&dev_attr_HW_OCOTP_CRYPTO3.attr,
+	&dev_attr_HW_OCOTP_HWCAP0.attr,
+	&dev_attr_HW_OCOTP_HWCAP1.attr,
+	&dev_attr_HW_OCOTP_HWCAP2.attr,
+	&dev_attr_HW_OCOTP_HWCAP3.attr,
+	&dev_attr_HW_OCOTP_HWCAP4.attr,
+	&dev_attr_HW_OCOTP_HWCAP5.attr,
+	&dev_attr_HW_OCOTP_SWCAP.attr,
+	&dev_attr_HW_OCOTP_CUSTCAP.attr,
+	&dev_attr_HW_OCOTP_LOCK.attr,
+	&dev_attr_HW_OCOTP_OPS0.attr,
+	&dev_attr_HW_OCOTP_OPS1.attr,
+	&dev_attr_HW_OCOTP_OPS2.attr,
+	&dev_attr_HW_OCOTP_OPS3.attr,
+	&dev_attr_HW_OCOTP_UN0.attr,
+	&dev_attr_HW_OCOTP_UN1.attr,
+	&dev_attr_HW_OCOTP_UN2.attr,
+	&dev_attr_HW_OCOTP_ROM0.attr,
+	&dev_attr_HW_OCOTP_ROM1.attr,
+	&dev_attr_HW_OCOTP_ROM2.attr,
+	&dev_attr_HW_OCOTP_ROM3.attr,
+	&dev_attr_HW_OCOTP_ROM4.attr,
+	&dev_attr_HW_OCOTP_ROM5.attr,
+	&dev_attr_HW_OCOTP_ROM6.attr,
+	&dev_attr_HW_OCOTP_ROM7.attr,
+	&dev_attr_HW_OCOTP_SRK0.attr,
+	&dev_attr_HW_OCOTP_SRK1.attr,
+	&dev_attr_HW_OCOTP_SRK2.attr,
+	&dev_attr_HW_OCOTP_SRK3.attr,
+	&dev_attr_HW_OCOTP_SRK4.attr,
+	&dev_attr_HW_OCOTP_SRK5.attr,
+	&dev_attr_HW_OCOTP_SRK6.attr,
+	&dev_attr_HW_OCOTP_SRK7.attr,
+	NULL
+};
+
+static const struct fsl_ocotp imx23_ocotp = {
+	.group = { .name = "fuses", .attrs = imx23_ocotp_attributes },
+	.data_offset	= 0x20,
+};
+
+static const struct fsl_ocotp imx28_ocotp = {
+	.group = { .name = "fuses", .attrs = imx28_ocotp_attributes },
+	.data_offset	= 0x20,
+};
+
+static const struct of_device_id fsl_ocotp_dt_ids[] = {
+	{ .compatible = "fsl,imx23-ocotp", .data = &imx23_ocotp },
+	{ .compatible = "fsl,imx28-ocotp", .data = &imx28_ocotp },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, fsl_ocotp_dt_ids);
+
+static int fsl_ocotp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct fsl_ocotp *otp;
+	const struct of_device_id *match;
+	struct resource *res;
+	int ret;
+
+	match = of_match_device(fsl_ocotp_dt_ids, dev);
+	if (!match) {
+		dev_err(dev, "%s: Unable to match device\n", __func__);
+		return -ENODEV;
+	}
+
+	if (!dev->of_node) {
+		dev_err(dev, "missing device tree\n");
+		return -EINVAL;
+	}
+
+	otp = devm_kmemdup(dev, match->data, sizeof(*otp), GFP_KERNEL);
+	if (!otp)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	otp->base_addr = devm_ioremap_resource(dev, res);
+	if (IS_ERR(otp->base_addr))
+		return PTR_ERR(otp->base_addr);
+
+	mutex_init(&otp->lock);
+
+	ret = sysfs_create_group(&dev->kobj, &otp->group);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, otp);
+
+	dev_info(dev, "initialized\n");
+
+	return 0;
+}
+
+static int fsl_ocotp_remove(struct platform_device *pdev)
+{
+	struct fsl_ocotp *otp = platform_get_drvdata(pdev);
+
+	sysfs_remove_group(&pdev->dev.kobj, &otp->group);
+
+	return 0;
+}
+
+static struct platform_driver fsl_ocotp_driver = {
+	.probe		= fsl_ocotp_probe,
+	.remove		= fsl_ocotp_remove,
+	.driver		= {
+		.name   = "fsl_ocotp",
+		.owner	= THIS_MODULE,
+		.of_match_table = fsl_ocotp_dt_ids,
+	},
+};
+
+module_platform_driver(fsl_ocotp_driver);
+MODULE_AUTHOR("Christoph G. Baumann <cgb@debian.org>");
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_DESCRIPTION("driver for OCOTP in i.MX23/i.MX28");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Arnd Bergmann]

On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
> This patch brings readonly support for the On Chip OTP cells in the i.MX23
> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
> as interface.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  drivers/misc/Kconfig     |   13 ++
>  drivers/misc/Makefile    |    1 +
>  drivers/misc/fsl_ocotp.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 346 insertions(+)
>  create mode 100644 drivers/misc/fsl_ocotp.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index b841180..7455efa 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
>           bus. System Configuration interface is one of the possible means
>           of generating transactions on this bus.
>  
> +config FSL_OCOTP
> +        tristate "Freescale MXS On-Chip OTP Memory Support"
> +        depends on ARCH_MXS && SYSFS
> +        help
> +          If you say Y here, you will get support for a readonly
> +         SysFS interface for the One Time Programmable memory pages that
> +         are stored on the Freescale i.MX23/i.MX28 processor.
> +
> +          To compile this driver as a module, choose M here: the module
> +          will be called fsl_ocotp.
> +
> +          If unsure, it is safe to say N.
> 

I think this needs to be an MTD driver, not a "misc" driver, and it
should use the proper MTD interfaces instead of introducing an
incompatible set of interfaces.

	Arnd

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi Arnd,

Am 20.10.2014 um 16:44 schrieb Arnd Bergmann:
> On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
>> This patch brings readonly support for the On Chip OTP cells in the i.MX23
>> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
>> as interface.
>>
>> ...
> I think this needs to be an MTD driver, not a "misc" driver, and it
> should use the proper MTD interfaces instead of introducing an
> incompatible set of interfaces.
>
> 	Arnd

phew that sounds like a lot of work and much complexity.

Am i right, that i should drop the sysfs interface?

Does MTD drivers have a readonly text (non binary) user interface?

Best regards
Stefan

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Arnd Bergmann]

On Monday 20 October 2014 17:32:37 Stefan Wahren wrote:
> 
> Am 20.10.2014 um 16:44 schrieb Arnd Bergmann:
> > On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
> >> This patch brings readonly support for the On Chip OTP cells in the i.MX23
> >> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
> >> as interface.
> >>
> >> ...
> > I think this needs to be an MTD driver, not a "misc" driver, and it
> > should use the proper MTD interfaces instead of introducing an
> > incompatible set of interfaces.
> >
> >       Arnd
> 
> phew that sounds like a lot of work and much complexity.
> 
> Am i right, that i should drop the sysfs interface?
> 
> Does MTD drivers have a readonly text (non binary) user interface?

I haven't looked at the MTD OTP interface in detail, but most
of the other SoCs seem to use it.

	Arnd

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Ezequiel Garcia]

On 10/20/2014 11:44 AM, Arnd Bergmann wrote:
> On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
>> This patch brings readonly support for the On Chip OTP cells in the i.MX23
>> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
>> as interface.
>>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> ---
>>  drivers/misc/Kconfig     |   13 ++
>>  drivers/misc/Makefile    |    1 +
>>  drivers/misc/fsl_ocotp.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 346 insertions(+)
>>  create mode 100644 drivers/misc/fsl_ocotp.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index b841180..7455efa 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
>>           bus. System Configuration interface is one of the possible means
>>           of generating transactions on this bus.
>>  
>> +config FSL_OCOTP
>> +        tristate "Freescale MXS On-Chip OTP Memory Support"
>> +        depends on ARCH_MXS && SYSFS
>> +        help
>> +          If you say Y here, you will get support for a readonly
>> +         SysFS interface for the One Time Programmable memory pages that
>> +         are stored on the Freescale i.MX23/i.MX28 processor.
>> +
>> +          To compile this driver as a module, choose M here: the module
>> +          will be called fsl_ocotp.
>> +
>> +          If unsure, it is safe to say N.
>>
> 
> I think this needs to be an MTD driver, not a "misc" driver, and it
> should use the proper MTD interfaces instead of introducing an
> incompatible set of interfaces.
> 

Are you sure MTD is the right place? Recently an eFuse driver was merged
in drivers/soc/tegra/fuse:

http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c

Isn't this a similar device?
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141028/06ec5899/attachment-0001.sig>

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Arnd Bergmann]

On Tuesday 28 October 2014 14:17:39 Ezequiel Garcia wrote:
> On 10/20/2014 11:44 AM, Arnd Bergmann wrote:
> > On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
> >> This patch brings readonly support for the On Chip OTP cells in the i.MX23
> >> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
> >> as interface.
> >>
> >> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >> ---
> >>  drivers/misc/Kconfig     |   13 ++
> >>  drivers/misc/Makefile    |    1 +
> >>  drivers/misc/fsl_ocotp.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
> >>  3 files changed, 346 insertions(+)
> >>  create mode 100644 drivers/misc/fsl_ocotp.c
> >>
> >> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> >> index b841180..7455efa 100644
> >> --- a/drivers/misc/Kconfig
> >> +++ b/drivers/misc/Kconfig
> >> @@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
> >>           bus. System Configuration interface is one of the possible means
> >>           of generating transactions on this bus.
> >>  
> >> +config FSL_OCOTP
> >> +        tristate "Freescale MXS On-Chip OTP Memory Support"
> >> +        depends on ARCH_MXS && SYSFS
> >> +        help
> >> +          If you say Y here, you will get support for a readonly
> >> +         SysFS interface for the One Time Programmable memory pages that
> >> +         are stored on the Freescale i.MX23/i.MX28 processor.
> >> +
> >> +          To compile this driver as a module, choose M here: the module
> >> +          will be called fsl_ocotp.
> >> +
> >> +          If unsure, it is safe to say N.
> >>
> > 
> > I think this needs to be an MTD driver, not a "misc" driver, and it
> > should use the proper MTD interfaces instead of introducing an
> > incompatible set of interfaces.
> > 
> 
> Are you sure MTD is the right place? Recently an eFuse driver was merged
> in drivers/soc/tegra/fuse:
> 
> http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c
> 
> Isn't this a similar device?

Hmm, I missed that one.

I came up with MTD just because a grep for OTP showed most hits in there.
I have to admit that I didn't check whether those are actually for
the same kind of device or for something else that goes by the same
name. Having it in MTD doesn't sound too obscure though.

There are a few other references to efuse or otp in the kernel, which means
that at some point we probably want to have a common subsystem and user
interface for this, either in MTD or standalone.

Between drivers/misc/fsl_ocotp.c, drivers/soc/tegra/fuse and
drivers/mfd/ab3100-otp.c, is there any commonality that we could
base an abstract API on?

	Arnd

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi,

> Arnd Bergmann <arnd@arndb.de> hat am 28. Oktober 2014 um 20:13 geschrieben:
> [...]
>
> I came up with MTD just because a grep for OTP showed most hits in there.
> I have to admit that I didn't check whether those are actually for
> the same kind of device or for something else that goes by the same
> name. Having it in MTD doesn't sound too obscure though.
>
> There are a few other references to efuse or otp in the kernel, which means
> that at some point we probably want to have a common subsystem and user
> interface for this, either in MTD or standalone.
>
> Between drivers/misc/fsl_ocotp.c, drivers/soc/tegra/fuse and
> drivers/mfd/ab3100-otp.c, is there any commonality that we could
> base an abstract API on?

i don't have a answer to this question, but how about changing fsl_ocotp driver
to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.

Does it make sense to you?

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

BR Stefan

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Arnd Bergmann]

On Thursday 06 November 2014 20:25:32 Stefan Wahren wrote:
> Hi,
> 
> > Arnd Bergmann <arnd@arndb.de> hat am 28. Oktober 2014 um 20:13 geschrieben:
> > [...]
> >
> > I came up with MTD just because a grep for OTP showed most hits in there.
> > I have to admit that I didn't check whether those are actually for
> > the same kind of device or for something else that goes by the same
> > name. Having it in MTD doesn't sound too obscure though.
> >
> > There are a few other references to efuse or otp in the kernel, which means
> > that at some point we probably want to have a common subsystem and user
> > interface for this, either in MTD or standalone.
> >
> > Between drivers/misc/fsl_ocotp.c, drivers/soc/tegra/fuse and
> > drivers/mfd/ab3100-otp.c, is there any commonality that we could
> > base an abstract API on?
> 
> i don't have a answer to this question, but how about changing fsl_ocotp driver
> to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
> 
> Does it make sense to you?

I haven't looked at the drivers, so I don't know if the tegra interface
is any better or worse than the others. Changing everyone to have the same
interface is definitely a good idea, but of course only if the unified
interface is a good one ;-)

	Arnd

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Ezequiel Garcia]

Hi Stefan, Arnd,

(I'm trimming the Cc list and adding Thierry and Maxime to the loop):

On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
[..]
>>
>> i don't have a answer to this question, but how about changing fsl_ocotp driver
>> to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
>>
>> Does it make sense to you?
> 
> I haven't looked at the drivers, so I don't know if the tegra interface
> is any better or worse than the others. Changing everyone to have the same
> interface is definitely a good idea, but of course only if the unified
> interface is a good one ;-)
> 

I'm in the process of finding a suitable upstream path for a new eFuse driver
for fuses used on Imagination Technologies SoCs.

This was our last proposal, which follows Tegra's work:

http://www.spinics.net/lists/devicetree/msg59246.html

However, Arnd was reluctant to take yet another efuse driver under drivers/soc
and proposed instead to try to find a unified API. We've had numerous fuse
drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes
sense.

I've talked to Arnd on IRC and we agreed to create a new directory
drivers/efuse. As a first step we would just move the tegra driver,
and add the new drivers (img on my side, and possibly mxs on Stefan's).
Perhaps we would also pull the sunxi_sid driver as well.

Having the drivers together would allow us to come up with a unified API
as follow up work.

How does this sound? If you have no objections to this, I can go ahead and
try to prepare some RFCs.
-- 
Ezequiel

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi Ezequiel,

Am 08.01.2015 um 14:59 schrieb Ezequiel Garcia:
> Hi Stefan, Arnd,
>
> (I'm trimming the Cc list and adding Thierry and Maxime to the loop):
>
> I'm in the process of finding a suitable upstream path for a new eFuse driver
> for fuses used on Imagination Technologies SoCs.
>
> This was our last proposal, which follows Tegra's work:
>
> http://www.spinics.net/lists/devicetree/msg59246.html
>
> However, Arnd was reluctant to take yet another efuse driver under drivers/soc
> and proposed instead to try to find a unified API. We've had numerous fuse
> drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes
> sense.
>
> I've talked to Arnd on IRC and we agreed to create a new directory
> drivers/efuse. As a first step we would just move the tegra driver,
> and add the new drivers (img on my side, and possibly mxs on Stefan's).
> Perhaps we would also pull the sunxi_sid driver as well.
>
> Having the drivers together would allow us to come up with a unified API
> as follow up work.

does this unified API affects userspace interface, internal kernel
interface or both?

> How does this sound? If you have no objections to this, I can go ahead and
> try to prepare some RFCs.

I'm happy about any progress on this. It's not really urgent for me to
get the driver into mainline. A helpful and useable userspace interface
is more important to me. So i want to send my comments/requirements
about the API and post the mxs driver after the definition of the
unified API.

Does this answer your question?

Stefan

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi Ezequiel,

> Ezequiel Garcia <ezequiel.garcia@imgtec.com> hat am 8. Januar 2015 um 14:59
> geschrieben:
>
>
> Hi Stefan, Arnd,
>
> (I'm trimming the Cc list and adding Thierry and Maxime to the loop):
>
> [...]
>
> I've talked to Arnd on IRC and we agreed to create a new directory
> drivers/efuse. As a first step we would just move the tegra driver,
> and add the new drivers (img on my side, and possibly mxs on Stefan's).
> Perhaps we would also pull the sunxi_sid driver as well.

AFAIK the binding documentation for the tegra driver is stored in

Documentation/devicetree/bindings/fuse/

so a consistent naming would be better. Beside that i'm okay with the approach.

Stefan

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Thierry Reding]

On Thu, Jan 08, 2015 at 10:59:33AM -0300, Ezequiel Garcia wrote:
> Hi Stefan, Arnd,
> 
> (I'm trimming the Cc list and adding Thierry and Maxime to the loop):
> 
> On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
> [..]
> >>
> >> i don't have a answer to this question, but how about changing fsl_ocotp driver
> >> to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
> >>
> >> Does it make sense to you?
> > 
> > I haven't looked at the drivers, so I don't know if the tegra interface
> > is any better or worse than the others. Changing everyone to have the same
> > interface is definitely a good idea, but of course only if the unified
> > interface is a good one ;-)
> > 
> 
> I'm in the process of finding a suitable upstream path for a new eFuse driver
> for fuses used on Imagination Technologies SoCs.
> 
> This was our last proposal, which follows Tegra's work:
> 
> http://www.spinics.net/lists/devicetree/msg59246.html
> 
> However, Arnd was reluctant to take yet another efuse driver under drivers/soc
> and proposed instead to try to find a unified API. We've had numerous fuse
> drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes
> sense.
> 
> I've talked to Arnd on IRC and we agreed to create a new directory
> drivers/efuse. As a first step we would just move the tegra driver,
> and add the new drivers (img on my side, and possibly mxs on Stefan's).
> Perhaps we would also pull the sunxi_sid driver as well.
> 
> Having the drivers together would allow us to come up with a unified API
> as follow up work.
> 
> How does this sound? If you have no objections to this, I can go ahead and
> try to prepare some RFCs.

No objections from me. Adding Peter and linux-tegra for visibility.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150109/e448848c/attachment.sig>

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Maxime Ripard]

On Thu, Jan 08, 2015 at 10:59:33AM -0300, Ezequiel Garcia wrote:
> Hi Stefan, Arnd,
> 
> (I'm trimming the Cc list and adding Thierry and Maxime to the loop):
> 
> On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
> [..]
> >>
> >> i don't have a answer to this question, but how about changing fsl_ocotp driver
> >> to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
> >>
> >> Does it make sense to you?
> > 
> > I haven't looked at the drivers, so I don't know if the tegra interface
> > is any better or worse than the others. Changing everyone to have the same
> > interface is definitely a good idea, but of course only if the unified
> > interface is a good one ;-)
> > 
> 
> I'm in the process of finding a suitable upstream path for a new eFuse driver
> for fuses used on Imagination Technologies SoCs.
> 
> This was our last proposal, which follows Tegra's work:
> 
> http://www.spinics.net/lists/devicetree/msg59246.html
> 
> However, Arnd was reluctant to take yet another efuse driver under
> drivers/soc and proposed instead to try to find a unified API. We've
> had numerous fuse drivers (tegra, sunxi, imx and img) appearing, so
> his concern certainly makes sense.
> 
> I've talked to Arnd on IRC and we agreed to create a new directory
> drivers/efuse. As a first step we would just move the tegra driver,
> and add the new drivers (img on my side, and possibly mxs on
> Stefan's).  Perhaps we would also pull the sunxi_sid driver as well.
> 
> Having the drivers together would allow us to come up with a unified API
> as follow up work.
> 
> How does this sound? If you have no objections to this, I can go
> ahead and try to prepare some RFCs.

It sounds great :)

Could you put me in Cc whenever you send some patches?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150112/d70391be/attachment.sig>

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Ezequiel Garcia]

On 11/06/2014 04:25 PM, Stefan Wahren wrote:
> Hi,
> 
>> Arnd Bergmann <arnd@arndb.de> hat am 28. Oktober 2014 um 20:13 geschrieben:
>> [...]
>>
>> I came up with MTD just because a grep for OTP showed most hits in there.
>> I have to admit that I didn't check whether those are actually for
>> the same kind of device or for something else that goes by the same
>> name. Having it in MTD doesn't sound too obscure though.
>>
>> There are a few other references to efuse or otp in the kernel, which means
>> that at some point we probably want to have a common subsystem and user
>> interface for this, either in MTD or standalone.
>>
>> Between drivers/misc/fsl_ocotp.c, drivers/soc/tegra/fuse and
>> drivers/mfd/ab3100-otp.c, is there any commonality that we could
>> base an abstract API on?
> 
> i don't have a answer to this question, but how about changing fsl_ocotp driver
> to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
> 
> Does it make sense to you?
> 

While you are here, maybe you can check if your API and driver will also
be useful to support i.MX6 OCOTP?

I understand that I might be asking too much, and that perhaps i.MX23/28
eFuses are completely different from other another i.MX.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> hat am 7. November 2014 um
> 20:14 geschrieben:
>
>
> While you are here, maybe you can check if your API and driver will also
> be useful to support i.MX6 OCOTP?

That's why i named the driver fsl_ocotp and not mxs_ocotp ;-)

Sure the handling would be a little different.

>
> I understand that I might be asking too much, and that perhaps i.MX23/28
> eFuses are completely different from other another i.MX.

I don't believe that, but i didn't doublecheck it.

BR Stefan

>
> --
> Ezequiel Garcia, VanguardiaSur
> www.vanguardiasur.com.ar
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi Ezequiel,

Am 28.10.2014 um 18:17 schrieb Ezequiel Garcia:
> On 10/20/2014 11:44 AM, Arnd Bergmann wrote:
>> On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
>>> This patch brings readonly support for the On Chip OTP cells in the i.MX23
>>> and i.MX28 processor. The driver uses files (one for each cell) in sysfs
>>> as interface.
>>>
>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>> ---
>>>  drivers/misc/Kconfig     |   13 ++
>>>  drivers/misc/Makefile    |    1 +
>>>  drivers/misc/fsl_ocotp.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 346 insertions(+)
>>>  create mode 100644 drivers/misc/fsl_ocotp.c
>>>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index b841180..7455efa 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
>>>           bus. System Configuration interface is one of the possible means
>>>           of generating transactions on this bus.
>>>  
>>> +config FSL_OCOTP
>>> +        tristate "Freescale MXS On-Chip OTP Memory Support"
>>> +        depends on ARCH_MXS && SYSFS
>>> +        help
>>> +          If you say Y here, you will get support for a readonly
>>> +         SysFS interface for the One Time Programmable memory pages that
>>> +         are stored on the Freescale i.MX23/i.MX28 processor.
>>> +
>>> +          To compile this driver as a module, choose M here: the module
>>> +          will be called fsl_ocotp.
>>> +
>>> +          If unsure, it is safe to say N.
>>>
>> I think this needs to be an MTD driver, not a "misc" driver, and it
>> should use the proper MTD interfaces instead of introducing an
>> incompatible set of interfaces.
>>
> Are you sure MTD is the right place? Recently an eFuse driver was merged
> in drivers/soc/tegra/fuse:
>
> http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c
>
> Isn't this a similar device?

the i.MX28 Reference manual speak also of eFuses and this driver looks
more familiar to me.

>From my point of view it's important to keep the structure of 40 OTP
register a 32 bits. It doesn't make sense to merge them all together in
a blob of 1280 bits and a userspace tool needs to separate it again.

Thanks for the hint.

BR Stefan

[PATCH RFC V3 3/3] mxs: enable ocotp for i.MX23 and i.MX28

[Stefan Wahren]

This patch enables On Chip OTP support for i.MX23 and i.MX28 SoCs,
but keeps the old compatible string.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/imx23.dtsi |    3 +--
 arch/arm/boot/dts/imx28.dtsi |    3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index bbcfb5a..677d937 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -350,9 +350,8 @@
 			};
 
 			ocotp at 8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx23-ocotp", "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb at 8002e000 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 47f68ac..f4e0ebb 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -923,9 +923,8 @@
 			};
 
 			ocotp: ocotp at 8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx28-ocotp", "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb at 8002e000 {
-- 
1.7.9.5

[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[Jörg Krause]

Hi Stefan,

I'm very interested in your patches. Anything new about this?

Best regards
J?rg Krause

[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[Jörg Krause]

Hi Stefan,

sorry, I forgot to subscribe to the mailing list.

Any news about these patches? What's missing?

Best regards
J?rg Krause

[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[Stefan Wahren]

Hi J?rg,

Am 25.02.2015 um 21:27 schrieb J?rg Krause:
> Hi Stefan,
>
> sorry, I forgot to subscribe to the mailing list.
>
> Any news about these patches? What's missing?

i wait until there is a common infrastructure for OTP / eFuse driver.

Please look at this discussion:

http://marc.info/?l=linux-arm-kernel&m=142486510903415&w=2

After these patches has been applied, i will adapt my patches here:

https://github.com/lategoodbye/fsl_ocotp

> Best regards
> J?rg Krause
>

BR Stefan

[PATCH RFC V3 0/3] mxs: add ocotp support for i.MX23 and i.MX28

[Jörg Krause]

Hi Stefan,

On Do, 2015-02-26 at 08:11 +0100, Stefan Wahren wrote:
> Hi J?rg,
> 
> Am 25.02.2015 um 21:27 schrieb J?rg Krause:
> > Hi Stefan,
> >
> > sorry, I forgot to subscribe to the mailing list.
> >
> > Any news about these patches? What's missing?
> 
> i wait until there is a common infrastructure for OTP / eFuse driver.
> 
> Please look at this discussion:
> 
> http://marc.info/?l=linux-arm-kernel&m=142486510903415&w=2
> 
> After these patches has been applied, i will adapt my patches here:
> 
> https://github.com/lategoodbye/fsl_ocotp

These are good news! Many thanks!

Best regards
J?rg Krause