All of lore.kernel.org
 help / color / mirror / Atom feed
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28
Date: Mon, 20 Jul 2015 10:16:05 +0200	[thread overview]
Message-ID: <201507201016.05699.marex@denx.de> (raw)
In-Reply-To: <55AC970D.6090707@i2se.com>

On Monday, July 20, 2015 at 08:37:01 AM, Stefan Wahren wrote:
> Hi Marek,

Hi!

> Am 20.07.2015 um 00:07 schrieb Marek Vasut:
> > On Monday, July 20, 2015 at 12:04:56 AM, Stefan Wahren wrote:
> >> This patch series brings read-only support for the On-Chip OTP cells
> >> in the i.MX23 and i.MX28 processor.
> >> 
> >> It has been a long time since V3 of this series [1]. The last version
> >> has been rejected because there was no standard interface to the OTP
> >> data. So this version bases on V7 of the new NVMEM framework [2] which
> >> required a nearly complete rewrite of the driver.
> >> 
> >> [1] -
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/29522
> >> 8. html [2] -
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355652.h
> >> tm l
> > 
> > Are you sure you even want this support in kernel ?
> 
> definitely. But only read-only support make sense. Please believe me, i
> didn't wait since last year for the NVMEM framework just for fun.

:)

> > Isn't it enough to have
> > this in some manufacturing-time mutated bootloader to program the OTP
> > once and never touch it again ?
> 
> No, our products uses a previous version of this patch series to set the
> MAC address of a network interface from OTP data. I also get some
> feedback from other users that they are happy about this driver.

OK, now I understand. This makes perfect sense indeed.

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Cc: Srinivas Kandagatla
	<srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	Fabio Estevam
	<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Sanchayan Maity
	<maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28
Date: Mon, 20 Jul 2015 10:16:05 +0200	[thread overview]
Message-ID: <201507201016.05699.marex@denx.de> (raw)
In-Reply-To: <55AC970D.6090707-eS4NqCHxEME@public.gmane.org>

On Monday, July 20, 2015 at 08:37:01 AM, Stefan Wahren wrote:
> Hi Marek,

Hi!

> Am 20.07.2015 um 00:07 schrieb Marek Vasut:
> > On Monday, July 20, 2015 at 12:04:56 AM, Stefan Wahren wrote:
> >> This patch series brings read-only support for the On-Chip OTP cells
> >> in the i.MX23 and i.MX28 processor.
> >> 
> >> It has been a long time since V3 of this series [1]. The last version
> >> has been rejected because there was no standard interface to the OTP
> >> data. So this version bases on V7 of the new NVMEM framework [2] which
> >> required a nearly complete rewrite of the driver.
> >> 
> >> [1] -
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/29522
> >> 8. html [2] -
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355652.h
> >> tm l
> > 
> > Are you sure you even want this support in kernel ?
> 
> definitely. But only read-only support make sense. Please believe me, i
> didn't wait since last year for the NVMEM framework just for fun.

:)

> > Isn't it enough to have
> > this in some manufacturing-time mutated bootloader to program the OTP
> > once and never touch it again ?
> 
> No, our products uses a previous version of this patch series to set the
> MAC address of a network interface from OTP data. I also get some
> feedback from other users that they are happy about this driver.

OK, now I understand. This makes perfect sense indeed.

Best regards,
Marek Vasut
--
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

  reply	other threads:[~2015-07-20  8:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-19 22:04 [PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28 Stefan Wahren
2015-07-19 22:04 ` Stefan Wahren
2015-07-19 22:04 ` [PATCH V4 RFC 1/3] DT: nvmem: add binding for mxs-ocotp Stefan Wahren
2015-07-19 22:04   ` Stefan Wahren
2015-07-19 22:04 ` [PATCH V4 RFC 2/3] nvmem: add driver for ocotp in i.MX23 and i.MX28 Stefan Wahren
2015-07-19 22:04   ` Stefan Wahren
2015-07-19 22:12   ` Marek Vasut
2015-07-19 22:12     ` Marek Vasut
2015-07-20  6:45     ` Stefan Wahren
2015-07-20  6:45       ` Stefan Wahren
2015-07-20  8:15       ` Marek Vasut
2015-07-20  8:15         ` Marek Vasut
2015-07-19 22:04 ` [PATCH V4 RFC 3/3] mxs: enable ocotp for " Stefan Wahren
2015-07-19 22:04   ` Stefan Wahren
2015-07-19 22:07 ` [PATCH V4 RFC 0/3] nvmem: add ocotp support " Marek Vasut
2015-07-19 22:07   ` Marek Vasut
2015-07-20  6:37   ` Stefan Wahren
2015-07-20  6:37     ` Stefan Wahren
2015-07-20  8:16     ` Marek Vasut [this message]
2015-07-20  8:16       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201507201016.05699.marex@denx.de \
    --to=marex@denx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.