mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] environment: do not attempt to erase devices with MTD_NO_ERASE
Date: Fri, 23 Nov 2018 09:05:22 +0100	[thread overview]
Message-ID: <20181123080522.5vwc4makxbhycscq@pengutronix.de> (raw)
In-Reply-To: <e8a745f8ce80ae9a17cb3d7278732d77cec8277f.camel@ew.tq-group.com>

On Thu, Nov 22, 2018 at 11:19:30AM +0100, Matthias Schiffer wrote:
> On Wed, 2018-11-21 at 08:56 +0100, Sascha Hauer wrote:
> > Hi Matthias,
> > 
> > On Tue, Nov 20, 2018 at 10:40:34AM +0100, 
> > matthias.schiffer@ew.tq-group.com wrote:
> > > From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > > 
> > > Devices like MRAM do not need to be erased; in fact, trying to do a
> > > partial
> > > erase will fail with -EINVAL, as they don't have a proper erase
> > > block size
> > > defined.
> > 
> > Where does this -EINVAL come from? Wouldn't it be an option to check
> > for
> > the MTD_NO_ERASE flag mtd_op_erase() and return -EOPNOTSUPP there?
> > 
> > Sascha
> > 
> 
> Hmm, what are the expected semantics of MTD_NO_ERASE - "does not need
> erase" or "does not support erase"? According to code comments, it's
> the former.
> 
> The MRAM I'm working with reports an erase size equal to its total
> size:
> 
> barebox:/ devinfo m25p0
> Parameters:
>   erasesize: 131072 (type: uint32)
>   oobsize: 0 (type: uint32)
>   partitions: 128k(barebox-environment) (type: string)
>   size: 131072 (type: uint64)
>   writesize: 1 (type: uint32)
> 
> This matches what Linux reports, but it seems to me that this MRAM does
> not actually implement it: When I try to erase the whole flash (from
> Linux or Barebox), it does return success, but the data is unchanged.

So actually your device does not support erase. I'd say "does not
support erase" is the correct semantics for MTD_NO_ERASE, at least I
can't think of any devices that support an optional erase operation.

> When I configure the environment to span the whole flash, envfs_save()
> is working fine without my patch, as the erase is successful.
> 
> The problems start when I try to partition the MRAM, as envfs_save()
> will now try to erase a block smaller than the erasesize, leading to
> -EINVAL.

The MRAM specifies an erasesize of 128KiB and then afterwards an erase
operation is a no-op. This seems wrong, at least inconsistent. This
should be discussed on the Linux mtd list.

For barebox I think it's fine to return -EOPNOTSUPP for devices which
have the MTD_NO_ERASE flag. At least for your device this return value
really is correct.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2018-11-23  8:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  9:40 [PATCH] clk: fix NULL deref without OF node in debug message matthias.schiffer
2018-11-20  9:40 ` [PATCH] environment: do not attempt to erase devices with MTD_NO_ERASE matthias.schiffer
2018-11-21  7:56   ` Sascha Hauer
2018-11-22 10:19     ` Matthias Schiffer
2018-11-23  8:05       ` Sascha Hauer [this message]
2018-11-23 14:50         ` [PATCH v2] mtd: return EOPNOTSUPP when attempting to erase an MTD_NO_ERASE device Matthias Schiffer
2018-11-26  7:46           ` Sascha Hauer
2018-11-20  9:40 ` [PATCH] FIT: look for hash-1 as well as hash@1 nodes in signature check matthias.schiffer
2018-11-21  8:01   ` Sascha Hauer
2018-11-22 10:41     ` [PATCH v2] FIT: support hash-1/signature-1 " Matthias Schiffer
2018-11-23  8:07 ` [PATCH] clk: fix NULL deref without OF node in debug message Sascha Hauer

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=20181123080522.5vwc4makxbhycscq@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=matthias.schiffer@ew.tq-group.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox