From: hujianyang <hujianyang@huawei.com>
To: Joseph Balough <jbb5044@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 1/2] mtd: ubiformat: Add --confirm argument
Date: Wed, 7 Jan 2015 09:56:30 +0800 [thread overview]
Message-ID: <54AC924E.80805@huawei.com> (raw)
In-Reply-To: <CACuXwh49YRxqYMHyu_8YH3_VW_EaT4hAuxEWyXWosczZPbfdnA@mail.gmail.com>
On 2015/1/7 4:27, Joseph Balough wrote:
>
>
> On Sat, Jan 3, 2015 at 9:31 PM, hujianyang <hujianyang@huawei.com <mailto:hujianyang@huawei.com>> wrote:
>
> This option 'c' seems only use when *flash-image* is specified. So maybe you
> can check the validity of this option depending on *args.image* in parse_opt().
>
>
> That's a good idea. I'll do that and send an updated patch.
>
> Do we have a function like *mtd_write_and_check()*? I think the operation
> first write and then check it by reading may be used in many cases.
>
>
> I looked through the libmtd source and didn't see an already existing mtd_write_and_check function (or anything like it). And in the whole mtd-utils repository, only ubiformat and nandwrite actually use the mtd_write function itself.
>
Er, I'm not sure if it's related to CONFIG_MTD_NAND_VERIFY_WRITE or
something else.
Actually, I'm writing a script to check nand state. This script will
first write some bytes to nand and then read back to check. After
repeating several times, production team will ensure whether the nand
in their product is in right state and sell them out.
That's why I need a function like *mtd_write_and_check*. I don't think
it's necessarily for your need.
>
> It's worthy to check the writing data of the *flash-image* without any
> additional options in my considering.
>
>
> I feel like most programs like this require an additional argument to check the written data which is why I made it a separate argument. I can change it to be default behavior if that is desired.
>
I'm not the maintainer of the utility, you can resend a new version and
wait for Artem's reply.
Thanks,
Hu
next prev parent reply other threads:[~2015-01-07 1:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 14:58 [PATCH 0/2] mtd: ubiformat: Add support for image confirmation Joe Balough
2014-12-31 14:58 ` [PATCH 1/2] mtd: ubiformat: Add --confirm argument Joe Balough
2015-01-04 2:31 ` hujianyang
[not found] ` <CACuXwh49YRxqYMHyu_8YH3_VW_EaT4hAuxEWyXWosczZPbfdnA@mail.gmail.com>
2015-01-07 1:56 ` hujianyang [this message]
2014-12-31 14:58 ` [PATCH 2/2] mtd: ubiformat: Add confirmation fail exit Joe Balough
2015-01-04 2:38 ` hujianyang
[not found] ` <CACuXwh5eGfpQ6=qJH2_O5yGiK82pxF1mJHaG8X+Hpa50P5PZww@mail.gmail.com>
2015-01-06 1:48 ` hujianyang
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=54AC924E.80805@huawei.com \
--to=hujianyang@huawei.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=jbb5044@gmail.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.