diff mbox

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

Message ID 1413628372-2809-3-git-send-email-stefan.wahren@i2se.com (mailing list archive)
State New, archived
Headers show

Commit Message

Stefan Wahren Oct. 18, 2014, 10:32 a.m. UTC
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

Comments

Arnd Bergmann Oct. 20, 2014, 2:44 p.m. UTC | #1
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
Stefan Wahren Oct. 20, 2014, 3:32 p.m. UTC | #2
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
Arnd Bergmann Oct. 20, 2014, 5:32 p.m. UTC | #3
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
Ezequiel Garcia Oct. 28, 2014, 5:17 p.m. UTC | #4
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?
Arnd Bergmann Oct. 28, 2014, 7:13 p.m. UTC | #5
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
Stefan Wahren Oct. 29, 2014, 7:14 a.m. UTC | #6
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
Stefan Wahren Nov. 6, 2014, 7:25 p.m. UTC | #7
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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

BR Stefan
Arnd Bergmann Nov. 6, 2014, 7:47 p.m. UTC | #8
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
Ezequiel Garcia Nov. 7, 2014, 7:14 p.m. UTC | #9
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.
Stefan Wahren Nov. 7, 2014, 7:44 p.m. UTC | #10
> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Ezequiel Garcia Jan. 8, 2015, 1:59 p.m. UTC | #11
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.
Stefan Wahren Jan. 8, 2015, 2:53 p.m. UTC | #12
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
Stefan Wahren Jan. 8, 2015, 8:47 p.m. UTC | #13
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
Thierry Reding Jan. 9, 2015, 10:02 a.m. UTC | #14
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
Maxime Ripard Jan. 12, 2015, 9:21 a.m. UTC | #15
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
diff mbox

Patch

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");