mtd: Changes for 6.17
Miquel Raynal
maintainerHello Linus,
I was on my side on vacation the past weeks, I've tried to make this up as fast as possible for you to merge before your trip, so here is the MTD PR for 6.17.
Thanks,
Miquèl
The following changes since commit d0b3b7b22dfa1f4b515fd3a295b3fd958f9e81af:
Linux 6.16-rc4 (2025-06-29 13:09:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.17
for you to fetch changes up to 9cf9db888f387844e063efc6296e9fa5c042995e:
Merge tag 'nand/for-6.17' into mtd/next (2025-07-31 18:52:16 +0200)
----------------------------------------------------------------
* MTD changes:
Apart from a binding conversion to yaml, only minor changes/small fixes have been merged.
* Raw NAND changes:
Various controller drivers received minor fixes like DMA mapping checks, better timing derivations or bitflip statistics.
It has also been discovered that some Hynix NAND flashes were not supporting read-retries, which is not properly supported.
* SPI NAND changes:
In order to support high-speed modes, certain chips need extra configuration like adding more dummy cycles. This is now possible, especially on Winbond chips.
Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).
* SPI NOR changes:
A notable changes is the fix for exiting 4-byte addressing on Infineon SEMPER flashes. These flashes do not support the standard EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.
There is also a fix for unlocking flashes that are write-protected at power-on. This was caused by using an uninitialized mtd_info in spi_nor_try_unlock_all().
----------------------------------------------------------------
Andy Shevchenko (1):
mtd: map: Don't use "proxy" headers
Arnd Bergmann (1):
mtd: nftl: reduce stack usage in NFTL_movebuf()
Balamanikandan Gunasundar (1):
mtd: rawnand: atmel: set pmecc data setup time
Christophe JAILLET (1):
mtd: spi-nor: Constify struct spi_nor_fixups
David Regan (1):
mtd: nand: brcmnand: fix mtd corrected bits stat
Frank Li (2):
dt-bindings: mtd: convert nxp-spifi.txt to yaml format
dt-bindings: mtd: jedec,spi-nor: Add atmel,at26* compatible string
Gabor Juhos (1):
mtd: spinand: propagate spinand_wait() errors from spinand_write_page()
Hector Palacios (1):
mtd: rawnand: hynix: don't try read-retry on SLC NANDs
Ivan Stepchenko (1):
mtd: fix possible integer overflow in erase_xfer()
Michael Walle (1):
mtd: spi-nor: Fix spi_nor_try_unlock_all()
Miquel Raynal (10):
spi: spi-mem: Use picoseconds for calculating the op durations
spi: spi-mem: Take into account the actual maximum frequency
mtd: spinand: Fix macro alignment
mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants
mtd: spinand: Add a ->configure_chip() hook
mtd: spinand: winbond: Enable high-speed modes on w25n0xjw
mtd: spinand: winbond: Enable high-speed modes on w35n0xjw
mtd: spinand: winbond: Add comment about the maximum frequency Merge tag 'spi-nor/for-6.17' into mtd/next
Merge tag 'nand/for-6.17' into mtd/next
Takahiro Kuwano (1):
mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER
Teng Wu (1):
mtd: spinand: gigadevice: Add support for GD5F1GM9 chips
Thomas Fourier (4):
mtd: rawnand: renesas: Add missing check after DMA map
mtd: rawnand: atmel: Fix dma_mapping_error() address
mtd: rawnand: rockchip: Add missing check after DMA map
mtd: rawnand: fsmc: Add missing check after DMA map
Yuesong Li (1):
mtd: nand: brcmnand: replace manual string choices with standard helpers
.../devicetree/bindings/mtd/jedec,spi-nor.yaml | 2 +- .../devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml | 74 ++++++++++ .../devicetree/bindings/mtd/nxp-spifi.txt | 58 -------- drivers/mtd/ftl.c | 2 +- drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +- drivers/mtd/nand/raw/atmel/pmecc.c | 6 + drivers/mtd/nand/raw/brcmnand/brcmnand.c | 62 +++++--- drivers/mtd/nand/raw/fsmc_nand.c | 2 + drivers/mtd/nand/raw/nand_hynix.c | 4 +- drivers/mtd/nand/raw/renesas-nand-controller.c | 6 + drivers/mtd/nand/raw/rockchip-nand-controller.c | 15 ++ drivers/mtd/nand/spi/alliancememory.c | 12 +- drivers/mtd/nand/spi/ato.c | 6 +- drivers/mtd/nand/spi/core.c | 27 +++- drivers/mtd/nand/spi/esmt.c | 8 +- drivers/mtd/nand/spi/foresee.c | 8 +- drivers/mtd/nand/spi/gigadevice.c | 68 ++++++--- drivers/mtd/nand/spi/macronix.c | 8 +- drivers/mtd/nand/spi/micron.c | 20 +-- drivers/mtd/nand/spi/paragon.c | 12 +- drivers/mtd/nand/spi/skyhigh.c | 12 +- drivers/mtd/nand/spi/toshiba.c | 8 +- drivers/mtd/nand/spi/winbond.c | 163 +++++++++++++++++++-- drivers/mtd/nand/spi/xtx.c | 12 +- drivers/mtd/nftlcore.c | 43 +++--- drivers/mtd/spi-nor/micron-st.c | 8 +- drivers/mtd/spi-nor/spansion.c | 35 ++++- drivers/mtd/spi-nor/swp.c | 19 +-- drivers/spi/spi-mem.c | 27 +++- include/linux/mtd/map.h | 13 +- include/linux/mtd/spinand.h | 70 +++++---- include/linux/spi/spi-mem.h | 2 +- 32 files changed, 556 insertions(+), 258 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml delete mode 100644 Documentation/devicetree/bindings/mtd/nxp-spifi.txt
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
The pull request you sent on Thu, 31 Jul 2025 18:59:44 +0200:
The pull request you sent on Thu, 31 Jul 2025 18:59:44 +0200:
Quoted 1 line
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.gittags/mtd/for-6.17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cbbf0a759ff96c80dfc32192a2cc427b79447f74
Thank you!
Signature · 6 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Miquel,
On Thu, Jul 31 2025, Miquel Raynal wrote:
[...]
Quoted 22 lines
* MTD changes:
Apart from a binding conversion to yaml, only minor changes/small fixes have been merged.
* Raw NAND changes:
Various controller drivers received minor fixes like DMA mapping checks, better timing derivations or bitflip statistics.
It has also been discovered that some Hynix NAND flashes were not supporting read-retries, which is not properly supported.* SPI NAND changes:
In order to support high-speed modes, certain chips need extra configuration like adding more dummy cycles. This is now possible, especially on Winbond chips.
Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).
* SPI NOR changes:
Quoted 7 lines
A notable changes is the fix for exiting 4-byte addressing on Infineon SEMPER flashes. These flashes do not support the standard EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.
There is also a fix for unlocking flashes that are write-protected at power-on. This was caused by using an uninitialized
mtd_infoinspi_nor_try_unlock_all().
I personally think bullet points are a bit easier to read for changelogs compared to paragraphs since there is less filler text needed. For example, my original merge message didn't the "there is also a fix for". It just said "Fix unlocking of...".
Anyway, if you still prefer paragraphs then do let me know and I'll use those next time around and save you some editing.
[...]
Signature · 6 lines
Regards, Pratyush Yadav ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Miquel Raynal
maintainerHello Pratyush,
Quoted 10 lines
Quoted 9 lines
* SPI NOR changes:
A notable changes is the fix for exiting 4-byte addressing on Infineon SEMPER flashes. These flashes do not support the standard EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.
There is also a fix for unlocking flashes that are write-protected at power-on. This was caused by using an uninitialized
mtd_infoinspi_nor_try_unlock_all().
Quoted 7 lines
I personally think bullet points are a bit easier to read for changelogs compared to paragraphs since there is less filler text needed. For example, my original merge message didn't the "there is also a fix for". It just said "Fix unlocking of...".
Anyway, if you still prefer paragraphs then do let me know and I'll use those next time around and save you some editing.
Some time ago Linus asked me to change the content of the PR description (I was mostly listing the patches) and pointed to examples which were mostly plain English, not bullet points. So I changed both the content (hinting what are the major changes and roughly describing the small ones) and the form (no bullet points). I've kept splitting the subsystems with '*' though, as the changes in each subsystem are mostly unrelated.
I'm fine either ways, but I assumed until now that the preferred form was plain text descriptions.
Cheers,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 28 lines · Miquel Raynal
Hello Pratyush,
Quoted 10 lines
Quoted 9 lines
* SPI NOR changes:
A notable changes is the fix for exiting 4-byte addressing on Infineon SEMPER flashes. These flashes do not support the standard EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.
There is also a fix for unlocking flashes that are write-protected at power-on. This was caused by using an uninitialized
mtd_infoinspi_nor_try_unlock_all().Quoted 7 lines
I personally think bullet points are a bit easier to read for changelogs compared to paragraphs since there is less filler text needed. For example, my original merge message didn't the "there is also a fix for". It just said "Fix unlocking of...".
Anyway, if you still prefer paragraphs then do let me know and I'll use those next time around and save you some editing.
Some time ago Linus asked me to change the content of the PR description (I was mostly listing the patches) and pointed to examples which were mostly plain English, not bullet points. So I changed both the content (hinting what are the major changes and roughly describing the small ones) and the form (no bullet points). I've kept splitting the subsystems with '*' though, as the changes in each subsystem are mostly unrelated.
Quoted 2 lines
I'm fine either ways, but I assumed until now that the preferred form was plain text descriptions.
Okay, fair enough. I can do plain text next time around.
Signature · 6 lines
Regards, Pratyush Yadav ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 6 lines · Pratyush Yadav
Quoted 4 lines
I'm fine either ways, but I assumed until now that the preferred form was plain text descriptions.
Okay, fair enough. I can do plain text next time around.
I'm actually fine either way - what I care about is that it's a human-readable explanation of what is going on, and what I get when I pull.
It should also strive to not only be relevant to me when I pull, but also hopefully be relevant to others if they end up having to look at the resulting merge - perhaps due to bugs that got introduced.
So in a perfect world, think about how to explain to me what I'm getting in the pull, but also explaining to somebody who is in the middle of a bisect, and notices that the problem they are trying to figure out was introduced by merging that tree/
Or maybe the bisect is down to two or three merges, and the person bisecting - who does *NOT* necessarily know anything about those subsystems - is trying to judge what is the most likely culprit to speed up bisection. A good merge message - from the pull request - gives outsiders a feel for what hs going on and whether that merge is likely to be relevant to them.
(And yes, I often find myself to be that person: I bisect some issue pretty much every single merge window, and while I usually have a good idea of what is going on, and just trust "git bisect" to do the right thing, I *do* end up looking back at merges to see where I am in the bisection process)
It can be bullet points when that makes sense, or it can be more of a plain text explanation of the background to a change.
What I don't want is some cryptic "this is just the shortlog". I can see that in git. The difference between a shortlog and a commit message is that the commit message should *explain* what is going on.
Sometimes the two can be the same. Sometimes things are just so obvious that they don't need further explanation than a one-liner. If a commit fixes a NULL pointer dereference due to a missing check, it's not like you need to say more than that.
Also note that sometimes the explanation can be *shorter* than the shortlog. If there are a hundred small independent details that got fixed, listing them one by one doesn't make it human-readable.
So being human-readable can mean expanding on *why* something happened. But it can also be about giving a top-level view of lots of individually irrelevant details.
Linus
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Miquel Raynal
maintainerHello,
Quoted 11 lines · Linus Torvalds
Quoted 6 lines · Pratyush Yadav
Quoted 4 lines
I'm fine either ways, but I assumed until now that the preferred form was plain text descriptions.
Okay, fair enough. I can do plain text next time around.
I'm actually fine either way - what I care about is that it's a human-readable explanation of what is going on, and what I get when I pull.
[...]
Quoted 5 lines
(And yes, I often find myself to be that person: I bisect some issue pretty much every single merge window, and while I usually have a good idea of what is going on, and just trust "git bisect" to do the right thing, I *do* end up looking back at merges to see where I am in the bisection process)
:)
Quoted 2 lines
It can be bullet points when that makes sense, or it can be more of a plain text explanation of the background to a change.
Thanks Linus for the detailed answer.
Pratyush, I guess I'll switch back to bullet points to highlight what are the important changes, so you can stick to what you were doing. If I feel like plain text would be sometimes better I might mix both occasionally.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/