It seems all of the SPI drivers want to propagate fwnode (or of_node)
of the physical device to the SPI device. Make sure we don't duplicate
it over and over in each new driver (+2 in this cycle) by making core
to take care of that. Note, similar is done already by IIO and
I²C subsystems.

There is one noticeable and quite specific case that is taken care in
the first patch and now we have a confirmation from Cirrus that everything
is okay.  The rest is just a mechanical conversion after checking that
the parent device is assigned to the same that provides the respective
fwnode.

Changelog v2:
- collected tags
- fixed W=1 warning (unused variable) in spi-dln2.c (LKP)

v1: 20260108203004.3538449-1-andriy.shevchenko@linux.intel.com

Andy Shevchenko (4):
  spi: Propagate default fwnode to the SPI controller device
  spi: Drop duplicate of_node assignment
  spi: Drop duplicate fwnode assignment
  spi: Drop duplicate device_set_node() call

 drivers/spi/atmel-quadspi.c          | 1 -
 drivers/spi/spi-airoha-snfi.c        | 1 -
 drivers/spi/spi-altera-platform.c    | 2 --
 drivers/spi/spi-amlogic-spifc-a1.c   | 1 -
 drivers/spi/spi-amlogic-spisg.c      | 1 -
 drivers/spi/spi-apple.c              | 1 -
 drivers/spi/spi-ar934x.c             | 1 -
 drivers/spi/spi-armada-3700.c        | 4 +---
 drivers/spi/spi-aspeed-smc.c         | 1 -
 drivers/spi/spi-atcspi200.c          | 1 -
 drivers/spi/spi-ath79.c              | 1 -
 drivers/spi/spi-atmel.c              | 1 -
 drivers/spi/spi-axi-spi-engine.c     | 1 -
 drivers/spi/spi-bcm-qspi.c           | 1 -
 drivers/spi/spi-bcm2835.c            | 1 -
 drivers/spi/spi-bcm2835aux.c         | 1 -
 drivers/spi/spi-bcm63xx-hsspi.c      | 1 -
 drivers/spi/spi-bcm63xx.c            | 1 -
 drivers/spi/spi-bcmbca-hsspi.c       | 1 -
 drivers/spi/spi-cadence-quadspi.c    | 1 -
 drivers/spi/spi-cadence-xspi.c       | 1 -
 drivers/spi/spi-cadence.c            | 1 -
 drivers/spi/spi-cavium-octeon.c      | 1 -
 drivers/spi/spi-cavium-thunderx.c    | 1 -
 drivers/spi/spi-clps711x.c           | 1 -
 drivers/spi/spi-cs42l43.c            | 8 ++++++++
 drivers/spi/spi-davinci.c            | 1 -
 drivers/spi/spi-dln2.c               | 3 ---
 drivers/spi/spi-dw-core.c            | 2 --
 drivers/spi/spi-ep93xx.c             | 1 -
 drivers/spi/spi-falcon.c             | 1 -
 drivers/spi/spi-fsl-dspi.c           | 1 -
 drivers/spi/spi-fsl-espi.c           | 1 -
 drivers/spi/spi-fsl-lib.c            | 1 -
 drivers/spi/spi-fsl-lpspi.c          | 1 -
 drivers/spi/spi-geni-qcom.c          | 1 -
 drivers/spi/spi-gpio.c               | 1 -
 drivers/spi/spi-gxp.c                | 1 -
 drivers/spi/spi-hisi-kunpeng.c       | 1 -
 drivers/spi/spi-img-spfi.c           | 1 -
 drivers/spi/spi-imx.c                | 1 -
 drivers/spi/spi-ingenic.c            | 1 -
 drivers/spi/spi-lantiq-ssc.c         | 1 -
 drivers/spi/spi-ljca.c               | 1 -
 drivers/spi/spi-loongson-core.c      | 1 -
 drivers/spi/spi-lp8841-rtc.c         | 1 -
 drivers/spi/spi-meson-spicc.c        | 1 -
 drivers/spi/spi-meson-spifc.c        | 1 -
 drivers/spi/spi-microchip-core-spi.c | 1 -
 drivers/spi/spi-mpc512x-psc.c        | 2 --
 drivers/spi/spi-mpc52xx-psc.c        | 2 --
 drivers/spi/spi-mpc52xx.c            | 1 -
 drivers/spi/spi-mpfs.c               | 1 -
 drivers/spi/spi-mt65xx.c             | 1 -
 drivers/spi/spi-mt7621.c             | 1 -
 drivers/spi/spi-mtk-nor.c            | 1 -
 drivers/spi/spi-mtk-snfi.c           | 1 -
 drivers/spi/spi-mux.c                | 1 -
 drivers/spi/spi-mxic.c               | 1 -
 drivers/spi/spi-npcm-fiu.c           | 1 -
 drivers/spi/spi-npcm-pspi.c          | 1 -
 drivers/spi/spi-nxp-fspi.c           | 2 --
 drivers/spi/spi-nxp-xspi.c           | 1 -
 drivers/spi/spi-oc-tiny.c            | 1 -
 drivers/spi/spi-orion.c              | 1 -
 drivers/spi/spi-pl022.c              | 1 -
 drivers/spi/spi-pxa2xx.c             | 2 --
 drivers/spi/spi-qcom-qspi.c          | 1 -
 drivers/spi/spi-qpic-snand.c         | 1 -
 drivers/spi/spi-qup.c                | 1 -
 drivers/spi/spi-rb4xx.c              | 1 -
 drivers/spi/spi-realtek-rtl-snand.c  | 1 -
 drivers/spi/spi-realtek-rtl.c        | 1 -
 drivers/spi/spi-rockchip-sfc.c       | 1 -
 drivers/spi/spi-rockchip.c           | 1 -
 drivers/spi/spi-rspi.c               | 1 -
 drivers/spi/spi-rzv2h-rspi.c         | 2 --
 drivers/spi/spi-rzv2m-csi.c          | 2 --
 drivers/spi/spi-s3c64xx.c            | 1 -
 drivers/spi/spi-sc18is602.c          | 2 --
 drivers/spi/spi-sg2044-nor.c         | 1 -
 drivers/spi/spi-sh-hspi.c            | 1 -
 drivers/spi/spi-sh-msiof.c           | 1 -
 drivers/spi/spi-sifive.c             | 1 -
 drivers/spi/spi-slave-mt27xx.c       | 1 -
 drivers/spi/spi-sn-f-ospi.c          | 1 -
 drivers/spi/spi-sprd-adi.c           | 1 -
 drivers/spi/spi-sprd.c               | 1 -
 drivers/spi/spi-stm32-ospi.c         | 1 -
 drivers/spi/spi-stm32-qspi.c         | 1 -
 drivers/spi/spi-stm32.c              | 1 -
 drivers/spi/spi-sun4i.c              | 1 -
 drivers/spi/spi-sun6i.c              | 1 -
 drivers/spi/spi-sunplus-sp7021.c     | 1 -
 drivers/spi/spi-synquacer.c          | 3 ---
 drivers/spi/spi-tegra114.c           | 1 -
 drivers/spi/spi-tegra20-sflash.c     | 1 -
 drivers/spi/spi-tegra20-slink.c      | 1 -
 drivers/spi/spi-tegra210-quad.c      | 1 -
 drivers/spi/spi-ti-qspi.c            | 1 -
 drivers/spi/spi-uniphier.c           | 1 -
 drivers/spi/spi-virtio.c             | 2 --
 drivers/spi/spi-wpcm-fiu.c           | 1 -
 drivers/spi/spi-xcomm.c              | 1 -
 drivers/spi/spi-xilinx.c             | 1 -
 drivers/spi/spi-xlp.c                | 1 -
 drivers/spi/spi-xtensa-xtfpga.c      | 1 -
 drivers/spi/spi.c                    | 3 +++
 108 files changed, 12 insertions(+), 122 deletions(-)

