Pull mtd updates from Miquel Raynal:
 "MTD changes:

   - Apart from a binding conversion to yaml, only minor changes/small
     fixes have been merged.

  Raw NAND changes:

   - Minor fixes for various controller drivers like DMA mapping checks,
     better timing derivations or bitflip statistics.

   - some Hynix NAND flashes were not supporting read-retries, so don't
     even try to do it

  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()"

* tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (26 commits)
  mtd: spinand: winbond: Add comment about the maximum frequency
  mtd: spinand: winbond: Enable high-speed modes on w35n0xjw
  mtd: spinand: winbond: Enable high-speed modes on w25n0xjw
  mtd: spinand: Add a ->configure_chip() hook
  mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants
  mtd: spinand: Fix macro alignment
  spi: spi-mem: Take into account the actual maximum frequency
  spi: spi-mem: Use picoseconds for calculating the op durations
  mtd: rawnand: atmel: set pmecc data setup time
  mtd: spinand: propagate spinand_wait() errors from spinand_write_page()
  mtd: rawnand: fsmc: Add missing check after DMA map
  mtd: rawnand: rockchip: Add missing check after DMA map
  mtd: rawnand: hynix: don't try read-retry on SLC NANDs
  mtd: rawnand: atmel: Fix dma_mapping_error() address
  mtd: nand: brcmnand: fix mtd corrected bits stat
  mtd: rawnand: renesas: Add missing check after DMA map
  mtd: spinand: gigadevice: Add support for GD5F1GM9 chips
  mtd: nand: brcmnand: replace manual string choices with standard helpers
  mtd: map: Don't use "proxy" headers
  mtd: spi-nor: Fix spi_nor_try_unlock_all()
  ...

In order to pick the best variant, the duration of each typical
operation is derived and then compared. These durations are based on the
maximum capabilities of the chips, which are commonly the limiting
factors. However there are other possible limiting pieces, such as the
hardware layout, EMC considerations and in some cases, the SPI controller
itself.

We need to take this into account to further refine our variant choice,
so let's use the actual frequency that will be used for the operation
instead of the theoretical maximum.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>

We have a system which uses 24 SPI chip selects, raise the hard coded
limit accordingly.

Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://patch.msgid.link/20250629-spi-increase-number-of-cs-v2-1-85a0a09bab32@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>

Pull spi updates from Mark Brown:
 "The bulk of the changes in this release are driver work, as well as
  new device support we have some important work on performance over
  several drivers, and big overhauls for maintainability on a couple
  too. Highlights include:

   - Big cleanups of the sh-msiof driver from Geert Uytterhoeven, and of
     the NXP FSPI driver from Haibo Chen

   - Performance improvements for the AXI SPI engine

   - Support for writes to memory mapped flashes on Renesas devices

   - Integrated DMA support for Tegra210 QSPI, used by the Tegra234

   - DMA support for Amlogic SPI controllers

   - Support for AMD HID2, Qualcomm IPQ5018, Renesas RZ/G3E, Rockchip
     RK3528 and Samsung Exynos Autov920

  An update to fix some issues with the Atmel QSPI driver runtime PM
  pulled in a new API from the PM core, and the Renesas memory mapped
  write changes pull in some code that's shared in drivers/memory"

