[PATCH 0/3] mtd: spi-nor: Add VIA/WonderMedia serial flash controller driver

[PATCH 0/3] mtd: spi-nor: Add VIA/WonderMedia serial flash controller driver

[Alexey Charkov]

Add a driver for the self-contained SPI NOR flash controller found on
VIA/WonderMedia SoCs, along with the respective DT binding and DTS.

The driver is a clean reimplementation based on the Linux SPI NOR
framework, although only chip probing routines are SPI NOR specific.
The rest of the controller operation is abstracted away behind a small
set of MMIO registers and a physical memory mapping for chip contents.
In fact, the vendor's implementation open-coded all driver operations
on top of the MTD framework directly, but had to rely on a static table
of supported flash chips indexed by ID due to the lack of auto-probing.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Alexey Charkov (3):
      dt-bindings: spi: Add VIA/WonderMedia serial flash controller
      mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller
      ARM: dts: vt8500: Add serial flash controller and its clock

 .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++
 MAINTAINERS                                        |   2 +
 arch/arm/boot/dts/vt8500/vt8500-bv07.dts           |  37 ++
 arch/arm/boot/dts/vt8500/vt8500.dtsi               |  34 ++
 arch/arm/boot/dts/vt8500/wm8505-ref.dts            |  37 ++
 arch/arm/boot/dts/vt8500/wm8505.dtsi               |  21 +
 arch/arm/boot/dts/vt8500/wm8650-mid.dts            |  37 ++
 arch/arm/boot/dts/vt8500/wm8650.dtsi               |  21 +
 arch/arm/boot/dts/vt8500/wm8750-apc8750.dts        |  37 ++
 arch/arm/boot/dts/vt8500/wm8750.dtsi               |  21 +
 arch/arm/boot/dts/vt8500/wm8850-w70v2.dts          |  37 ++
 arch/arm/boot/dts/vt8500/wm8850.dtsi               |  21 +
 arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts       |  37 ++
 drivers/mtd/spi-nor/controllers/Kconfig            |  14 +
 drivers/mtd/spi-nor/controllers/Makefile           |   1 +
 drivers/mtd/spi-nor/controllers/wmt-sflash.c       | 525 +++++++++++++++++++++
 16 files changed, 1004 insertions(+)
---
base-commit: ed61cb3d78d585209ec775933078e268544fe9a4
change-id: 20250510-wmt-sflash-b0ba35f1a3ae

Best regards,
-- 
Alexey Charkov <alchark@gmail.com>

[PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Alexey Charkov]

Add a binding for the serial flash controller found on VIA/WonderMedia
SoCs, which provides semi-transparent access to SPI NOR chips by
mapping their contents to the physical CPU address space.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++
 MAINTAINERS                                        |   1 +
 2 files changed, 123 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/WonderMedia serial flash controller
