From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: marex@denx.de, vigneshr@ti.com, richard@nod.at,
linux-kernel@vger.kernel.org, boris.brezillon@collabora.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com
Subject: Re: [PATCH v2] mtd: spi-nor: keep lock bits if they are non-volatile
Date: Wed, 22 Jan 2020 06:58:38 +0000 [thread overview]
Message-ID: <1658390.DVVSh22Ze7@192.168.0.113> (raw)
In-Reply-To: <5323055.WqobA3rpa8@192.168.0.113>
Michael,
To be more explicit:
On Tuesday, January 21, 2020 8:53:20 PM EET Tudor Ambarus wrote:
> Yes but that was the whole idea of this patch. So if I get you correct
>
> > it is
> > not possible to change that even if:
> >
> > (1) it was never intended that way. Eg. the original patch(es) were
> > about
> > removing the volatile write protection (which makes perfectly sense,
> > even
> > during probe time) to be able to write to the flash. But it was never
> > intended
> > to disable the non-volatile write protection.
Even if this is true, we can't break backward compat.
> >
> > (2) it might be even harmful. It is still an open question wether the
> > write
> > to the non-volatile bits (even if it is the same value) might wear them
> > out.
> > Unfortunately our FAE didn't answered yet..
> >
We'll think about this when we know for sure.
> > (3) it makes the write protection utterly useless, because if you lock
> > the
> > flash it will be automatically unlocked after the next reboot. Even
> > worse, the
> > user likely won't notice it.
Even if this is true, we can't break backward compat.
>
> Breaking backward compatibility and keeping the locking state of the spi-nor
> flashes at probe is a no-go, because there might be user space apps that
> expect that all the spi-nor flashes are by default unlocked. The unlocking
> of the flash at probe time was introduced 12 years ago, we definitely can't
> change this now.
Kconfig option or module param will fix this without breaking backward compat,
we should focus on this direction.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: <vigneshr@ti.com>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <richard@nod.at>,
<boris.brezillon@collabora.com>, <miquel.raynal@bootlin.com>,
<marex@denx.de>
Subject: Re: [PATCH v2] mtd: spi-nor: keep lock bits if they are non-volatile
Date: Wed, 22 Jan 2020 06:58:38 +0000 [thread overview]
Message-ID: <1658390.DVVSh22Ze7@192.168.0.113> (raw)
In-Reply-To: <5323055.WqobA3rpa8@192.168.0.113>
Michael,
To be more explicit:
On Tuesday, January 21, 2020 8:53:20 PM EET Tudor Ambarus wrote:
> Yes but that was the whole idea of this patch. So if I get you correct
>
> > it is
> > not possible to change that even if:
> >
> > (1) it was never intended that way. Eg. the original patch(es) were
> > about
> > removing the volatile write protection (which makes perfectly sense,
> > even
> > during probe time) to be able to write to the flash. But it was never
> > intended
> > to disable the non-volatile write protection.
Even if this is true, we can't break backward compat.
> >
> > (2) it might be even harmful. It is still an open question wether the
> > write
> > to the non-volatile bits (even if it is the same value) might wear them
> > out.
> > Unfortunately our FAE didn't answered yet..
> >
We'll think about this when we know for sure.
> > (3) it makes the write protection utterly useless, because if you lock
> > the
> > flash it will be automatically unlocked after the next reboot. Even
> > worse, the
> > user likely won't notice it.
Even if this is true, we can't break backward compat.
>
> Breaking backward compatibility and keeping the locking state of the spi-nor
> flashes at probe is a no-go, because there might be user space apps that
> expect that all the spi-nor flashes are by default unlocked. The unlocking
> of the flash at probe time was introduced 12 years ago, we definitely can't
> change this now.
Kconfig option or module param will fix this without breaking backward compat,
we should focus on this direction.
Cheers,
ta
next prev parent reply other threads:[~2020-01-22 6:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 22:12 [PATCH v2] mtd: spi-nor: keep lock bits if they are non-volatile Michael Walle
2020-01-03 22:12 ` Michael Walle
2020-01-11 13:46 ` Tudor.Ambarus
2020-01-11 13:46 ` Tudor.Ambarus
2020-01-11 22:50 ` Michael Walle
2020-01-11 22:50 ` Michael Walle
2020-01-21 18:53 ` Tudor.Ambarus
2020-01-21 18:53 ` Tudor.Ambarus
2020-01-22 6:58 ` Tudor.Ambarus [this message]
2020-01-22 6:58 ` Tudor.Ambarus
2020-01-22 12:10 ` Vignesh Raghavendra
2020-01-22 12:10 ` Vignesh Raghavendra
2020-01-22 12:44 ` Michael Walle
2020-01-22 12:44 ` Michael Walle
2020-01-23 17:20 ` Vignesh Raghavendra
2020-01-23 17:20 ` Vignesh Raghavendra
2020-03-27 14:41 ` Michael Walle
2020-03-27 14:41 ` Michael Walle
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=1658390.DVVSh22Ze7@192.168.0.113 \
--to=tudor.ambarus@microchip.com \
--cc=boris.brezillon@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/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.