Hello Linus,
This is the MTD fixes PR for v5.5-rc6.
Thanks,
Miquèl
The following changes since commit c79f46a282390e0f5b306007bf7b11a46d529538:
Linux 5.5-rc5 (2020-01-05 14:23:27 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/fixes-for-5.5-rc6
for you to fetch changes up to 82de6a6fb67e16a30ec2f586b1f6976c2d7b4b62:
mtd: spi-nor: Fix the writing of the Status Register on micron flashes (2020-01-09 20:11:34 +0100)
----------------------------------------------------------------
MTD:
* sm_ftl: Fix NULL pointer warning.
Raw NAND:
* Cadence: fix compile testing.
* STM32: Avoid locking.
Onenand:
* Fix several sparse/build warnings.
SPI-NOR:
* Add a flag to fix interaction with Micron parts.
----------------------------------------------------------------
Amir Mahdi Ghorbanian (1):
mtd: onenand: omap2: Fix errors in style
Arnd Bergmann (1):
mtd: sm_ftl: fix NULL pointer warning
Christophe Kerello (1):
mtd: rawnand: stm32_fmc2: avoid to lock the CPU bus
Krzysztof Kozlowski (1):
mtd: onenand: samsung: Fix iomem access with regular memcpy
Peter Ujfalusi (1):
mtd: onenand: omap2: Pass correct flags for prep_dma_memcpy
Tudor Ambarus (1):
mtd: spi-nor: Fix the writing of the Status Register on micron flashes
Vasyl Gomonovych (1):
mtd: cadence: Fix cast to pointer from integer of different size warning
drivers/mtd/nand/onenand/omap2.c | 14 ++++++------
drivers/mtd/nand/onenand/onenand_base.c | 14 ++++++------
drivers/mtd/nand/onenand/samsung_mtd.c | 8 +++----
drivers/mtd/nand/raw/cadence-nand-controller.c | 13 ++++++-----
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 38 +++++++++++++++++++++++++++++++--
drivers/mtd/sm_ftl.c | 3 ++-
drivers/mtd/spi-nor/spi-nor.c | 1 +
include/linux/mtd/flashchip.h | 2 +-
8 files changed, 65 insertions(+), 28 deletions(-)
On Fri, Jan 10, 2020 at 6:42 AM Miquel Raynal <[email protected]> wrote:
>
> This is the MTD fixes PR for v5.5-rc6.
Hmm. I've pulled this, I've pushed it out, and I see it on the public
gitweb and I see the email on lore.kernel.org.
But I don't see a pr-tracker-bot reply.
I _did_ get one for Jens' block pull, so pr-tracker-bot is alive. I
can't see why this pull request didn't trigger it, though.
Konstantin, can you see what's wrong?
Linus
On Fri, Jan 10, 2020 at 12:31 PM Linus Torvalds
<[email protected]> wrote:
>
> Konstantin, can you see what's wrong?
It's not just Miquel's. The sound, thermal, and power management fixes
pulls seem to also be lacking pr-tracker-bot responses.
But Jens got one for block - but that went to the block mailing list,
not lkml. So maybe it's specific to lkml itself.
Maybe things are just slow, and I have gotten used to the
almost-instant responses when I do a "git push" to publish my pulls.
Linus
The pull request you sent on Fri, 10 Jan 2020 15:42:18 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/fixes-for-5.5-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4936ce17bf7c4a17a9223a0b7d96c49d62767762
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Fri, Jan 10, 2020 at 12:38:37PM -0800, Linus Torvalds wrote:
> On Fri, Jan 10, 2020 at 12:31 PM Linus Torvalds
> <[email protected]> wrote:
> >
> > Konstantin, can you see what's wrong?
>
> It's not just Miquel's. The sound, thermal, and power management fixes
> pulls seem to also be lacking pr-tracker-bot responses.
>
> But Jens got one for block - but that went to the block mailing list,
> not lkml. So maybe it's specific to lkml itself.
>
> Maybe things are just slow, and I have gotten used to the
> almost-instant responses when I do a "git push" to publish my pulls.
Sorry about that. The public-inbox repository for LKML automatically
rolled over to start a new epoch (from 7.git to 8.git). This only
happens once about every 6-9 months and is such a rare occurrence that
it's hard to properly catch all potential gotchas.
Things should be unstuck now, and at least this particular bug is fixed
-- hopefully it'll be smooth and automatic the next time the epoch rolls
over to 9.git.
Regards,
-K
Hi Konstantin,
On Sat, Jan 11, 2020 at 3:50 PM Konstantin Ryabitsev
<[email protected]> wrote:
> Things should be unstuck now, and at least this particular bug is fixed
> -- hopefully it'll be smooth and automatic the next time the epoch rolls
> over to 9.git.
Are you prepared for multi-digit epochs? ;-)
They not only contain more than one digit, but compare incorrectly
when using lexical sorting...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Jan 13, 2020 at 09:02:44AM +0100, Geert Uytterhoeven wrote:
> > Things should be unstuck now, and at least this particular bug is
> > fixed
> > -- hopefully it'll be smooth and automatic the next time the epoch rolls
> > over to 9.git.
>
> Are you prepared for multi-digit epochs? ;-)
> They not only contain more than one digit, but compare incorrectly
> when using lexical sorting...
I had to check, but yes -- we start from 0 and count up until we get a
"no such dir":
https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/pr-tracker-bot.py#n376
Best,
-K