All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/1] fw_setenv always locks flash whenever it tries to write
Date: Thu, 30 Jul 2020 10:24:42 -0400	[thread overview]
Message-ID: <20200730142442.GH6965@bill-the-cat> (raw)
In-Reply-To: <185eb61bef5de1ee423723625206b8feabe040bf.camel@gmail.com>

On Thu, Jul 23, 2020 at 10:20:55PM +0000, Ivan Mikhaylov wrote:
> On Fri, 2020-07-10 at 19:54 +0300, Ivan Mikhaylov wrote:
> > fw_setenv usage always locks u-boot-env mtd device without questions.
> > Locking of flash can be disruptive and may affect not only u-boot-env
> > region due to different problems with chips and lock callbacks on
> > kernel
> > side. I'm not sure if my fix is right, but also I thought about
> > possible option
> > in fw_env config about locking/unlocking or even option into
> > fw_setenv/printenv. Any ideas?
> > 
> > Ivan Mikhaylov (1):
> >   fw_setenv: lock the flash only if it was locked before
> > 
> >  tools/env/fw_env.c | 24 +++++++++++++++++++-----
> >  1 file changed, 19 insertions(+), 5 deletions(-)
> > 
> 
> A little bit more description:
> 
> With current implementation of fw_setenv, it is always locks u-boot-env 
> region if lock interface is implemented for such mtd device. You can
> not control lock of this region with fw_setenv, there is no option for
> it in config or in application itself. Because of this situation may
> happen problems like in this thread on xilinx forum:
> https://forums.xilinx.com/t5/Embedded-Linux/Flash-be-locked-after-use-fw-setenv-from-user-space/td-p/1027851
> 
> Short desc link: some person has issue with some spi chip which has
> lock interface but doesn't locks properly which leads to lock of whole
> flash memory on lock of u-boot-env region. As resulted solution hack
> was added into spi-nor.c driver for this chip with lock disablement.
> 
> And for solving such issue usually:
> 1. do manual unlock after each fw_setenv usage.
> 2. do hacks inside driver representing your device, as example in spi-
> nor.c linux driver.
> 
> And, yes, in this case it is problem of two sides:
> 1. driver lock implementation for some chips.
> 2. fw_setenv's way of work which is not trying be convenient in this
> case and is not providing any option for not doing locks.
> 
> I want to implement some mechanism which will help user do not lock
> flash when it's not needed. So there is some points how it can be:
> 1. lock this region if it's already locked.
> 2. add option into fw_setenv application.
> 3. add some option about locks into fw_env.config.
> 
> Patch what I've, just dirty implementation of first one.
> Any ideas or suggestions?

Thanks.  I've taken the above and updated the commit message more.  I'm
currently reviewing the patch with other env changes now.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200730/a8d62d61/attachment.sig>

  reply	other threads:[~2020-07-30 14:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 16:54 [PATCH 0/1] fw_setenv always locks flash whenever it tries to write Ivan Mikhaylov
2020-07-10 16:54 ` [PATCH 1/1] fw_setenv: lock the flash only if it was locked before Ivan Mikhaylov
2020-07-31 21:40   ` Tom Rini
2020-07-23 22:20 ` [PATCH 0/1] fw_setenv always locks flash whenever it tries to write Ivan Mikhaylov
2020-07-30 14:24   ` Tom Rini [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-05-06  1:24 Ivan Mikhaylov

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=20200730142442.GH6965@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.