All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: Mathias Thore <Mathias.Thore@infinera.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Regression for NOR flash with multiple erase block regions
Date: Fri, 22 Sep 2017 22:04:55 +0200	[thread overview]
Message-ID: <20170922220455.04f89f08@bbrezillon> (raw)
In-Reply-To: <74af973f5ae542c3b53240c95949628c@svr-chch-ex1.atlnz.lc>

On Fri, 22 Sep 2017 18:27:42 +0000
Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:

> Hi Mathias,
> 
> On 23/09/17 01:12, Mathias Thore wrote:
> > Hello,
> > 
> > Commit 1eeef2d7483a7e3f8d2dd2a5b9939b3b814dc549 included in Linux 4.13 ( 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/mtdpart.c?h=v4.13&id=1eeef2d7483a7e3f8d2dd2a5b9939b3b814dc549 
> > ) introduces a regression for NOR flash with multiple erase block 
> > regions of different sizes.
> > 
> > Only the largest erase block size seems to be considered when 
> > determining if partitions are aligned. Partitions in smaller regions 
> > will be mounted as read-only. With Linux 4.12 and earlier, read/write 
> > access was available for these partitions.

I don't understand how this could work before this patch? I mean, we
were previously using mtd_mod_by_eb() to check part alignment and
this functions is just returning the remainder of the off / erasesize
division. So, assuming the erasesize of your NOR did not change
between 4.12 and 4.13, I don't see how this commit could cause the
regression you're describing here.

Maybe MTD_NO_ERASE is set on your NOR, and ->writesize is used in place
of ->erasesize to check the alignment, but ->writesize is normally set
to 1 on NOR devices, so again, no real reasons for this failure.

> 
> Sorry about that. I think a fix would be to re-calculate the 
> wr_alignment as we're looking at each erase block. Unfortunately I'm 
> about to get on a plane for 13 hours so I'm pretty much a write off for 
> the next couple of days.
> 
> I'll take a look when I get back on-line unless Boris beats me to it.

  reply	other threads:[~2017-09-22 20:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4762f230bbd3437990b9f5baa61ab095@sv-ex13-prd1.infinera.com>
2017-09-22 18:27 ` Regression for NOR flash with multiple erase block regions Chris Packham
2017-09-22 20:04   ` Boris Brezillon [this message]
2017-09-25  6:28     ` Mathias Thore
2017-09-25  7:30       ` Boris Brezillon
2017-09-25  8:05         ` Mathias Thore
2017-09-25  8:14           ` Boris Brezillon
2017-09-25  8:57             ` Mathias Thore
2017-09-25  9:45               ` Boris Brezillon
2017-09-22 13:15 Mathias Thore

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=20170922220455.04f89f08@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=Mathias.Thore@infinera.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.