* tag 'spi-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (90 commits)
  spi: spi-qpic-snand: return early on error from qcom_spi_io_op()
  spi: loopback-test: fix up const pointer issue in rx_ranges_cmp()
  spi: gpio: fix const issue in spi_to_spi_gpio()
  spi: spi-qpic-snand: remove superfluous parameters of qcom_spi_check_error()
  dt-bindings: spi: samsung: add exynosautov920-spi compatible
  spi: spi-qpic-snand: reuse qcom_spi_check_raw_flash_errors()
  spi: dt-bindings: Add rk3528-spi compatible
  spi: spi_amd: Update Kconfig dependencies
  spi: spi_amd: Add HIDDMA basic write support
  spi: spi_amd: Remove read{q,b} usage on DMA buffer
  spi: sh-msiof: Move register definitions to <linux/spi/sh_msiof.h>
  spi: sh-msiof: Document frame start sync pulse mode
  spi: sh-msiof: Double maximum DMA transfer size using two groups
  spi: sh-msiof: Simplify BRG's Division Ratio
  spi: sh-msiof: Increase TX FIFO size for R-Car V4H/V4M
  spi: sh-msiof: Correct RX FIFO size for R-Car Gen3
  spi: sh-msiof: Correct RX FIFO size for R-Car Gen2
  spi: sh-msiof: Add core support for dual-group transfers
  spi: sh-msiof: Correct SIMDR2_GRPMASK
  spi: sh-msiof: SIFCTR bitfield conversion
  ...

Some places in the spi core pass in a const pointer to a device and the
default container_of() casts that away, which is not a good idea.
Preserve the proper const attribute by using container_of_const() for
to_spi_device() instead, which is what it was designed for.

Note, this removes the NULL check for a device pointer in the call, but
no one was ever checking for that return value, and a device pointer
should never be NULL overall anyway, so this should be a safe change.

Cc: Mark Brown <broonie@kernel.org>
Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2025052230-fidgeting-stooge-66f5@gregkh
Signed-off-by: Mark Brown <broonie@kernel.org>

Move the MSIOF register and register bit definitions from the MSIOF SPI
driver to the existing header file <linux/spi/sh_msiof.h>, so they can
be shared with the MSIOF I2S driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/066d1086973eb309006258484e9fe8138807e565.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>

Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

Recently in the discussion with David the idea of having
a common helper popped up. The helper converts the given
bits per word to bytes. The result will always be power-of-two
(e.g. for 37 bits it returns 8 bytes) or 0 for 0 input.
More details are in the respective code comment.

This mini-series introduces it and replaces current users
under drivers/spi and we expect more (and possibly some
lurking in other subsystems).

This helper converts the given bits per word to bytes. The result
will always be power-of-two, e.g.,

    ===============    =================
    Input (in bits)    Output (in bytes)
    ===============    =================
            5                   1
            9                   2
            21                  4
            37                  8
    ===============    =================

It will return 0 for the 0 input.

There are a couple of cases in SPI that are using the same approach
and at least one more (in IIO) would benefit of it. Add a helper
for everyone.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250417152529.490582-2-andriy.shevchenko@linux.intel.com
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Introduce support for protocol drivers to specify whether a transfer
should use single or dual transfer mode. Currently, the SPI controller
cannot determine this information from the user, leading to potential
limitations in transfer capabilities.

Add a new field `dtr_mode` in the `spi_transfer` structure. The `dtr_mode`
field allows protocol drivers to indicate if Double Transfer Rate (DTR)
mode is supported for a given transfer. When `dtr_mode` is set to true,
the SPI controller will use DTR mode; otherwise, it will default to single
transfer mode.

Introduce another field `dtr_caps` to indicate if the QSPI controller is
capable of supporting DTR mode (SDR and DDR). By default, both `dtr_caps`
and `dtr_mode` will be false. These flags manage the QSPI controller's DTR
mode capabilities within the SPI framework.

The QSPI controller driver uses these flags to configure single or double
transfer rates using the controller register.

The existing spi-mem driver helps configure the DTR mode but is limited to
memory devices. There is no support available to set DTR mode for non-memory
devices, e.g., touch or any generic SPI sensor. This change is backward
compatible and doesn't break existing SPI or QSPI drivers.

Changes include:
- Addition of `dtr_mode` and `dtr_caps` fields in the `spi_transfer`
  structure.
- Documentation updates to reflect the new `dtr_mode` and `dtr_caps` fields.

Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Link: https://patch.msgid.link/20250404135427.313825-1-quic_msavaliy@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>

The CS related fields are sparse in the struct spi_device. Group them.
While at it, fix the comment style of cs_index_mask.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250331103609.4160281-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>