[PATCH] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times

[Miquel Raynal]

Hi Tim,

tharvey at gateworks.com wrote on Tue, 25 Oct 2022 15:02:27 -0700:

> On Mon, Oct 24, 2022 at 1:01 AM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >
> > Hi Tim,
> >
> > tharvey at gateworks.com wrote on Fri, 21 Oct 2022 14:55:15 -0700:
> >  
> > > On Fri, Sep 2, 2022 at 12:03 AM Miquel Raynal <miquel.raynal at bootlin.com> wrote:  
> > > >
> > > > Hey folks,
> > > >
> > > > richard at nod.at wrote on Fri, 15 Jul 2022 09:59:10 +0200 (CEST):
> > > >  
> > > > > ----- Ursprüngliche Mail -----  
> > > > > >> My IRC history doesn't go back far enough, but if I recall correctly
> > > > > >> Miquel is on vacation, he would have picked up this patch for linux-next
> > > > > >> otherwise.  
> > > > >
> > > > > Exactly.  
> > > >
> > > > Indeed, I was off for an extended period of time, I'm (very) slowly
> > > > catching up now.
> > > >  
> > > > >  
> > > > > > Ok, let me do a round of stable releases so that people don't get hit by
> > > > > > this now...  
> > > > >
> > > > > Thanks a lot for doing so.
> > > > >  
> > > > > > Hopefully this gets fixed up by 5.19-final.  
> > > > >
> > > > > Sure, I'll pickup this patch.  
> > > >
> > > > Thanks Greg & Richard for the handling of this issue.
> > > >
> > > > Cheers,
> > > > Miquèl
> > > >  
> > >
> > > Hello All,
> > >
> > > As Tomasz stated previously 06781a5026350 was merged in v5.19-rc4 and
> > > then was picked up by several stable kernels. While this made it into
> > > the 5.15 and 5.18 stable branches it did not make it into the
> > > following which are thus the are currently broken:
> > > 5.10.y
> > > 5.17.y
> > >
> > > How do we get this patch applied to those stable branches as well to
> > > resolve this?  
> >
> > It is likely that the original patch (targeting a mainline kernel) did
> > not apply to those branches. In this case you can adapt the fix to the
> > concerned kernels and send it to stable@ (following the Documentation
> > guidelines for backports).
> >
> > Thanks,
> > Miquèl  
> 
> Miquèl,
> 
> Thanks for the pointer. You are correct that this patch which resolves
> the regression does not apply directly to 5.4/5.10/5.17 stable trees.
> I'm looking over
> https://www.kernel.org/doc/html/v4.10/process/stable-kernel-rules.html

Option 3 fits, right?

> and I'm not clear what I need to put in the commit to make it clear
> that it only applies to those specific trees. Do I simply adjust the
> 'Fixes' tag to address the commit from that specific stable branch and
> send one for each stable branch (thus each would have a different sha
> in the Fixes tag) while also adding the 'commit <sha> upstream' to the
> top?

Here are the failures:
https://lore.kernel.org/stable/165858381623360@kroah.com/
https://lore.kernel.org/stable/165858381472139@kroah.com/
https://lore.kernel.org/stable/165858381313218@kroah.com/

You should not adjust the Fixes tag, this tag should really
reflect what you are trying to fix, and not some kind of target for the
backport. However you're changing the commit content so you can also
change the commit log, with eg. the upstream original commit somewhere
there in plain text. You can target a kernel version on the Cc: stable
line (see the doc) and you can also use

	--subject-prefix="PATCH stable <version>"

during git-format-patch, even though I'm not sure this is actually
needed, it's more like courtesy to let reviewers know what you are
doing.

Here is an example, maybe not the best one (forget about the RESEND)
but a typical case:
https://lore.kernel.org/linux-mtd/20220223174431.1083-1-f.fainelli@gmail.com/

Thanks,
Miquèl