[GIT PULL] mtd: Changes for 6.17

[GIT PULL] mtd: Changes for 6.17

[Miquel Raynal]

Hello 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/

Re: [GIT PULL] mtd: Changes for 6.17

[pr-tracker-bot]

The pull request you sent on Thu, 31 Jul 2025 18:59:44 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.17

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cbbf0a759ff96c80dfc32192a2cc427b79447f74

Thank you!

-- 
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/

Re: [GIT PULL] mtd: Changes for 6.17

[Pratyush Yadav]

Hi Miquel,

On Thu, Jul 31 2025, Miquel Raynal wrote:

[...]
> * 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().

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.

[...]

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [GIT PULL] mtd: Changes for 6.17

[Miquel Raynal]

Hello Pratyush,

>> * 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().
>
> 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/

Re: [GIT PULL] mtd: Changes for 6.17

[Pratyush Yadav]

On Fri, Aug 01 2025, Miquel Raynal wrote:

> Hello Pratyush,
>
>>> * 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().
>>
>> 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.

Okay, fair enough. I can do plain text next time around.

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [GIT PULL] mtd: Changes for 6.17

[Linus Torvalds]

On Mon, 4 Aug 2025 at 07:40, Pratyush Yadav <pratyush@kernel.org> wrote:
>
> >
> > 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/

Re: [GIT PULL] mtd: Changes for 6.17

[Miquel Raynal]

Hello,

On 04/08/2025 at 08:53:14 -07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 4 Aug 2025 at 07:40, Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> >
>> > 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.

[...]

> (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.

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/