All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Amul Kumar Saha <amul.saha@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	kyungmin.park@samsung.com, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [OneNAND] OTP support re-implementation 1/1
Date: Fri, 28 Aug 2009 16:38:56 +0300	[thread overview]
Message-ID: <1251466736.3514.10.camel@localhost> (raw)
In-Reply-To: <6098B9D32DCD48C387EF96034FFFC55D@sisodomain.com>

On Thu, 2009-08-27 at 12:07 +0530, Amul Kumar Saha wrote:
> >> Re-implemented OTP support for OneNAND
> >> Added following features to OneNAND
> >> 1. Lock only 1st Block in OneNAND
> >> 2. Lock BOTH 1st Block and OTP Block in OneNAND
> >
> > -ENOPARSE
> >
> > Large patches like this normally require good explanations of what is
> > done, why it is done, which problem it solves, how it is done, etc.
> >
> 
> What is OTP in OneNAND?
> The device includes,
> 1. one block-sized OTP (One Time Programmable) area and
> 2. user-controlled 1st block OTP(Block 0)
> that can be used to increase system security or to provide identification capabilities.
> 
> What is done?
> In OneNAND, one block of the NAND Array is set aside as an OTP memory area, and 1st Block (Block 0) 
> can be used as OTP area.
> This area, available to the user, can be configured and locked with secured user information.
> The OTP block can be read, programmed and locked using the same operations as any other NAND Flash 
> Array
> memory block. After issuing an OTP-Lock, OTP block cannot be erased. OTP block is fully-guaranteed 
> to be a valid block.
> 
> Why it is done? (Impact)
> Locking the 1st Block OTP has the effect of a 'Write-protect' to guard against accidental 
> re-programming of data stored in the 1st block and OTP Block.
> 
> Which problem it solves?
> OTP support is provided in the existing implementation of OneNAND/Flex-OneNAND driver, but it is not 
> working with OneNAND devices.
> Have observed the following in current OTP OneNAND Implmentation,
> 1. DataSheet specific sequence to lock the OTP Area is not followed.
> 2. Certain functions are quiet generic to cope with OTP specific activity.
> This patch re-implements OTP support for OneNAND device.
> 
> How it is done?
> For all blocks, 8th word is available to the user.
> However,in case of OTP Block, 8th word of sector 0, page 0 is reserved as OTP Locking Bit area.
> Therefore, in case of OTP Block, user usage on this area is prohibited.
> Condition specific values are entered in the 8th word, sector0, page 0 of the OTP block during the 
> process of issuing an OTP-Lock.
> The possible conditions are:-
> 1. Only 1st Block Lock
> 2. Only OTP Block Lock
> 3. Lock both the 1st Block and the OTP Block
> 
> What feature additions have been done in this patch?
> This patch adds feature for:-
> 1. Only 1st Block Lock
> 2. Lock both the 1st Block and the OTP Block 

Could you insert the description to the patch and re-send it, please?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2009-08-28 13:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 10:43 [PATCH] [OneNAND] OTP support re-implementation 1/1 Amul Kumar Saha
2009-08-26  5:41 ` Amul Kumar Saha
2009-08-26  5:58   ` Artem Bityutskiy
2009-08-27  6:37     ` Amul Kumar Saha
2009-08-28 13:38       ` Artem Bityutskiy [this message]
2009-08-31  9:19         ` Amul Kumar Saha
2009-08-31  9:34           ` Kyungmin Park
2009-09-02  5:55             ` Amul Kumar Saha
2009-09-02  5:59             ` Amul Kumar Saha
2009-09-02  6:10               ` Artem Bityutskiy
2009-09-03  5:51                 ` Amul Kumar Saha
2009-09-03  6:10                   ` Artem Bityutskiy
2009-09-03 10:37                     ` Amul Kumar Saha
2009-09-03 11:19                       ` Artem Bityutskiy
2009-09-07  9:45                         ` Amul Kumar Saha
2009-09-07  9:57                           ` Kyungmin Park
2009-09-16  3:33                             ` Amul Kumar Saha
2009-09-16  6:40                               ` Artem Bityutskiy
2009-09-28  9:38                           ` Artem Bityutskiy
2009-10-01  6:48                             ` Amul Kumar Saha
2009-10-12  4:42                             ` Amul Kumar Saha
  -- strict thread matches above, loose matches on Subject: below --
2009-10-12  6:01 Amul Kumar Saha
2009-10-20  8:56 ` Artem Bityutskiy
2009-10-20 14:13   ` Adrian Hunter
2009-10-21 11:20     ` Amul Kumar Saha
2009-10-23  6:11       ` Artem Bityutskiy
2009-10-21 11:30     ` Amul Kumar Saha

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=1251466736.3514.10.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=amul.saha@samsung.com \
    --cc=dwmw2@infradead.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mtd@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.