+
+description:
+  This controller is used on VIA/WonderMedia SoCs such as VIA VT8500,
+  WonderMedia WM8850 and similar. It provides a semi-transparent interface
+  for reading and writing SPI NOR chip contents via a physical memory map,
+  abstracting away all SPI communication, while also providing a direct
+  mechanism for issuing "programmable commands" to the underlying SPI chip
+
+maintainers:
+  - Alexey Charkov <alchark@gmail.com>
+
+properties:
+  compatible:
+    enum:
+      - via,vt8500-sflash
+      - wm,wm8505-sflash
+      - wm,wm8650-sflash
+      - wm,wm8750-sflash
+      - wm,wm8850-sflash
+
+  reg:
+    items:
+      - description: MMIO registers region of the controller
+      - description:
+          Physical memory region within which the controller will map the
+          flash contents of chip 0 for reading and writing. If the flash
+          size is smaller than this region, it will be mapped at its end.
+          Note that if this chip is used as the boot device (as is most
+          often the case), the boot ROM maps it at the very end of the
+          CPU address space (i.e. ending at 0xffffffff)
+      - description:
+          Physical memory region within which the controller will map the
+          flash contents of chip 1 for reading and writing. If the flash
+          size is smaller than this region, it will be mapped at its end
+
+  reg-names:
+    items:
+      - const: io
+      - const: chip0-mmap
+      - const: chip1-mmap
+
+  clocks:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^flash@[0-1]$":
+    type: object
+    additionalProperties: true
+
+    properties:
+      reg:
+        minimum: 0
+        maximum: 1
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    sflash: spi-nor-controller@d8002000 {
+        compatible = "wm,wm8850-sflash";
+        reg = <0xd8002000 0x400>,
+              <0xff800000 0x800000>,
+              <0xef800000 0x800000>;
+        reg-names = "io", "chip0-mmap", "chip1-mmap";
+        clocks = <&clksf>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        flash@0 {
+            compatible = "jedec,spi-nor";
+            reg = <0>;
+
+            partitions {
+                compatible = "fixed-partitions";
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+                partition@0 {
+                    label = "U-boot";
+                    reg = <0 0x50000>;
+                    read-only;
+                };
+
+                partition@1 {
+                    label = "U-boot environment 1";
+                    reg = <0x50000 0x10000>;
+                };
+
+                partition@2 {
+                    label = "U-boot environment 2";
+                    reg = <0x60000 0x10000>;
+                };
+
+                partition@3 {
+                    label = "W-load";
+                    reg = <0x70000 0x10000>;
+                    read-only;
+                };
+            };
+        };
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 6dbdf02d6b0c9357ad1da520a0f6c16b7f38f879..f09c457bbfc5ef71a3f8379c111bac52b767cbbc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3475,6 +3475,7 @@ F:	Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml
 F:	Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml
 F:	Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml
 F:	Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml
+F:	Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
 F:	arch/arm/boot/dts/vt8500/
 F:	arch/arm/mach-vt8500/
 F:	drivers/clocksource/timer-vt8500.c

-- 
2.49.0

[PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[Alexey Charkov]

The controller is tailored to SPI NOR flash memory and abstracts away all
SPI communications behind a small set of MMIO registers and a physical
memory mapping of the actual chip contents.

It doesn't expose chip probing functions beyond reading the ID though, so
use lower level chip opcodes via the "programmable command mode" of the
controller and the kernel's SPI NOR framework to avoid hard-coding chip
parameters for each ID the way the vendor kernel does it.

Currently tested on a WonderMedia WM8950 SoC with a Macronix MX25L4005A
flash chip (APC Rock board), but should work on all VIA/WonderMedia SoCs

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 MAINTAINERS                                  |   1 +
 drivers/mtd/spi-nor/controllers/Kconfig      |  14 +
 drivers/mtd/spi-nor/controllers/Makefile     |   1 +
 drivers/mtd/spi-nor/controllers/wmt-sflash.c | 525 +++++++++++++++++++++++++++
 4 files changed, 541 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f09c457bbfc5ef71a3f8379c111bac52b767cbbc..ff849c03a3b79a0487d3ab7e704ed11ffdb58f41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3481,6 +3481,7 @@ F:	arch/arm/mach-vt8500/
 F:	drivers/clocksource/timer-vt8500.c
 F:	drivers/i2c/busses/i2c-viai2c-wmt.c
 F:	drivers/mmc/host/wmt-sdmmc.c
+F:	drivers/mtd/spi-nor/controllers/wmt-sflash.c
 F:	drivers/pwm/pwm-vt8500.c
 F:	drivers/rtc/rtc-vt8500.c
 F:	drivers/soc/vt8500/
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index ca45dcd3ffe81f87dbf9ddc2a1535244ea92be20..aa8400b9aeaaec3b8b3f8996d501f5ac77a488ea 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -16,3 +16,17 @@ config SPI_NXP_SPIFI
 	  SPIFI is a specialized controller for connecting serial SPI
 	  Flash. Enable this option if you have a device with a SPIFI
 	  controller and want to access the Flash as a mtd device.
+
+config SPI_WMT_SFLASH
+	tristate "VIA/WonderMedia serial flash controller"
+	depends on ARCH_VT8500 || COMPILE_TEST
+	depends on OF
+	depends on HAS_IOMEM
+	help
+	  Enable support for the VIA/WonderMedia serial flash controller.
+
+	  This is the specialized controller driving SPI NOR flash chips
+	  inside VIA/WonderMedia SoCs. Most if not all VIA/WonderMedia
+	  based devices use SPI NOR flash as their boot storage, so select
+	  this if you need to access the primary or secondary bootloader
+	  and their environment partitions.
diff --git a/drivers/mtd/spi-nor/controllers/Makefile b/drivers/mtd/spi-nor/controllers/Makefile
index 0b8e1d5309138619bbfdf3e27639b6be2935e65e..9c0365354a37986755f3c067ba2f1f5708fd20ad 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_SPI_HISI_SFC)	+= hisi-sfc.o
 obj-$(CONFIG_SPI_NXP_SPIFI)	+= nxp-spifi.o
+obj-$(CONFIG_SPI_WMT_SFLASH)	+= wmt-sflash.o
diff --git a/drivers/mtd/spi-nor/controllers/wmt-sflash.c b/drivers/mtd/spi-nor/controllers/wmt-sflash.c
new file mode 100644
index 0000000000000000000000000000000000000000..d63c3402345a9dac7e8a0591bb032481ad3b02f7
--- /dev/null
+++ b/drivers/mtd/spi-nor/controllers/wmt-sflash.c
@@ -0,0 +1,525 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIA/WonderMedia SPI NOR flash controller driver
+ *
+ * Copyright (c) 2025 Alexey Charkov <alchark@gmail.com>
+ */
+#include <linux/clk.h>
+#include <linux/bitops.h>
+#include <linux/errno.h>
+#include <linux/iopoll.h>
+#include <linux/log2.h>
+#include <linux/minmax.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/spi-nor.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define SF_CHIP_SEL_0_CFG	0x000		/* chip select 0 config */
+#define SF_CHIP_SEL_1_CFG	0x008		/* chip select 0 config */
+#define SF_CHIP_SEL_CFG(x)	(8 * (x))
+#define SF_CHIP_SEL_ADDR	GENMASK(31, 16) /* 64kb aligned address */
+#define SF_CHIP_SEL_SIZE	GENMASK(11, 8)	/* log2(size/32kb) */
+
+#define SF_SPI_INTF_CFG		0x040	/* SPI interface config */
+#define SF_ADDR_WIDTH_32	BIT(0)	/* 0: 24 bit, 1: 32 bit addr */
+#define SF_USR_RD_CMD_MOD	BIT(4)	/* 0: normal, 1: user cmd read */
+#define SF_USR_WR_CMD_MOD	BIT(5)	/* 0: normal, 1: user cmd write */
+#define SF_PROG_CMD_MOD		BIT(6)	/* 0: normal, 1: prog cmd */
+#define SF_CS_DELAY		GENMASK(18, 16)	/* chip select delay */
+#define SF_RES_DELAY		GENMASK(27, 24) /* reset delay */
+#define SF_PDWN_DELAY		GENMASK(31, 28) /* power down delay */
+
+#define SF_SPI_RD_WR_CTR	0x050	/* read/write control */
+#define SF_RD_FAST		BIT(0)	/* 0: normal read, 1: fast read */
+#define SF_RD_ID		BIT(4)	/* 0: read status, 1: read ID */
+
+#define SF_SPI_WR_EN_CTR	0x060	/* write enable control */
+#define SF_CS0_WR_EN		BIT(0)
+#define SF_CS1_WR_EN		BIT(1)
+#define SF_CS_WR_EN(x)		BIT(x)
+
+#define SF_SPI_ER_CTR		0x070	/* erase control */
+#define SF_CHIP_ERASE		BIT(0)	/* full chip erase */
+#define SF_SEC_ERASE		BIT(15)	/* sector erase */
+
+#define SF_SPI_ER_START_ADDR	0x074	/* erase start address */
+#define SF_CHIP_ER_CS0		BIT(0)	/* erase chip 0 */
+#define SF_CHIP_ER_CS1		BIT(1)	/* erase chip 1 */
+#define SF_CHIP_ER_CS(x)	BIT(x)
+#define SF_ER_START_ADDR	GENMASK(31, 16)
+
+#define SF_SPI_ERROR_STATUS	0x080
+#define SF_MASLOCK_ERR		BIT(0)	/* master lock */
+#define SF_PCMD_ACC_ERR		BIT(1)	/* programmable cmd access */
+#define SF_PCMD_OP_ERR		BIT(2)	/* programmable cmd opcode */
+#define SF_PWR_DWN_ACC_ERR	BIT(3)	/* power down access */
+#define SF_MEM_REGION_ERR	BIT(4)	/* memory region */
+#define SF_WR_PROT_ERR		BIT(5)	/* write protection */
+#define SF_SPI_ERROR_CLEARALL	(SF_MASLOCK_ERR | \
+				 SF_PCMD_ACC_ERR | \
+				 SF_PCMD_OP_ERR | \
+				 SF_PWR_DWN_ACC_ERR | \
+				 SF_MEM_REGION_ERR | \
+				 SF_WR_PROT_ERR)
+
+#define SF_SPI_MEM_0_SR_ACC	0x100	/* status read from chip 0 */
+#define SF_SPI_MEM_1_SR_ACC	0x110	/* status read from chip 1 */
+#define SF_SPI_MEM_SR_ACC(x)	(0x100 + 0x10 * (x))
+
+#define SF_SPI_PDWN_CTR_0	0x180	/* power down chip 0 */
+#define SF_SPI_PDWN_CTR_1	0x190	/* power down chip 1 */
+#define SF_SPI_PDWN_CTR_(x)	(0x180 + 0x10 * (x))
+#define SF_PWR_DOWN		BIT(0)
+
+#define SF_SPI_PROG_CMD_CTR	0x200	/* programmable cmd control */
+#define SF_PROG_CMD_EN		BIT(0)	/* enable programmable cmd */
+#define SF_PROG_CMD_CS		GENMASK(1, 1)	/* chip select for cmd */
+#define SF_RX_DATA_SIZE		GENMASK(22, 16)	/* receive data size */
+#define SF_TX_DATA_SIZE		GENMASK(30, 24)	/* transmit data size */
+
+#define SF_SPI_USER_CMD_VAL	0x210
+#define SF_USR_RD_CMD		GENMASK(7, 0)	/* user read command */
+#define SF_USR_WR_CMD		GENMASK(23, 16)	/* user write command */
+
+#define SF_SPI_PROG_CMD_WBF	0x300	/* 64 bytes pcmd write buffer */
+#define SF_SPI_PROG_CMD_RBF	0x380	/* 64 bytes pcmd read buffer */
+
+#define SF_WAIT_TIMEOUT		1000000
+
+struct wmt_sflash_priv {
+	size_t			cs;
+	struct wmt_sflash_host	*host;
+	void __iomem		*mmap_base;
+	resource_size_t		mmap_phys;
+};
+
+#define SF_MAX_CHIP_NUM		2
+struct wmt_sflash_host {
+	struct device		*dev;
+	struct clk		*clk;
+
+	void __iomem		*regbase;
+	struct resource		*mmap_res[SF_MAX_CHIP_NUM];
+
+	struct spi_nor		*nor[SF_MAX_CHIP_NUM];
+	size_t			num_chips;
+};
+
+static int wmt_sflash_prep(struct spi_nor *nor)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+
+	return clk_prepare_enable(host->clk);
+}
+
+static void wmt_sflash_unprep(struct spi_nor *nor)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+
+	clk_disable_unprepare(host->clk);
+}
+
+static void wmt_sflash_pcmd_mode(struct wmt_sflash_host *host, bool enable)
+{
+	u32 reg = readl(host->regbase + SF_SPI_INTF_CFG);
+
+	reg &= ~SF_PROG_CMD_MOD;
+	reg |= FIELD_PREP(SF_PROG_CMD_MOD, enable);
+	writel(reg, host->regbase + SF_SPI_INTF_CFG);
+}
+
+static inline int wmt_sflash_wait_pcmd(struct wmt_sflash_host *host)
+{
+	u32 reg;
+
+	return readl_poll_timeout(host->regbase + SF_SPI_PROG_CMD_CTR, reg,
+		!(reg & SF_PROG_CMD_EN), 1, SF_WAIT_TIMEOUT);
+}
+
+static int wmt_sflash_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
+			       size_t len)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+	int ret;
+	u32 reg;
+
+	if (len > 64) {
+		dev_err(host->dev,
+		"Cannot read %d bytes from registers\n", len);
+		return -EINVAL;
+	}
+
+	wmt_sflash_pcmd_mode(host, true);
+	writeb(opcode, host->regbase + SF_SPI_PROG_CMD_WBF);
+
+	reg = SF_PROG_CMD_EN |
+	      FIELD_PREP(SF_PROG_CMD_CS, priv->cs) |
+	      FIELD_PREP(SF_TX_DATA_SIZE, 1) |
+	      FIELD_PREP(SF_RX_DATA_SIZE, len);
+	writel(reg, host->regbase + SF_SPI_PROG_CMD_CTR);
+
+	ret = wmt_sflash_wait_pcmd(host);
+
+	if (len)
+		memcpy_fromio(buf, host->regbase + SF_SPI_PROG_CMD_RBF, len);
+
+	wmt_sflash_pcmd_mode(host, false);
+
+	return ret;
+}
+
+static int wmt_sflash_write_reg(struct spi_nor *nor, u8 opcode, const u8 *buf,
+				size_t len)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+	int ret;
+	u32 reg;
+
+	if (len > 63) {
+		dev_err(host->dev,
+		"Cannot write %d bytes to registers\n", len);
+		return -EINVAL;
+	}
+
+	wmt_sflash_pcmd_mode(host, true);
+	writeb(opcode, host->regbase + SF_SPI_PROG_CMD_WBF);
+
+	if (len)
+		memcpy_toio(host->regbase + SF_SPI_PROG_CMD_WBF + 1, buf, len);
+
+	reg = SF_PROG_CMD_EN |
+	      FIELD_PREP(SF_PROG_CMD_CS, priv->cs) |
+	      FIELD_PREP(SF_TX_DATA_SIZE, len + 1);
+	writel(reg, host->regbase + SF_SPI_PROG_CMD_CTR);
+
+	ret = wmt_sflash_wait_pcmd(host);
+	wmt_sflash_pcmd_mode(host, false);
+
+	return ret;
+}
+
+static int wmt_sflash_wait_spi(struct wmt_sflash_priv *priv)
+{
+	struct wmt_sflash_host *host = priv->host;
+	int timeout = SF_WAIT_TIMEOUT;
+	u32 error;
+
+	while (timeout--) {
+		if (!(readl(host->regbase +
+			    SF_SPI_MEM_SR_ACC(priv->cs)) & 1))
+			return 0;
+
+		error = readl(host->regbase + SF_SPI_ERROR_STATUS);
+		if (error & SF_MASLOCK_ERR) {
+			dev_err(host->dev,
+				"Master lock error\n");
+			goto err;
+		}
+		if (error & SF_PCMD_ACC_ERR) {
+			dev_err(host->dev,
+				"Programmable command access error\n");
+			goto err;
+		}
+		if (error & SF_PCMD_OP_ERR) {
+			dev_err(host->dev,
+				"Programmable command opcode error\n");
+			goto err;
+		}
+		if (error & SF_PWR_DWN_ACC_ERR) {
+			dev_err(host->dev,
+				"Power down access error\n");
+			goto err;
+		}
+		if (error & SF_MEM_REGION_ERR) {
+			dev_err(host->dev,
+				"Memory region error\n");
+			goto err;
+		}
+		if (error & SF_WR_PROT_ERR) {
+			dev_err(host->dev,
+				"Write protection error\n");
+			goto err;
+		}
+	}
+	return 0;
+
+err:
+	writel(SF_SPI_ERROR_CLEARALL, host->regbase + SF_SPI_ERROR_STATUS);
+	return -EBUSY;
+}
+
+static ssize_t wmt_sflash_read(struct spi_nor *nor, loff_t from, size_t len,
+			       u_char *read_buf)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+	u32 reg = nor->read_opcode == SPINOR_OP_READ_FAST ? SF_RD_FAST : 0;
+
+	writel(reg, host->regbase + SF_SPI_RD_WR_CTR);
+
+	if (wmt_sflash_wait_spi(priv))
+		return 0;
+
+	memcpy_fromio(read_buf, priv->mmap_base + from, len);
+	return len;
+}
+
+static ssize_t wmt_sflash_write(struct spi_nor *nor, loff_t to, size_t len,
+				const u_char *write_buf)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+	size_t burst, offset = 0;
+
+	writel(SF_CS_WR_EN(priv->cs),
+	       host->regbase + SF_SPI_WR_EN_CTR);
+
+	while (offset < len) {
+		/* select 8 / 4 / 2 / 1 byte write length */
+		burst = 1 << min(3, ilog2(len - offset));
+		memcpy_toio(priv->mmap_base + to + offset,
+			    write_buf + offset, burst);
+
+		if (wmt_sflash_wait_spi(priv))
+			return offset;
+
+		offset += burst;
+	}
+
+	writel(0, host->regbase + SF_SPI_WR_EN_CTR);
+
+	return offset;
+}
+
+static int wmt_sflash_erase(struct spi_nor *nor, loff_t offs)
+{
+	struct wmt_sflash_priv *priv = nor->priv;
+	struct wmt_sflash_host *host = priv->host;
+	int ret = 0;
+	u32 reg;
+
+	if (offs & (SZ_64K - 1)) {
+		dev_err(host->dev,
+			"Erase offset 0x%llx not on 64k boundary\n", offs);
+		return -EINVAL;
+	}
+
+	writel(SF_CS_WR_EN(priv->cs),
+	       host->regbase + SF_SPI_WR_EN_CTR);
+
+	reg = SF_CHIP_ER_CS(priv->cs) |
+	      FIELD_PREP(SF_ER_START_ADDR, (priv->mmap_phys + offs) >> 16);
+	writel(reg, host->regbase + SF_SPI_ER_START_ADDR);
+
+	writel(SF_SEC_ERASE, host->regbase + SF_SPI_ER_CTR);
+
+	ret = wmt_sflash_wait_spi(priv);
+	writel(0, host->regbase + SF_SPI_WR_EN_CTR);
+
+	return ret;
+}
+
+static const struct spi_nor_controller_ops wmt_sflash_controller_ops = {
+	.prepare	= wmt_sflash_prep,
+	.unprepare	= wmt_sflash_unprep,
+	.read_reg	= wmt_sflash_read_reg,
+	.write_reg	= wmt_sflash_write_reg,
+	.read		= wmt_sflash_read,
+	.write		= wmt_sflash_write,
+	.erase		= wmt_sflash_erase,
+};
+
+static int wmt_sflash_register(struct device_node *np,
+				   struct wmt_sflash_host *host)
+{
+	const struct spi_nor_hwcaps hwcaps = {
+		.mask = SNOR_HWCAPS_READ |
+			SNOR_HWCAPS_READ_FAST |
+			SNOR_HWCAPS_PP,
+	};
+	struct device *dev = host->dev;
+	struct wmt_sflash_priv *priv;
+	struct mtd_info *mtd;
+	struct spi_nor *nor;
+	int ret;
+	u32 reg;
+
+	nor = devm_kzalloc(dev, sizeof(*nor), GFP_KERNEL);
+	if (!nor)
+		return -ENOMEM;
+
+	nor->dev = dev;
+	spi_nor_set_flash_node(nor, np);
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	ret = of_property_read_u32(np, "reg", &priv->cs);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "There's no reg property for %pOF\n",
+				     np);
+
+	if (priv->cs >= SF_MAX_CHIP_NUM)
+		return dev_err_probe(dev, -ENXIO,
+				     "Chip select %d is out of bounds\n",
+				     priv->cs);
+
+	priv->host = host;
+	nor->priv = priv;
+	nor->controller_ops = &wmt_sflash_controller_ops;
+
+	ret = spi_nor_scan(nor, NULL, &hwcaps);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to scan SPI NOR chip\n");
+
+	mtd = &nor->mtd;
+	mtd->name = np->name;
+
+	priv->mmap_phys = host->mmap_res[priv->cs]->end - mtd->size + 1;
+	priv->mmap_phys &= -SZ_64K;
+
+	priv->mmap_base = devm_ioremap(dev, priv->mmap_phys, mtd->size);
+	if (IS_ERR(priv->mmap_base))
+		return dev_err_probe(dev, PTR_ERR(priv->mmap_base),
+			"Failed to map chip %d at address 0x%x size 0x%llx\n",
+			priv->cs, priv->mmap_phys, mtd->size);
+
+	reg = FIELD_PREP(SF_CHIP_SEL_ADDR, priv->mmap_phys >> 16) |
+	      FIELD_PREP(SF_CHIP_SEL_SIZE, order_base_2(mtd->size) - 15);
+	writel(reg, host->regbase + SF_CHIP_SEL_CFG(priv->cs));
+
+	reg = FIELD_PREP(SF_CS_DELAY, 3);
+	writel(reg, host->regbase + SF_SPI_INTF_CFG);
+
+	/* the controller only handles 64k aligned addresses */
+	mtd->erasesize = max(mtd->erasesize, SZ_64K);
+
+	ret = mtd_device_register(mtd, NULL, 0);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to register MTD device\n");
+
+	host->nor[host->num_chips] = nor;
+	host->num_chips++;
+	return 0;
+}
+
+static void wmt_sflash_unregister_all(struct wmt_sflash_host *host)
+{
+	int i;
+
+	for (i = 0; i < host->num_chips; i++)
+		mtd_device_unregister(&host->nor[i]->mtd);
+}
+
+static int wmt_sflash_register_all(struct wmt_sflash_host *host)
+{
+	struct device *dev = host->dev;
+	struct device_node *np;
+	int ret;
+
+	for_each_available_child_of_node(dev->of_node, np) {
+		ret = wmt_sflash_register(np, host);
+		if (ret) {
+			of_node_put(np);
+			goto fail;
+		}
+
+		if (host->num_chips == SF_MAX_CHIP_NUM) {
+			dev_warn(dev, "Flash count exceeds the maximum chipselect number\n");
+			of_node_put(np);
+			break;
+		}
+	}
+	return 0;
+
+fail:
+	wmt_sflash_unregister_all(host);
+	return ret;
+}
+
+static int wmt_sflash_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct wmt_sflash_host *host;
+	char mmap_str[32];
+	int ret, i;
+
+	host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return dev_err_probe(dev, -ENOMEM,
+			"Failed to allocate controller private data\n");
+
+	platform_set_drvdata(pdev, host);
+	host->dev = dev;
+
+	host->regbase = devm_platform_ioremap_resource_byname(pdev, "io");
+	if (IS_ERR(host->regbase))
+		return dev_err_probe(dev, PTR_ERR(host->regbase),
+			"Failed to remap controller MMIO registers\n");
+
+	for (i = 0; i < SF_MAX_CHIP_NUM; i++) {
+		snprintf(mmap_str, sizeof(mmap_str), "chip%d-mmap", i);
+
+		host->mmap_res[i] = platform_get_resource_byname(pdev,
+						IORESOURCE_MEM, mmap_str);
+		if (!host->mmap_res[i])
+			return dev_err_probe(dev, -ENXIO,
+				"Memory map region not found for chip %d\n",
+				i);
+	}
+
+	host->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(host->clk))
+		return dev_err_probe(dev, PTR_ERR(host->clk),
+			"Failed to get clock\n");
+
+	ret = clk_prepare_enable(host->clk);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable clock\n");
+
+	ret = wmt_sflash_register_all(host);
+
+	clk_disable_unprepare(host->clk);
+	return ret;
+}
+
+static void wmt_sflash_remove(struct platform_device *pdev)
+{
+	struct wmt_sflash_host *host = platform_get_drvdata(pdev);
+
+	wmt_sflash_unregister_all(host);
+}
+
+static const struct of_device_id wmt_sflash_dt_ids[] = {
+	{ .compatible = "via,vt8500-sflash"},
+	{ .compatible = "wm,wm8505-sflash"},
+	{ .compatible = "wm,wm8650-sflash"},
+	{ .compatible = "wm,wm8750-sflash"},
+	{ .compatible = "wm,wm8850-sflash"},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, wmt_sflash_dt_ids);
+
+static struct platform_driver wmt_sflash_driver = {
+	.driver = {
+		.name	= "wmt-sflash",
+		.of_match_table = wmt_sflash_dt_ids,
+	},
+	.probe	= wmt_sflash_probe,
+	.remove = wmt_sflash_remove,
+};
+module_platform_driver(wmt_sflash_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VIA/WonderMedia SPI NOR flash controller driver");

-- 
2.49.0

[PATCH 3/3] ARM: dts: vt8500: Add serial flash controller and its clock

[Alexey Charkov]

The serial flash controller resides at the same MMIO address in all known
VIA/WonderMedia SoCs, and its clock uses the same enable bit and divisor
reg on all SoCs, feeding off PLL B.

Add respective DT nodes using SoC specific compatibles for the controller
to make it future proof in case any differences in behavior are discovered
later on.

All known boards boot from SPI NOR flash, so their flash chips are at CS0
and mapped by the boot ROM at the end of their CPU address space. Add
respective DT nodes in board-specific dts files too.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 arch/arm/boot/dts/vt8500/vt8500-bv07.dts     | 37 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/vt8500.dtsi         | 34 +++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8505-ref.dts      | 37 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8505.dtsi         | 21 ++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8650-mid.dts      | 37 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8650.dtsi         | 21 ++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8750-apc8750.dts  | 37 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8750.dtsi         | 21 ++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8850-w70v2.dts    | 37 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8850.dtsi         | 21 ++++++++++++++++
 arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts | 37 ++++++++++++++++++++++++++++
 11 files changed, 340 insertions(+)

diff --git a/arch/arm/boot/dts/vt8500/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500/vt8500-bv07.dts
index 38a2da5e2c5d64477f04e1da9d98cb97be0d95e4..c3c5ba3ac014cc49bee8c2b9e6c7b25225d4d5fe 100644
--- a/arch/arm/boot/dts/vt8500/vt8500-bv07.dts
+++ b/arch/arm/boot/dts/vt8500/vt8500-bv07.dts
@@ -30,6 +30,43 @@ timing0: timing-800x480 {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/vt8500/vt8500.dtsi b/arch/arm/boot/dts/vt8500/vt8500.dtsi
index 2ba021585d4889f29777a12473964c29f999f3a0..7ea115576c69b517cb2a08206638062f22c976a0 100644
--- a/arch/arm/boot/dts/vt8500/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500/vt8500.dtsi
@@ -74,6 +74,19 @@ ref24: ref24M {
 					clock-frequency = <24000000>;
 				};
 
+				ref25: clock-25000000 {
+					#clock-cells = <0>;
+					compatible = "fixed-clock";
+					clock-frequency = <25000000>;
+				};
+
+				pllb: clock@204 {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x204>;
+				};
+
 				clkuart0: uart0 {
 					#clock-cells = <0>;
 					compatible = "via,vt8500-device-clock";
@@ -105,6 +118,15 @@ clkuart3: uart3 {
 					enable-reg = <0x250>;
 					enable-bit = <4>;
 				};
+
+				clksf: clock {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
 			};
 		};
 
@@ -114,6 +136,18 @@ timer@d8130100 {
 			interrupts = <36>;
 		};
 
+		sflash: spi-nor-controller@d8002000 {
+			compatible = "via,vt8500-sflash";
+			reg = <0xd8002000 0x400>,
+			      <0xff800000 0x800000>,
+			      <0xef800000 0x800000>;
+			reg-names = "io", "chip0-mmap", "chip1-mmap";
+			clocks = <&clksf>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
 		usb@d8007900 {
 			compatible = "via,vt8500-ehci";
 			reg = <0xd8007900 0x200>;
diff --git a/arch/arm/boot/dts/vt8500/wm8505-ref.dts b/arch/arm/boot/dts/vt8500/wm8505-ref.dts
index 8ce9e2ef0a81097e7143a5392ee5b42bf8028ec1..b037f9d919fb51a527f35276e2b8601f3f3d8505 100644
--- a/arch/arm/boot/dts/vt8500/wm8505-ref.dts
+++ b/arch/arm/boot/dts/vt8500/wm8505-ref.dts
@@ -30,6 +30,43 @@ timing0: timing-800x480 {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/vt8500/wm8505.dtsi b/arch/arm/boot/dts/vt8500/wm8505.dtsi
index 99c064c916b2279797f71261ca9306e9dcd4bbd8..bf9ba4e99f86d1bf41c4e4bfe8b4f71ad162be4f 100644
--- a/arch/arm/boot/dts/vt8500/wm8505.dtsi
+++ b/arch/arm/boot/dts/vt8500/wm8505.dtsi
@@ -203,6 +203,15 @@ clksdhc: sdhc {
 					enable-reg = <0x254>;
 					enable-bit = <18>;
 				};
+
+				clksf: clock {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
 			};
 		};
 
@@ -212,6 +221,18 @@ timer@d8130100 {
 			interrupts = <36>;
 		};
 
+		sflash: spi-nor-controller@d8002000 {
+			compatible = "wm,wm8505-sflash";
+			reg = <0xd8002000 0x400>,
+			      <0xff800000 0x800000>,
+			      <0xef800000 0x800000>;
+			reg-names = "io", "chip0-mmap", "chip1-mmap";
+			clocks = <&clksf>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
 		usb@d8007100 {
 			compatible = "via,vt8500-ehci";
 			reg = <0xd8007100 0x200>;
diff --git a/arch/arm/boot/dts/vt8500/wm8650-mid.dts b/arch/arm/boot/dts/vt8500/wm8650-mid.dts
index 7977b6c1e8ebf215df210dee703e470b9159d329..d3c8b7b99706603bab5aa8dad1165edb3763c2f6 100644
--- a/arch/arm/boot/dts/vt8500/wm8650-mid.dts
+++ b/arch/arm/boot/dts/vt8500/wm8650-mid.dts
@@ -31,6 +31,43 @@ timing0: timing-800x480 {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/vt8500/wm8650.dtsi b/arch/arm/boot/dts/vt8500/wm8650.dtsi
index 0d6c7bd87f7dcce0eef056d04c38ab1de5d52639..972b61d2437b1da9ce765b65f844872e8df4da1d 100644
--- a/arch/arm/boot/dts/vt8500/wm8650.dtsi
+++ b/arch/arm/boot/dts/vt8500/wm8650.dtsi
@@ -175,6 +175,15 @@ clksdhc: sdhc {
 					enable-reg = <0x254>;
 					enable-bit = <18>;
 				};
+
+				clksf: clock {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
 			};
 		};
 
@@ -184,6 +193,18 @@ timer@d8130100 {
 			interrupts = <36>;
 		};
 
+		sflash: spi-nor-controller@d8002000 {
+			compatible = "wm,wm8650-sflash";
+			reg = <0xd8002000 0x400>,
+			      <0xff800000 0x800000>,
+			      <0xef800000 0x800000>;
+			reg-names = "io", "chip0-mmap", "chip1-mmap";
+			clocks = <&clksf>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
 		usb@d8007900 {
 			compatible = "via,vt8500-ehci";
 			reg = <0xd8007900 0x200>;
diff --git a/arch/arm/boot/dts/vt8500/wm8750-apc8750.dts b/arch/arm/boot/dts/vt8500/wm8750-apc8750.dts
index 136e812bc1e498d48c7fc61154bc66a48888b117..4465946cfe44e82db1cad14c1f81237e1ccc0e67 100644
--- a/arch/arm/boot/dts/vt8500/wm8750-apc8750.dts
+++ b/arch/arm/boot/dts/vt8500/wm8750-apc8750.dts
@@ -24,6 +24,43 @@ i2c: i2c {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/vt8500/wm8750.dtsi b/arch/arm/boot/dts/vt8500/wm8750.dtsi
index 0158c0ba5dd110957eac38775d3bf3ebd2ab4154..d6b4e4463fae1e8a0a3cf0feecce7125b4a67f5c 100644
--- a/arch/arm/boot/dts/vt8500/wm8750.dtsi
+++ b/arch/arm/boot/dts/vt8500/wm8750.dtsi
@@ -240,6 +240,15 @@ clki2c1: i2c1clk {
 					enable-reg = <0x250>;
 					enable-bit = <9>;
 				};
+
+				clksf: clock {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
 			};
 		};
 
@@ -256,6 +265,18 @@ timer@d8130100 {
 			interrupts = <36>;
 		};
 
+		sflash: spi-nor-controller@d8002000 {
+			compatible = "wm,wm8750-sflash";
+			reg = <0xd8002000 0x400>,
+			      <0xff800000 0x800000>,
+			      <0xef800000 0x800000>;
+			reg-names = "io", "chip0-mmap", "chip1-mmap";
+			clocks = <&clksf>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
 		usb@d8007900 {
 			compatible = "via,vt8500-ehci";
 			reg = <0xd8007900 0x200>;
diff --git a/arch/arm/boot/dts/vt8500/wm8850-w70v2.dts b/arch/arm/boot/dts/vt8500/wm8850-w70v2.dts
index 5d409323b10cb94a5694722de1e31cff5be390ce..d2638a204579d3dff477bb7f458438037e08019b 100644
--- a/arch/arm/boot/dts/vt8500/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/vt8500/wm8850-w70v2.dts
@@ -42,6 +42,43 @@ timing0: timing-800x480 {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/vt8500/wm8850.dtsi b/arch/arm/boot/dts/vt8500/wm8850.dtsi
index c4bfb4d30aad0358b39cbf30edf0c63e32167bbd..6837198de2508536eef52537a7f451679d36c38b 100644
--- a/arch/arm/boot/dts/vt8500/wm8850.dtsi
+++ b/arch/arm/boot/dts/vt8500/wm8850.dtsi
@@ -217,6 +217,15 @@ clksdhc: sdhc {
 					enable-reg = <0x250>;
 					enable-bit = <0>;
 				};
+
+				clksf: clock {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
 			};
 		};
 
@@ -243,6 +252,18 @@ timer@d8130100 {
 			interrupts = <36>;
 		};
 
+		sflash: spi-nor-controller@d8002000 {
+			compatible = "wm,wm8850-sflash";
+			reg = <0xd8002000 0x400>,
+			      <0xff800000 0x800000>,
+			      <0xef800000 0x800000>;
+			reg-names = "io", "chip0-mmap", "chip1-mmap";
+			clocks = <&clksf>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
 		usb@d8007900 {
 			compatible = "via,vt8500-ehci";
 			reg = <0xd8007900 0x200>;
diff --git a/arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts b/arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts
index 58b3c8deb4f20ae072bf1381f1dfa5e5adeb414a..647fdcccdbbd680276af1fa30363e09bbeb5ad16 100644
--- a/arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts
+++ b/arch/arm/boot/dts/vt8500/wm8950-apc-rock.dts
@@ -16,6 +16,43 @@ memory@0 {
 	};
 };
 
+&sflash {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "U-boot";
+				reg = <0 0x50000>;
+				read-only;
+			};
+
+			partition@1 {
+				label = "U-boot environment 1";
+				reg = <0x50000 0x10000>;
+			};
+
+			partition@2 {
+				label = "U-boot environment 2";
+				reg = <0x60000 0x10000>;
+			};
+
+			partition@3 {
+				label = "W-load";
+				reg = <0x70000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };

-- 
2.49.0

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[kernel test robot]

Hi Alexey,

kernel test robot noticed the following build errors:

[auto build test ERROR on ed61cb3d78d585209ec775933078e268544fe9a4]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexey-Charkov/dt-bindings-spi-Add-VIA-WonderMedia-serial-flash-controller/20250511-034459
base:   ed61cb3d78d585209ec775933078e268544fe9a4
patch link:    https://lore.kernel.org/r/20250510-wmt-sflash-v1-2-02a1ac6adf12%40gmail.com
patch subject: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20250511/202505111905.tlinDurh-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505111905.tlinDurh-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505111905.tlinDurh-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/mtd/spi-nor/controllers/wmt-sflash.c: In function 'wmt_sflash_pcmd_mode':
>> drivers/mtd/spi-nor/controllers/wmt-sflash.c:132:16: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration]
     132 |         reg |= FIELD_PREP(SF_PROG_CMD_MOD, enable);
         |                ^~~~~~~~~~


vim +/FIELD_PREP +132 drivers/mtd/spi-nor/controllers/wmt-sflash.c

   126	
   127	static void wmt_sflash_pcmd_mode(struct wmt_sflash_host *host, bool enable)
   128	{
   129		u32 reg = readl(host->regbase + SF_SPI_INTF_CFG);
   130	
   131		reg &= ~SF_PROG_CMD_MOD;
 > 132		reg |= FIELD_PREP(SF_PROG_CMD_MOD, enable);
   133		writel(reg, host->regbase + SF_SPI_INTF_CFG);
   134	}
   135	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[kernel test robot]

Hi Alexey,

kernel test robot noticed the following build warnings:

[auto build test WARNING on ed61cb3d78d585209ec775933078e268544fe9a4]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexey-Charkov/dt-bindings-spi-Add-VIA-WonderMedia-serial-flash-controller/20250511-034459
base:   ed61cb3d78d585209ec775933078e268544fe9a4
patch link:    https://lore.kernel.org/r/20250510-wmt-sflash-v1-2-02a1ac6adf12%40gmail.com
patch subject: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller
config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20250511/202505112028.FOL7oTti-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250511/202505112028.FOL7oTti-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505112028.FOL7oTti-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:15,
                    from include/linux/mtd/mtd.h:13,
                    from drivers/mtd/spi-nor/controllers/wmt-sflash.c:14:
   drivers/mtd/spi-nor/controllers/wmt-sflash.c: In function 'wmt_sflash_read_reg':
>> drivers/mtd/spi-nor/controllers/wmt-sflash.c:154:17: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
     154 |                 "Cannot read %d bytes from registers\n", len);
         |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
     110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
         |                              ^~~
   include/linux/dev_printk.h:154:56: note: in expansion of macro 'dev_fmt'
     154 |         dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
         |                                                        ^~~~~~~
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:153:17: note: in expansion of macro 'dev_err'
     153 |                 dev_err(host->dev,
         |                 ^~~~~~~
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:154:31: note: format string is defined here
     154 |                 "Cannot read %d bytes from registers\n", len);
         |                              ~^
         |                               |
         |                               int
         |                              %ld
   drivers/mtd/spi-nor/controllers/wmt-sflash.c: In function 'wmt_sflash_write_reg':
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:187:17: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
     187 |                 "Cannot write %d bytes to registers\n", len);
         |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
     110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
         |                              ^~~
   include/linux/dev_printk.h:154:56: note: in expansion of macro 'dev_fmt'
     154 |         dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
         |                                                        ^~~~~~~
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:186:17: note: in expansion of macro 'dev_err'
     186 |                 dev_err(host->dev,
         |                 ^~~~~~~
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:187:32: note: format string is defined here
     187 |                 "Cannot write %d bytes to registers\n", len);
         |                               ~^
         |                                |
         |                                int
         |                               %ld
   drivers/mtd/spi-nor/controllers/wmt-sflash.c: In function 'wmt_sflash_register':
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:365:47: error: passing argument 3 of 'of_property_read_u32' from incompatible pointer type [-Wincompatible-pointer-types]
     365 |         ret = of_property_read_u32(np, "reg", &priv->cs);
         |                                               ^~~~~~~~~
         |                                               |
         |                                               size_t * {aka long unsigned int *}
   In file included from include/linux/mtd/mtd.h:14:
   include/linux/of.h:1419:45: note: expected 'u32 *' {aka 'unsigned int *'} but argument is of type 'size_t *' {aka 'long unsigned int *'}
    1419 |                                        u32 *out_value)
         |                                        ~~~~~^~~~~~~~~
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:373:52: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
     373 |                                      "Chip select %d is out of bounds\n",
         |                                                   ~^
         |                                                    |
         |                                                    int
         |                                                   %ld
     374 |                                      priv->cs);
         |                                      ~~~~~~~~       
         |                                          |
         |                                          size_t {aka long unsigned int}
   drivers/mtd/spi-nor/controllers/wmt-sflash.c:394:46: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
     394 |                         "Failed to map chip %d at address 0x%x size 0x%llx\n",
         |                                             ~^
         |                                              |
         |                                              int
         |                                             %ld
     395 |                         priv->cs, priv->mmap_phys, mtd->size);
         |                         ~~~~~~~~              
         |                             |
         |                             size_t {aka long unsigned int}
>> drivers/mtd/spi-nor/controllers/wmt-sflash.c:394:62: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'resource_size_t' {aka 'long long unsigned int'} [-Wformat=]
     394 |                         "Failed to map chip %d at address 0x%x size 0x%llx\n",
         |                                                             ~^
         |                                                              |
         |                                                              unsigned int
         |                                                             %llx
     395 |                         priv->cs, priv->mmap_phys, mtd->size);
         |                                   ~~~~~~~~~~~~~~~             
         |                                       |
         |                                       resource_size_t {aka long long unsigned int}


vim +154 drivers/mtd/spi-nor/controllers/wmt-sflash.c

  > 14	#include <linux/mtd/mtd.h>
    15	#include <linux/mtd/spi-nor.h>
    16	#include <linux/of.h>
    17	#include <linux/platform_device.h>
    18	#include <linux/slab.h>
    19	
    20	#define SF_CHIP_SEL_0_CFG	0x000		/* chip select 0 config */
    21	#define SF_CHIP_SEL_1_CFG	0x008		/* chip select 0 config */
    22	#define SF_CHIP_SEL_CFG(x)	(8 * (x))
    23	#define SF_CHIP_SEL_ADDR	GENMASK(31, 16) /* 64kb aligned address */
    24	#define SF_CHIP_SEL_SIZE	GENMASK(11, 8)	/* log2(size/32kb) */
    25	
    26	#define SF_SPI_INTF_CFG		0x040	/* SPI interface config */
    27	#define SF_ADDR_WIDTH_32	BIT(0)	/* 0: 24 bit, 1: 32 bit addr */
    28	#define SF_USR_RD_CMD_MOD	BIT(4)	/* 0: normal, 1: user cmd read */
    29	#define SF_USR_WR_CMD_MOD	BIT(5)	/* 0: normal, 1: user cmd write */
    30	#define SF_PROG_CMD_MOD		BIT(6)	/* 0: normal, 1: prog cmd */
    31	#define SF_CS_DELAY		GENMASK(18, 16)	/* chip select delay */
    32	#define SF_RES_DELAY		GENMASK(27, 24) /* reset delay */
    33	#define SF_PDWN_DELAY		GENMASK(31, 28) /* power down delay */
    34	
    35	#define SF_SPI_RD_WR_CTR	0x050	/* read/write control */
    36	#define SF_RD_FAST		BIT(0)	/* 0: normal read, 1: fast read */
    37	#define SF_RD_ID		BIT(4)	/* 0: read status, 1: read ID */
    38	
    39	#define SF_SPI_WR_EN_CTR	0x060	/* write enable control */
    40	#define SF_CS0_WR_EN		BIT(0)
    41	#define SF_CS1_WR_EN		BIT(1)
    42	#define SF_CS_WR_EN(x)		BIT(x)
    43	
    44	#define SF_SPI_ER_CTR		0x070	/* erase control */
    45	#define SF_CHIP_ERASE		BIT(0)	/* full chip erase */
    46	#define SF_SEC_ERASE		BIT(15)	/* sector erase */
    47	
    48	#define SF_SPI_ER_START_ADDR	0x074	/* erase start address */
    49	#define SF_CHIP_ER_CS0		BIT(0)	/* erase chip 0 */
    50	#define SF_CHIP_ER_CS1		BIT(1)	/* erase chip 1 */
    51	#define SF_CHIP_ER_CS(x)	BIT(x)
    52	#define SF_ER_START_ADDR	GENMASK(31, 16)
    53	
    54	#define SF_SPI_ERROR_STATUS	0x080
    55	#define SF_MASLOCK_ERR		BIT(0)	/* master lock */
    56	#define SF_PCMD_ACC_ERR		BIT(1)	/* programmable cmd access */
    57	#define SF_PCMD_OP_ERR		BIT(2)	/* programmable cmd opcode */
    58	#define SF_PWR_DWN_ACC_ERR	BIT(3)	/* power down access */
    59	#define SF_MEM_REGION_ERR	BIT(4)	/* memory region */
    60	#define SF_WR_PROT_ERR		BIT(5)	/* write protection */
    61	#define SF_SPI_ERROR_CLEARALL	(SF_MASLOCK_ERR | \
    62					 SF_PCMD_ACC_ERR | \
    63					 SF_PCMD_OP_ERR | \
    64					 SF_PWR_DWN_ACC_ERR | \
    65					 SF_MEM_REGION_ERR | \
    66					 SF_WR_PROT_ERR)
    67	
    68	#define SF_SPI_MEM_0_SR_ACC	0x100	/* status read from chip 0 */
    69	#define SF_SPI_MEM_1_SR_ACC	0x110	/* status read from chip 1 */
    70	#define SF_SPI_MEM_SR_ACC(x)	(0x100 + 0x10 * (x))
    71	
    72	#define SF_SPI_PDWN_CTR_0	0x180	/* power down chip 0 */
    73	#define SF_SPI_PDWN_CTR_1	0x190	/* power down chip 1 */
    74	#define SF_SPI_PDWN_CTR_(x)	(0x180 + 0x10 * (x))
    75	#define SF_PWR_DOWN		BIT(0)
    76	
    77	#define SF_SPI_PROG_CMD_CTR	0x200	/* programmable cmd control */
    78	#define SF_PROG_CMD_EN		BIT(0)	/* enable programmable cmd */
    79	#define SF_PROG_CMD_CS		GENMASK(1, 1)	/* chip select for cmd */
    80	#define SF_RX_DATA_SIZE		GENMASK(22, 16)	/* receive data size */
    81	#define SF_TX_DATA_SIZE		GENMASK(30, 24)	/* transmit data size */
    82	
    83	#define SF_SPI_USER_CMD_VAL	0x210
    84	#define SF_USR_RD_CMD		GENMASK(7, 0)	/* user read command */
    85	#define SF_USR_WR_CMD		GENMASK(23, 16)	/* user write command */
    86	
    87	#define SF_SPI_PROG_CMD_WBF	0x300	/* 64 bytes pcmd write buffer */
    88	#define SF_SPI_PROG_CMD_RBF	0x380	/* 64 bytes pcmd read buffer */
    89	
    90	#define SF_WAIT_TIMEOUT		1000000
    91	
    92	struct wmt_sflash_priv {
    93		size_t			cs;
    94		struct wmt_sflash_host	*host;
    95		void __iomem		*mmap_base;
    96		resource_size_t		mmap_phys;
    97	};
    98	
    99	#define SF_MAX_CHIP_NUM		2
   100	struct wmt_sflash_host {
   101		struct device		*dev;
   102		struct clk		*clk;
   103	
   104		void __iomem		*regbase;
   105		struct resource		*mmap_res[SF_MAX_CHIP_NUM];
   106	
   107		struct spi_nor		*nor[SF_MAX_CHIP_NUM];
   108		size_t			num_chips;
   109	};
   110	
   111	static int wmt_sflash_prep(struct spi_nor *nor)
   112	{
   113		struct wmt_sflash_priv *priv = nor->priv;
   114		struct wmt_sflash_host *host = priv->host;
   115	
   116		return clk_prepare_enable(host->clk);
   117	}
   118	
   119	static void wmt_sflash_unprep(struct spi_nor *nor)
   120	{
   121		struct wmt_sflash_priv *priv = nor->priv;
   122		struct wmt_sflash_host *host = priv->host;
   123	
   124		clk_disable_unprepare(host->clk);
   125	}
   126	
   127	static void wmt_sflash_pcmd_mode(struct wmt_sflash_host *host, bool enable)
   128	{
   129		u32 reg = readl(host->regbase + SF_SPI_INTF_CFG);
   130	
   131		reg &= ~SF_PROG_CMD_MOD;
   132		reg |= FIELD_PREP(SF_PROG_CMD_MOD, enable);
   133		writel(reg, host->regbase + SF_SPI_INTF_CFG);
   134	}
   135	
   136	static inline int wmt_sflash_wait_pcmd(struct wmt_sflash_host *host)
   137	{
   138		u32 reg;
   139	
   140		return readl_poll_timeout(host->regbase + SF_SPI_PROG_CMD_CTR, reg,
   141			!(reg & SF_PROG_CMD_EN), 1, SF_WAIT_TIMEOUT);
   142	}
   143	
   144	static int wmt_sflash_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
   145				       size_t len)
   146	{
   147		struct wmt_sflash_priv *priv = nor->priv;
   148		struct wmt_sflash_host *host = priv->host;
   149		int ret;
   150		u32 reg;
   151	
   152		if (len > 64) {
   153			dev_err(host->dev,
 > 154			"Cannot read %d bytes from registers\n", len);
   155			return -EINVAL;
   156		}
   157	
   158		wmt_sflash_pcmd_mode(host, true);
   159		writeb(opcode, host->regbase + SF_SPI_PROG_CMD_WBF);
   160	
   161		reg = SF_PROG_CMD_EN |
   162		      FIELD_PREP(SF_PROG_CMD_CS, priv->cs) |
   163		      FIELD_PREP(SF_TX_DATA_SIZE, 1) |
   164		      FIELD_PREP(SF_RX_DATA_SIZE, len);
   165		writel(reg, host->regbase + SF_SPI_PROG_CMD_CTR);
   166	
   167		ret = wmt_sflash_wait_pcmd(host);
   168	
   169		if (len)
   170			memcpy_fromio(buf, host->regbase + SF_SPI_PROG_CMD_RBF, len);
   171	
   172		wmt_sflash_pcmd_mode(host, false);
   173	
   174		return ret;
   175	}
   176	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[Pratyush Yadav]

Hi Alexey,

On Sat, May 10 2025, Alexey Charkov wrote:

> The controller is tailored to SPI NOR flash memory and abstracts away all
> SPI communications behind a small set of MMIO registers and a physical
> memory mapping of the actual chip contents.
>
> It doesn't expose chip probing functions beyond reading the ID though, so
> use lower level chip opcodes via the "programmable command mode" of the
> controller and the kernel's SPI NOR framework to avoid hard-coding chip
> parameters for each ID the way the vendor kernel does it.
>
> Currently tested on a WonderMedia WM8950 SoC with a Macronix MX25L4005A
> flash chip (APC Rock board), but should work on all VIA/WonderMedia SoCs
>
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  MAINTAINERS                                  |   1 +
>  drivers/mtd/spi-nor/controllers/Kconfig      |  14 +
>  drivers/mtd/spi-nor/controllers/Makefile     |   1 +
>  drivers/mtd/spi-nor/controllers/wmt-sflash.c | 525 +++++++++++++++++++++++++++

Drivers in drivers/mtd/spi-nor/controllers/ are deprecated, and we want
to eventually get rid of the API. The expected way is for drivers to use
SPI MEM (drivers/spi/spi-mem.c). SPI MEM drivers are usually more
general and not tailored specifically to SPI NOR flashes, so it might be
a bit tricky to write drivers for specialized hardware with it. But I
think the drivers/spi/spi-intel.c driver is written for similar kind of
hardware so it should be possible.
>
[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[Alexey Charkov]

Hi Pratyush,

On Mon, May 12, 2025 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> Hi Alexey,
>
> On Sat, May 10 2025, Alexey Charkov wrote:
>
> > The controller is tailored to SPI NOR flash memory and abstracts away all
> > SPI communications behind a small set of MMIO registers and a physical
> > memory mapping of the actual chip contents.
> >
> > It doesn't expose chip probing functions beyond reading the ID though, so
> > use lower level chip opcodes via the "programmable command mode" of the
> > controller and the kernel's SPI NOR framework to avoid hard-coding chip
> > parameters for each ID the way the vendor kernel does it.
> >
> > Currently tested on a WonderMedia WM8950 SoC with a Macronix MX25L4005A
> > flash chip (APC Rock board), but should work on all VIA/WonderMedia SoCs
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  MAINTAINERS                                  |   1 +
> >  drivers/mtd/spi-nor/controllers/Kconfig      |  14 +
> >  drivers/mtd/spi-nor/controllers/Makefile     |   1 +
> >  drivers/mtd/spi-nor/controllers/wmt-sflash.c | 525 +++++++++++++++++++++++++++
>
> Drivers in drivers/mtd/spi-nor/controllers/ are deprecated, and we want
> to eventually get rid of the API. The expected way is for drivers to use
> SPI MEM (drivers/spi/spi-mem.c). SPI MEM drivers are usually more
> general and not tailored specifically to SPI NOR flashes, so it might be
> a bit tricky to write drivers for specialized hardware with it. But I
> think the drivers/spi/spi-intel.c driver is written for similar kind of
> hardware so it should be possible.

Oops. I've had a look at spi-mem, and it seems like it's not a
particularly fitting abstraction for this controller.

From what I understood, spi-mem primarily expects to be talking SPI
opcodes to the controller, and for the controller/driver to bring
their own chip probing routines. This controller on the other hand
abstracts the opcodes away, and wants someone to tell it what its
flash chip can do (the controller itself can only get a chip ID in
"normal" mode, and it needs to somehow know the chip size and
standard/fast read capability of the chip). So pretty much the
opposite, huh.

In the end, I only need something like spi_nor_detect() and can do the
rest directly on top of the MTD framework without touching any SPI
opcodes after the detection is done. Is there any other non-deprecated
framework that can provide something like this? Maybe physmap? It
looks even older than SPI NOR though :)

Best regards,
Alexey

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Rob Herring]

On Sat, May 10, 2025 at 11:42:21PM +0400, Alexey Charkov wrote:
> Add a binding for the serial flash controller found on VIA/WonderMedia
> SoCs, which provides semi-transparent access to SPI NOR chips by
> mapping their contents to the physical CPU address space.
> 
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++
>  MAINTAINERS                                        |   1 +
>  2 files changed, 123 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
> @@ -0,0 +1,122 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: VIA/WonderMedia serial flash controller
> +
> +description:
> +  This controller is used on VIA/WonderMedia SoCs such as VIA VT8500,
> +  WonderMedia WM8850 and similar. It provides a semi-transparent interface
> +  for reading and writing SPI NOR chip contents via a physical memory map,
> +  abstracting away all SPI communication, while also providing a direct
> +  mechanism for issuing "programmable commands" to the underlying SPI chip
> +
> +maintainers:
> +  - Alexey Charkov <alchark@gmail.com>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - via,vt8500-sflash
> +      - wm,wm8505-sflash
> +      - wm,wm8650-sflash
> +      - wm,wm8750-sflash
> +      - wm,wm8850-sflash
> +
> +  reg:
> +    items:
> +      - description: MMIO registers region of the controller
> +      - description:
> +          Physical memory region within which the controller will map the
> +          flash contents of chip 0 for reading and writing. If the flash
> +          size is smaller than this region, it will be mapped at its end.
> +          Note that if this chip is used as the boot device (as is most
> +          often the case), the boot ROM maps it at the very end of the
> +          CPU address space (i.e. ending at 0xffffffff)

Period needed on the end.

> +      - description:
> +          Physical memory region within which the controller will map the
> +          flash contents of chip 1 for reading and writing. If the flash
> +          size is smaller than this region, it will be mapped at its end

Period needed on the end.

> +
> +  reg-names:
> +    items:
> +      - const: io
> +      - const: chip0-mmap
> +      - const: chip1-mmap
> +
> +  clocks:
> +    maxItems: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0

This follows the SPI binding, right? Drop these 2 and add a $ref to 
spi-controller.yaml.

> +
> +patternProperties:
> +  "^flash@[0-1]$":
> +    type: object
> +    additionalProperties: true
> +
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    sflash: spi-nor-controller@d8002000 {

spi@...

> +        compatible = "wm,wm8850-sflash";
> +        reg = <0xd8002000 0x400>,
> +              <0xff800000 0x800000>,
> +              <0xef800000 0x800000>;
> +        reg-names = "io", "chip0-mmap", "chip1-mmap";
> +        clocks = <&clksf>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        flash@0 {
> +            compatible = "jedec,spi-nor";
> +            reg = <0>;
> +
> +            partitions {
> +                compatible = "fixed-partitions";
> +                #address-cells = <1>;
> +                #size-cells = <1>;
> +
> +                partition@0 {
> +                    label = "U-boot";

The somewhat standard value here is 'u-boot'.

> +                    reg = <0 0x50000>;
> +                    read-only;
> +                };
> +
> +                partition@1 {
> +                    label = "U-boot environment 1";

u-boot-env

> +                    reg = <0x50000 0x10000>;
> +                };
> +
> +                partition@2 {
> +                    label = "U-boot environment 2";

alt-u-boot-env or u-boot-env-backup?

> +                    reg = <0x60000 0x10000>;
> +                };
> +
> +                partition@3 {
> +                    label = "W-load";
> +                    reg = <0x70000 0x10000>;
> +                    read-only;
> +                };
> +            };
> +        };
> +    };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6dbdf02d6b0c9357ad1da520a0f6c16b7f38f879..f09c457bbfc5ef71a3f8379c111bac52b767cbbc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3475,6 +3475,7 @@ F:	Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml
>  F:	Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml
>  F:	Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml
>  F:	Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml
> +F:	Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
>  F:	arch/arm/boot/dts/vt8500/
>  F:	arch/arm/mach-vt8500/
>  F:	drivers/clocksource/timer-vt8500.c
> 
> -- 
> 2.49.0
> 

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Alexey Charkov]

On Wed, May 14, 2025 at 11:42 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, May 10, 2025 at 11:42:21PM +0400, Alexey Charkov wrote:
> > Add a binding for the serial flash controller found on VIA/WonderMedia
> > SoCs, which provides semi-transparent access to SPI NOR chips by
> > mapping their contents to the physical CPU address space.
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++
> >  MAINTAINERS                                        |   1 +
> >  2 files changed, 123 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml
> > @@ -0,0 +1,122 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: VIA/WonderMedia serial flash controller
> > +
> > +description:
> > +  This controller is used on VIA/WonderMedia SoCs such as VIA VT8500,
> > +  WonderMedia WM8850 and similar. It provides a semi-transparent interface
> > +  for reading and writing SPI NOR chip contents via a physical memory map,
> > +  abstracting away all SPI communication, while also providing a direct
> > +  mechanism for issuing "programmable commands" to the underlying SPI chip
> > +
> > +maintainers:
> > +  - Alexey Charkov <alchark@gmail.com>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - via,vt8500-sflash
> > +      - wm,wm8505-sflash
> > +      - wm,wm8650-sflash
> > +      - wm,wm8750-sflash
> > +      - wm,wm8850-sflash
> > +
> > +  reg:
> > +    items:
> > +      - description: MMIO registers region of the controller
> > +      - description:
> > +          Physical memory region within which the controller will map the
> > +          flash contents of chip 0 for reading and writing. If the flash
> > +          size is smaller than this region, it will be mapped at its end.
> > +          Note that if this chip is used as the boot device (as is most
> > +          often the case), the boot ROM maps it at the very end of the
> > +          CPU address space (i.e. ending at 0xffffffff)
>
> Period needed on the end.

Noted, thank you! Will adjust in the next version.

> > +      - description:
> > +          Physical memory region within which the controller will map the
> > +          flash contents of chip 1 for reading and writing. If the flash
> > +          size is smaller than this region, it will be mapped at its end
>
> Period needed on the end.

Ditto.

> > +
> > +  reg-names:
> > +    items:
> > +      - const: io
> > +      - const: chip0-mmap
> > +      - const: chip1-mmap
> > +
> > +  clocks:
> > +    maxItems: 1
> > +
> > +  "#address-cells":
> > +    const: 1
> > +
> > +  "#size-cells":
> > +    const: 0
>
> This follows the SPI binding, right? Drop these 2 and add a $ref to
> spi-controller.yaml.

Need some advice here. While this controller speaks SPI protocol to
its connected flash chips, it's a special-purpose thing that doesn't
expose much SPI functionality to the outside world, nor can it drive
any SPI devices other than SPI NOR flash. Does that still qualify as
an SPI controller as far as the bindings are concerned?

Happy to reference the spi-controller.yaml binding if so.

> > +patternProperties:
> > +  "^flash@[0-1]$":
> > +    type: object
> > +    additionalProperties: true
> > +
> > +    properties:
> > +      reg:
> > +        minimum: 0
> > +        maximum: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - reg-names
> > +  - clocks
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    sflash: spi-nor-controller@d8002000 {
>
> spi@...

Related to the question above... Happy to call it spi@ if appropriate
in this case.

> > +        compatible = "wm,wm8850-sflash";
> > +        reg = <0xd8002000 0x400>,
> > +              <0xff800000 0x800000>,
> > +              <0xef800000 0x800000>;
> > +        reg-names = "io", "chip0-mmap", "chip1-mmap";
> > +        clocks = <&clksf>;
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        flash@0 {
> > +            compatible = "jedec,spi-nor";
> > +            reg = <0>;
> > +
> > +            partitions {
> > +                compatible = "fixed-partitions";
> > +                #address-cells = <1>;
> > +                #size-cells = <1>;
> > +
> > +                partition@0 {
> > +                    label = "U-boot";
>
> The somewhat standard value here is 'u-boot'.

Noted, thanks - will adjust in the next version.

> > +                    reg = <0 0x50000>;
> > +                    read-only;
> > +                };
> > +
> > +                partition@1 {
> > +                    label = "U-boot environment 1";
>
> u-boot-env

Ditto.

> > +                    reg = <0x50000 0x10000>;
> > +                };
> > +
> > +                partition@2 {
> > +                    label = "U-boot environment 2";
>
> alt-u-boot-env or u-boot-env-backup?

Ditto.

Thanks for your review and comments Rob!

Best regards,
Alexey

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Krzysztof Kozlowski]

On 15/05/2025 21:50, Alexey Charkov wrote:
>>> +
>>> +  "#address-cells":
>>> +    const: 1
>>> +
>>> +  "#size-cells":
>>> +    const: 0
>>
>> This follows the SPI binding, right? Drop these 2 and add a $ref to
>> spi-controller.yaml.
> 
> Need some advice here. While this controller speaks SPI protocol to
> its connected flash chips, it's a special-purpose thing that doesn't
> expose much SPI functionality to the outside world, nor can it drive
> any SPI devices other than SPI NOR flash. Does that still qualify as
> an SPI controller as far as the bindings are concerned?
> 
> Happy to reference the spi-controller.yaml binding if so.

SPI NOR flashes are still child devices of an SPI controller. You can
look at other examples - aren't they all using spi-controller? Why this
would be different? Unless you found some cases that are different, but
then which ones?



Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Alexey Charkov]

On Fri, Jun 6, 2025 at 12:29 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 15/05/2025 21:50, Alexey Charkov wrote:
> >>> +
> >>> +  "#address-cells":
> >>> +    const: 1
> >>> +
> >>> +  "#size-cells":
> >>> +    const: 0
> >>
> >> This follows the SPI binding, right? Drop these 2 and add a $ref to
> >> spi-controller.yaml.
> >
> > Need some advice here. While this controller speaks SPI protocol to
> > its connected flash chips, it's a special-purpose thing that doesn't
> > expose much SPI functionality to the outside world, nor can it drive
> > any SPI devices other than SPI NOR flash. Does that still qualify as
> > an SPI controller as far as the bindings are concerned?
> >
> > Happy to reference the spi-controller.yaml binding if so.
>
> SPI NOR flashes are still child devices of an SPI controller. You can
> look at other examples - aren't they all using spi-controller? Why this
> would be different? Unless you found some cases that are different, but
> then which ones?

No strong opinions here, and no expectation of any special treatment
:) Just wanted to consult on what's most appropriate.

My (subjective and perhaps unfounded) expectation when seeing
something advertise itself as an SPI controller was that it would be a
general purpose SPI master, to which one can e.g. connect an SPI
driven LCD screen and get it to work with generic Linux SPI
infrastructure - which would not be possible with this single-purpose
NOR-only flash controller. Given that I don't know how flexible or
restrictive other examples are in terms of driving arbitrary SPI
devices, I thought it's better to just ask.

What I'm getting from this exchange here is that I'd better use the
spi-controller binding and respective node names regardless of the
fact that this controller cannot drive arbitrary SPI devices beyond
NOR flash (which, as I'm getting, is irrelevant after all).

Best regards,
Alexey

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Miquel Raynal]

Hi Alexey,

>> > Happy to reference the spi-controller.yaml binding if so.
>>
>> SPI NOR flashes are still child devices of an SPI controller. You can
>> look at other examples - aren't they all using spi-controller? Why this
>> would be different? Unless you found some cases that are different, but
>> then which ones?
>
> No strong opinions here, and no expectation of any special treatment
> :) Just wanted to consult on what's most appropriate.
>
> My (subjective and perhaps unfounded) expectation when seeing
> something advertise itself as an SPI controller was that it would be a
> general purpose SPI master, to which one can e.g. connect an SPI
> driven LCD screen and get it to work with generic Linux SPI
> infrastructure - which would not be possible with this single-purpose
> NOR-only flash controller. Given that I don't know how flexible or
> restrictive other examples are in terms of driving arbitrary SPI
> devices, I thought it's better to just ask.
>
> What I'm getting from this exchange here is that I'd better use the
> spi-controller binding and respective node names regardless of the
> fact that this controller cannot drive arbitrary SPI devices beyond
> NOR flash (which, as I'm getting, is irrelevant after all).

Just for information, there are several SPI controllers which are
optimized for flash handling (not only NOR, though) and for that we have
a spi-mem layer which allows to reference a set of SPI memory "only"
callbacks. On the description side though, these controllers are like
all other SPI controllers, so the same controller bindings may apply.

Thanks,
Miquèl

Re: [PATCH 1/3] dt-bindings: spi: Add VIA/WonderMedia serial flash controller

[Alexey Charkov]

On Mon, Jun 9, 2025 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexey,
>
> >> > Happy to reference the spi-controller.yaml binding if so.
> >>
> >> SPI NOR flashes are still child devices of an SPI controller. You can
> >> look at other examples - aren't they all using spi-controller? Why this
> >> would be different? Unless you found some cases that are different, but
> >> then which ones?
> >
> > No strong opinions here, and no expectation of any special treatment
> > :) Just wanted to consult on what's most appropriate.
> >
> > My (subjective and perhaps unfounded) expectation when seeing
> > something advertise itself as an SPI controller was that it would be a
> > general purpose SPI master, to which one can e.g. connect an SPI
> > driven LCD screen and get it to work with generic Linux SPI
> > infrastructure - which would not be possible with this single-purpose
> > NOR-only flash controller. Given that I don't know how flexible or
> > restrictive other examples are in terms of driving arbitrary SPI
> > devices, I thought it's better to just ask.
> >
> > What I'm getting from this exchange here is that I'd better use the
> > spi-controller binding and respective node names regardless of the
> > fact that this controller cannot drive arbitrary SPI devices beyond
> > NOR flash (which, as I'm getting, is irrelevant after all).
>
> Just for information, there are several SPI controllers which are
> optimized for flash handling (not only NOR, though) and for that we have
> a spi-mem layer which allows to reference a set of SPI memory "only"
> callbacks. On the description side though, these controllers are like
> all other SPI controllers, so the same controller bindings may apply.

Noted, thank you Miquèl!

Best regards,
Alexey

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[Pratyush Yadav]

Hi Alexey,

This email got buried in my inbox somewhere...

On Mon, May 12 2025, Alexey Charkov wrote:

> Hi Pratyush,
>
> On Mon, May 12, 2025 at 1:20 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> Hi Alexey,
>>
>> On Sat, May 10 2025, Alexey Charkov wrote:
>>
>> > The controller is tailored to SPI NOR flash memory and abstracts away all
>> > SPI communications behind a small set of MMIO registers and a physical
>> > memory mapping of the actual chip contents.
>> >
>> > It doesn't expose chip probing functions beyond reading the ID though, so
>> > use lower level chip opcodes via the "programmable command mode" of the
>> > controller and the kernel's SPI NOR framework to avoid hard-coding chip
>> > parameters for each ID the way the vendor kernel does it.
>> >
>> > Currently tested on a WonderMedia WM8950 SoC with a Macronix MX25L4005A
>> > flash chip (APC Rock board), but should work on all VIA/WonderMedia SoCs
>> >
>> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
>> > ---
>> >  MAINTAINERS                                  |   1 +
>> >  drivers/mtd/spi-nor/controllers/Kconfig      |  14 +
>> >  drivers/mtd/spi-nor/controllers/Makefile     |   1 +
>> >  drivers/mtd/spi-nor/controllers/wmt-sflash.c | 525 +++++++++++++++++++++++++++
>>
>> Drivers in drivers/mtd/spi-nor/controllers/ are deprecated, and we want
>> to eventually get rid of the API. The expected way is for drivers to use
>> SPI MEM (drivers/spi/spi-mem.c). SPI MEM drivers are usually more
>> general and not tailored specifically to SPI NOR flashes, so it might be
>> a bit tricky to write drivers for specialized hardware with it. But I
>> think the drivers/spi/spi-intel.c driver is written for similar kind of
>> hardware so it should be possible.
>
> Oops. I've had a look at spi-mem, and it seems like it's not a
> particularly fitting abstraction for this controller.
>
> From what I understood, spi-mem primarily expects to be talking SPI
> opcodes to the controller, and for the controller/driver to bring
> their own chip probing routines. This controller on the other hand
> abstracts the opcodes away, and wants someone to tell it what its
> flash chip can do (the controller itself can only get a chip ID in
> "normal" mode, and it needs to somehow know the chip size and
> standard/fast read capability of the chip). So pretty much the
> opposite, huh.

Does it use SFDP to figure out which opcodes to use? Then it feels very
similar to intel-spi. See [0] for example. I know this is fitting a
square peg in a round hole, but if it isn't too painful then it would
make maintenance on SPI NOR end a bit easier.

Mika (+Cc), you did the conversion of intel-spi to SPI MEM. Maybe you
can share how painful/easy the conversion was, and if it ended up being
maintainable?

>
> In the end, I only need something like spi_nor_detect() and can do the
> rest directly on top of the MTD framework without touching any SPI
> opcodes after the detection is done. Is there any other non-deprecated
> framework that can provide something like this? Maybe physmap? It
> looks even older than SPI NOR though :)

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-intel.c#n905

-- 
Regards,
Pratyush Yadav

Re: [PATCH 2/3] mtd: spi-nor: Add a driver for the VIA/WonderMedia serial flash controller

[Mika Westerberg]

Hi,

On Thu, Jul 24, 2025 at 03:51:08PM +0200, Pratyush Yadav wrote:
> > From what I understood, spi-mem primarily expects to be talking SPI
> > opcodes to the controller, and for the controller/driver to bring
> > their own chip probing routines. This controller on the other hand
> > abstracts the opcodes away, and wants someone to tell it what its
> > flash chip can do (the controller itself can only get a chip ID in
> > "normal" mode, and it needs to somehow know the chip size and
> > standard/fast read capability of the chip). So pretty much the
> > opposite, huh.
> 
> Does it use SFDP to figure out which opcodes to use? Then it feels very
> similar to intel-spi. See [0] for example. I know this is fitting a
> square peg in a round hole, but if it isn't too painful then it would
> make maintenance on SPI NOR end a bit easier.
> 
> Mika (+Cc), you did the conversion of intel-spi to SPI MEM. Maybe you
> can share how painful/easy the conversion was, and if it ended up being
> maintainable?

Well it is kind of "maintainable" but the driver needs to do whole lot of
translation to get the SPI opcodes translated into the commands the
controller can actually execute. This means that if we get new opcodes for
new chips the driver needs to be updated too. I feel the SPI MEM is not
really good fit for "higher level" controllers like this.