[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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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-eS4NqCHxEME@public.gmane.org>
---
 .../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@8002c000 {
+		compatible = "fsl,imx28-ocotp", "fsl,ocotp";
+		reg = <0x8002c000 0x2000>;
+	};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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-eS4NqCHxEME@public.gmane.org>
---
 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-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
+ *
+ * Christoph G. Baumann <cgb-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
+ * Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
+ *
+ * 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-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>");
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>");
+MODULE_DESCRIPTION("driver for OCOTP in i.MX23/i.MX28");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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-eS4NqCHxEME@public.gmane.org>
---
 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@8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx23-ocotp", "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb@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@8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx28-ocotp", "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb@8002e000 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-eS4NqCHxEME@public.gmane.org>
> ---
>  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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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

Re: [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ezequiel Garcia]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

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-eS4NqCHxEME@public.gmane.org>
>> ---
>>  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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [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-eS4NqCHxEME@public.gmane.org>
> >> ---
> >>  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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-eS4NqCHxEME@public.gmane.org>
>>> ---
>>>  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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Wahren]

Hi,

> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

BR Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-r2nGTMty4D4@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-r2nGTMty4D4@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Wahren]

> Ezequiel Garcia <ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org> 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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html