From: Rahul Bedarkar <firstname.lastname@example.org>
To: <email@example.com>, <firstname.lastname@example.org>
Cc: Rahul Bedarkar <email@example.com>,
David Woodhouse <firstname.lastname@example.org>,
Brian Norris <email@example.com>,
Boris Brezillon <firstname.lastname@example.org>,
Marek Vasut <email@example.com>,
Richard Weinberger <firstname.lastname@example.org>,
Cyrille Pitchen <email@example.com>
Subject: [RFC 0/6] Add user OTP support in SPI-NOR
Date: Fri, 17 Mar 2017 18:13:50 +0530 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Many NOR flash chips comes with One-Time-Programmable area a.k.a
security registers. This RFC patchset aims at adding generic OTP
support in SPI-NOR to read/write user OTP area.
In SPI-NOR framework, OTP specific read/write methods will use
read_xfer/write_xfer hooks. So PATCH 1, reverts "unused read_xfer/
PATCH 2 changes return value of read_xfer/write_xfer to allow
returning amount of data transferred and errors as read(2)/write(2).
This makes them inline with current read/write hooks.
PATCH 3 modified helpers in m25p80.c so that those can be used
from read_xfer/write_xfer methods.
PATCH 4 implements read_xfer/write_xfer in m25p80.c
PATCH 5 implements generic support to read/write user OTP.
And finally in PATCH 6 user OTP support for s25fl016k is enabled.
Overall changes are as follows:
New flag SPI_NOR_HAS_OTP is added to specify chip has OTP area. Using
OTP_INFO macro, details of OTP area can be specified. It includes size
of area, number of OTP areas/banks, starting address and difference
between consecutive OTP banks. OTP framework will give user linear
address view from 0 to size of OTP area. User don't need to specify
actual physical address of OTP area for reading/writing.
Details which could be specific to manufacturer like opcodes for
read/write/erase can be specified based on manufacturer.
Generic OTP read/write methods are added so as it can be used for OTP
support from other manufacturer.
This complete patchset is tested with Winbond NOR flash W25Q16DV which
is detected as "s25fl016k" by SPI-NOR.
I've plans to add support for locking these OTP areas and reading
factory OTP area as well. But before that I would to get comments
on this initial part to understand if I'm going in right direction.
Cc: David Woodhouse <email@example.com>
Cc: Brian Norris <firstname.lastname@example.org>
Cc: Boris Brezillon <email@example.com>
Cc: Marek Vasut <firstname.lastname@example.org>
Cc: Richard Weinberger <email@example.com>
Cc: Cyrille Pitchen <firstname.lastname@example.org>
Rahul Bedarkar (6):
Revert "mtd: spi-nor: remove unused read_xfer/write_xfer hooks"
mtd: spi-nor: change return value of read_xfer and write_xfer
mtd: m25p80: don't pass spi_nor to helper methods
mtd: m25p80: implement read_xfer and write_xfer
mtd: spi-nor: add support to read/write user OTP
mtd: spi-nor: enable OTP support for s25fl016k
drivers/mtd/devices/m25p80.c | 111 ++++++++++++---
drivers/mtd/spi-nor/spi-nor.c | 314 +++++++++++++++++++++++++++++++++++++++++-
include/linux/mtd/spi-nor.h | 52 +++++++
3 files changed, 460 insertions(+), 17 deletions(-)
next reply other threads:[~2017-03-17 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 12:43 Rahul Bedarkar [this message]
2017-03-17 12:43 ` [RFC 1/6] Revert "mtd: spi-nor: remove unused read_xfer/write_xfer hooks" Rahul Bedarkar
2017-03-17 12:43 ` [RFC 2/6] mtd: spi-nor: change return value of read_xfer and write_xfer Rahul Bedarkar
2017-03-17 12:43 ` [RFC 3/6] mtd: m25p80: don't pass spi_nor to helper methods Rahul Bedarkar
2017-03-17 12:43 ` [RFC 4/6] mtd: m25p80: implement read_xfer and write_xfer Rahul Bedarkar
2017-03-17 12:43 ` [RFC 5/6] mtd: spi-nor: add support to read/write user OTP Rahul Bedarkar
2017-03-17 12:43 ` [RFC 6/6] mtd: spi-nor: enable OTP support for s25fl016k Rahul Bedarkar
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).