-- 
2.50.1

On Mon, 12 Jan 2026 21:21:22 +0100, Andy Shevchenko wrote:
> It seems all of the SPI drivers want to propagate fwnode (or of_node)
> of the physical device to the SPI device. Make sure we don't duplicate
> it over and over in each new driver (+2 in this cycle) by making core
> to take care of that. Note, similar is done already by IIO and
> I²C subsystems.
> 
> There is one noticeable and quite specific case that is taken care in
> the first patch and now we have a confirmation from Cirrus that everything
> is okay.  The rest is just a mechanical conversion after checking that
> the parent device is assigned to the same that provides the respective
> fwnode.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/4] spi: Propagate default fwnode to the SPI controller device
      commit: f2d1a3318eb1ec860999db48cb8d13b43261624d
[2/4] spi: Drop duplicate of_node assignment
      commit: 3974a585be78a1dc90a19d5cf1846a99954e3842
[3/4] spi: Drop duplicate fwnode assignment
      commit: 103c510e1c6832720059756d155dd13a42baa7ab
[4/4] spi: Drop duplicate device_set_node() call
      commit: 37fbc1ab0f225d23f0839260a11375b4f1f7cf8c

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

On Mon, Jan 12, 2026 at 9:35 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> It seems all of the SPI drivers want to propagate fwnode (or of_node)
> of the physical device to the SPI device. Make sure we don't duplicate
> it over and over in each new driver (+2 in this cycle) by making core
> to take care of that. Note, similar is done already by IIO and
> I²C subsystems.
>
> There is one noticeable and quite specific case that is taken care in
> the first patch and now we have a confirmation from Cirrus that everything
> is okay.  The rest is just a mechanical conversion after checking that
> the parent device is assigned to the same that provides the respective
> fwnode.

This is clearly making the kernel a better place.

The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij