public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Aaron Sierra <asierra@xes-inc.com>
Cc: David Woodhouse <dwmw2@infradead.org>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/2] mtd: map_rom: Support UBI on ROM
Date: Tue, 16 Dec 2014 18:33:44 -0800	[thread overview]
Message-ID: <20141217023344.GS9759@ld-irv-0074> (raw)
In-Reply-To: <673100209.65720.1411665624206.JavaMail.zimbra@xes-inc.com>

Hi Aaron,

I see this has been sitting around way too long...

On Thu, Sep 25, 2014 at 12:20:24PM -0500, Aaron Sierra wrote:
> UBI needs to know the physical erase block size, even on read-only
> devices, since it defines the on-device layout. Use a device-tree
> provided value to support previously written UBI on read-only NOR.
> 
> UBI also needs a non-zero writebufsize, so we set it to one.

Hmm, this one is a pretty big bug IIRC (don't you get an OOPS or
BUG()?). Do you think it might be worth splitting into a separate patch
and sending to stable?

But then I'm curious: how do you get anything useful out of using UBI on
a read-only device? You don't need to (and can't) handle anything like
read disturb, and there's no write wear that needs to be leveled.

> 
> Note: This was implemented because hardware write-protected CFI
>       NOR cannot be probed for the physical erase block size.
> 
> Signed-off-by: Joe Schultz <jschultz@xes-inc.ccom>
> Signed-off-by: Aaron Sierra <asierra@xes-inc.ccom>
> ---
>  Documentation/devicetree/bindings/mtd/mtd-physmap.txt |  5 +++++
>  drivers/mtd/chips/map_rom.c                           | 13 ++++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> index 6b9f680..8ab16df 100644
> --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> @@ -36,6 +36,11 @@ are defined:
>   - vendor-id : Contains the flash chip's vendor id (1 byte).
>   - device-id : Contains the flash chip's device id (1 byte).
>  
> +For ROM compatible devices (and ROM fallback from cfi-flash), the following
> +additional property is defined:
> +
> + - erase-size : The chip's physical erase block size in bytes.
> +
>  The device tree may optionally contain sub-nodes describing partitions of the
>  address space. See partition.txt for more detail.
>  
> diff --git a/drivers/mtd/chips/map_rom.c b/drivers/mtd/chips/map_rom.c
> index 47a43cf..a831265 100644
> --- a/drivers/mtd/chips/map_rom.c
> +++ b/drivers/mtd/chips/map_rom.c
> @@ -11,6 +11,7 @@
>  #include <linux/errno.h>
>  #include <linux/slab.h>
>  #include <linux/init.h>
> +#include <linux/of.h>
>  #include <linux/mtd/mtd.h>
>  #include <linux/mtd/map.h>
>  
> @@ -28,6 +29,15 @@ static struct mtd_chip_driver maprom_chipdrv = {
>  	.module	= THIS_MODULE
>  };
>  
> +static unsigned int default_erasesize(struct map_info *map)
> +{
> +	const __be32 *erase_size = NULL;
> +#ifdef CONFIG_OF
> +	erase_size = of_get_property(map->device_node, "erase-size", NULL);
> +#endif

I think you can just drop the #ifdef and have the same effect, no?

> +	return !erase_size ? map->size : be32_to_cpu(*erase_size);
> +}
> +
>  static struct mtd_info *map_rom_probe(struct map_info *map)
>  {
>  	struct mtd_info *mtd;
> @@ -47,8 +57,9 @@ static struct mtd_info *map_rom_probe(struct map_info *map)
>  	mtd->_sync = maprom_nop;
>  	mtd->_erase = maprom_erase;
>  	mtd->flags = MTD_CAP_ROM;
> -	mtd->erasesize = map->size;
> +	mtd->erasesize = default_erasesize(map);
>  	mtd->writesize = 1;
> +	mtd->writebufsize = 1;
>  
>  	__module_get(THIS_MODULE);
>  	return mtd;

Brian

  reply	other threads:[~2014-12-17  2:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1683475520.65208.1411665491176.JavaMail.zimbra@xes-inc.com>
2014-09-25 17:20 ` [PATCH 2/2] mtd: map_rom: Support UBI on ROM Aaron Sierra
2014-12-17  2:33   ` Brian Norris [this message]
2014-12-17  9:37     ` Ricard Wanderlof
2014-12-17 16:04       ` Aaron Sierra
2014-12-17 20:13     ` Aaron Sierra
2015-01-10  7:31   ` Brian Norris

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=20141217023344.GS9759@ld-irv-0074 \
    --to=computersforpeace@gmail.com \
    --cc=asierra@xes-inc.com \
    --cc=dwmw2@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox