linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking.
Date: Wed, 20 Jun 2018 14:19:36 +0200	[thread overview]
Message-ID: <20180620141936.1f79cd10@bbrezillon> (raw)
In-Reply-To: <c5c50ddf2e99950dd790a264a5f40eb6e1647a83.camel@infinera.com>

On Wed, 20 Jun 2018 11:10:49 +0000
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:

> On Wed, 2018-06-20 at 11:25 +0200, Boris Brezillon wrote:
> > 
> > 
> > On Wed,  6 Jun 2018 12:13:30 +0200
> > Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote:
> >   
> > > cfi_ppb_unlock() walks all flash chips when unlocking sectors,
> > > avoid walking chips unaffected by the unlock operation.
> > > 
> > > Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
> > > Cc: stable@vger.kernel.org  
> > 
> > That's clearly not a fix, just an optimization. You should drop the
> > Fixes and Cc-stable tags.  
> 
> It sure IS! The code never intended to do this and it is just bad luck that nothing bad
> happened and I sure don't want to walk all 4 chips we have, stealing CPU and keeping the
> flash busy just because I am using stable.

Except it's like that from the beginning, so that's not a regression
you're fixing nor it is a real bug preventing you from using the driver
on your platform. I'm not making the rules of what is appropriate to be
backported and what is not, but I've been told several times that only
patches fixing bugs or perf regressions are supposed to be backported,
and that's not the case here.

> 
> Given I have moved on now and we disagree, I will not reword and resubmit any
> time soon. Feel free to do needed edits though.

I'm sorry, maybe you don't like it but that's the process. I understand
that it's not pleasant to have to send a new version of patches that
you thought were good enough to go upstream, but it's like that. If I
don't apply this rule to you, why should it apply to others.

  reply	other threads:[~2018-06-20 12:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 14:07 [PATCH 1/2] mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips Joakim Tjernlund
2018-06-05 14:07 ` [PATCH 2/2] mtd: cfi_cmdset_0002: Avoid point less unlocking/locking Joakim Tjernlund
2018-06-05 15:14   ` Boris Brezillon
2018-06-05 16:57     ` Joakim Tjernlund
2018-06-06 10:15       ` Joakim Tjernlund
2018-06-19 17:23         ` Joakim Tjernlund
2018-06-05 15:02 ` [PATCH 1/2] mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips Boris Brezillon
2018-06-05 15:26 ` Boris Brezillon
2018-06-05 15:33   ` Joakim Tjernlund
2018-06-06 10:13   ` [PATCH v2 1/4] mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock() Joakim Tjernlund
2018-06-06 10:13     ` [PATCH v2 2/4] mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips Joakim Tjernlund
2018-06-20  9:06       ` Boris Brezillon
2018-06-06 10:13     ` [PATCH v2 3/4] mtd: cfi_cmdset_0002: Avoid point less unlocking/locking Joakim Tjernlund
2018-06-20  9:14       ` Boris Brezillon
2018-06-20 11:10         ` Joakim Tjernlund
2018-06-20 11:54           ` Boris Brezillon
2018-06-06 10:13     ` [PATCH v2 4/4] mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking Joakim Tjernlund
2018-06-20  9:25       ` Boris Brezillon
2018-06-20 11:10         ` Joakim Tjernlund
2018-06-20 12:19           ` Boris Brezillon [this message]
2018-06-20 15:07             ` Joakim Tjernlund
2018-06-20  9:03     ` [PATCH v2 1/4] mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock() Boris Brezillon
2018-06-20 11:10       ` Joakim Tjernlund
2018-06-22 11:35     ` Boris Brezillon

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=20180620141936.1f79cd10@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=Joakim.Tjernlund@infinera.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).