[PATCH v4 0/4] ARM: s3c: crag6410: Convert to software nodes and properties

[PATCH v4 0/4] ARM: s3c: crag6410: Convert to software nodes and properties

[Dmitry Torokhov]

Hi,

This series converts the Cragganmore 6410 board to generic software nodes
and device properties, allowing the removal of legacy GPIO lookup tables.

We add software node propagation support to the wm831x MFD core to route
DVS GPIOs to the PMIC regulator, and convert the peripherals on the
Cragganmore board (PMIC DVS GPIO, basic-mmio-gpio, LEDs, WM1250, and SPI0)
from legacy GPIO lookup tables to software nodes and properties. This
eliminates the legacy GPIO lookup tables on the board and fixes incorrect
GPIO chip names from previous conversions.

Hopefully Krzysztof can finish merging the series through the soc tree
once Lee acks the MFD part.

Thanks!

Changes in v4:
- Patches 1-6 from v3 were applied to the samsung-soc tree
- Rebased onto latest linux-next
- Capitalized the MFD patch subject per MFD subsystem conventions
- Added Lee Jones and the MFD mailing list to recipients
- Link to v3: https://patch.msgid.link/20260711-samsung-kp-v3-0-b2fcaba77aff@gmail.com

Changes in v3:
- Fixed legacy property handling regression in the keypad driver by
  separating compact and verbose binding paths
- Removed redundant registration of crag6410_mmgpio_node from
  mach-crag6410.c
- Removed dead S3C64XX_SETUP_KEYPAD Kconfig symbol definition and
  selection
- Fixed missing newline in pr_err() message in mach-crag6410.c
- Redesigned PMIC DVS support to keep regulator driver changes minimal
  (untouched) and only use software nodes for GPIO routing via MFD core
- Link to v2: https://patch.msgid.link/20260708-samsung-kp-v2-0-3c6ed4c9b3b6@gmail.com

Changes in v2:
- Patches 1-8 of v1 were merged into mainline, dropping them from this
  series
- Rebased patches 9-14 of v1 onto latest next
- Resolved conflicts in mach-crag6410.c
- Removed redundant "out of memory" error messages from the keypad
  driver
- Added an infrastructure patch to register and attach software nodes
  for Samsung gpio_chips
- Converted basic-mmio-gpio and LEDs on Cragganmore 6410 to software
  properties in a new separate patch
- Addressed DT bindings feedback on the compact binding patch
- Fixed proximity switch event type for GPIO keys
- Added support for software nodes in wm831x regulator driver
- Converted PMIC DVS on Cragganmore 6410 to software properties using
  the new driver support
- Removed legacy DVS platform data fields and cleaned up driver
  fallback.

---
Dmitry Torokhov (4):
      mfd: wm831x: Support software nodes for DCDC regulators
      ARM: s3c: crag6410: convert PMIC DVS GPIO to software properties
      ARM: s3c: crag6410: convert basic-mmio-gpio and LEDs to software properties
      ARM: s3c: crag6410: convert WM1250 and SPI0 GPIO lookup tables to property entries

 arch/arm/mach-s3c/devs.c          |  35 ------
 arch/arm/mach-s3c/devs.h          |   1 -
 arch/arm/mach-s3c/mach-crag6410.c | 234 ++++++++++++++++++++++----------------
 drivers/mfd/wm831x-core.c         |  47 ++++++--
 include/linux/mfd/wm831x/pdata.h  |   2 +
 5 files changed, 175 insertions(+), 144 deletions(-)
---
base-commit: 20a33c6b6cbe7e4805dfb6cd68816937443aa148
change-id: 20240819-samsung-kp-ceedd4f2f720

Thanks.

-- 
Dmitry

[PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Dmitry Torokhov]

Allow passing software nodes to wm831x DCDC regulators via PMIC platform
data. This is useful for non-DT/non-ACPI platforms that want to
associate device properties (like DVS GPIOs) with the regulator devices
using software nodes.

Add software node pointers to the PMIC platform data and have the MFD
core assign them to the buckv cells.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/mfd/wm831x-core.c        | 47 ++++++++++++++++++++++++++++++----------
 include/linux/mfd/wm831x/pdata.h |  2 ++
 2 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
index df8e76e000cc..c4793be419ba 100644
--- a/drivers/mfd/wm831x-core.c
+++ b/drivers/mfd/wm831x-core.c
@@ -14,6 +14,7 @@
 #include <linux/delay.h>
 #include <linux/mfd/core.h>
 #include <linux/slab.h>
+#include <linux/string.h>
 #include <linux/err.h>
 
 #include <linux/mfd/wm831x/core.h>
@@ -1449,6 +1450,32 @@ const struct of_device_id wm831x_of_match[] = {
 };
 EXPORT_SYMBOL_GPL(wm831x_of_match);
 
+static int wm831x_add_devices(struct wm831x *wm831x, int wm831x_num,
+			      const struct mfd_cell *cells, int num_cells)
+{
+	struct wm831x_pdata *pdata = &wm831x->pdata;
+	int i;
+
+	struct mfd_cell *local_cells __free(kfree) =
+		kmemdup_array(cells, num_cells, sizeof(*cells), GFP_KERNEL);
+	if (!local_cells)
+		return -ENOMEM;
+
+	for (i = 0; i < num_cells; i++) {
+		struct mfd_cell *cell = &local_cells[i];
+
+		if (strcmp(cell->name, "wm831x-buckv") == 0) {
+			int id = cell->id - 1;
+
+			if (id >= 0 && id < WM831X_MAX_DCDC)
+				cell->swnode = pdata->dcdc_swnodes[id];
+		}
+	}
+
+	return mfd_add_devices(wm831x->dev, wm831x_num, local_cells, num_cells,
+			       NULL, 0, NULL);
+}
+
 /*
  * Instantiate the generic non-control parts of the device.
  */
@@ -1620,15 +1647,13 @@ int wm831x_device_init(struct wm831x *wm831x, int irq)
 	/* The core device is up, instantiate the subdevices. */
 	switch (parent) {
 	case WM8310:
-		ret = mfd_add_devices(wm831x->dev, wm831x_num,
-				      wm8310_devs, ARRAY_SIZE(wm8310_devs),
-				      NULL, 0, NULL);
+		ret = wm831x_add_devices(wm831x, wm831x_num,
+					 wm8310_devs, ARRAY_SIZE(wm8310_devs));
 		break;
 
 	case WM8311:
-		ret = mfd_add_devices(wm831x->dev, wm831x_num,
-				      wm8311_devs, ARRAY_SIZE(wm8311_devs),
-				      NULL, 0, NULL);
+		ret = wm831x_add_devices(wm831x, wm831x_num,
+					 wm8311_devs, ARRAY_SIZE(wm8311_devs));
 		if (!pdata->disable_touch)
 			mfd_add_devices(wm831x->dev, wm831x_num,
 					touch_devs, ARRAY_SIZE(touch_devs),
@@ -1636,9 +1661,8 @@ int wm831x_device_init(struct wm831x *wm831x, int irq)
 		break;
 
 	case WM8312:
-		ret = mfd_add_devices(wm831x->dev, wm831x_num,
-				      wm8312_devs, ARRAY_SIZE(wm8312_devs),
-				      NULL, 0, NULL);
+		ret = wm831x_add_devices(wm831x, wm831x_num,
+					 wm8312_devs, ARRAY_SIZE(wm8312_devs));
 		if (!pdata->disable_touch)
 			mfd_add_devices(wm831x->dev, wm831x_num,
 					touch_devs, ARRAY_SIZE(touch_devs),
@@ -1649,9 +1673,8 @@ int wm831x_device_init(struct wm831x *wm831x, int irq)
 	case WM8321:
 	case WM8325:
 	case WM8326:
-		ret = mfd_add_devices(wm831x->dev, wm831x_num,
-				      wm8320_devs, ARRAY_SIZE(wm8320_devs),
-				      NULL, 0, NULL);
+		ret = wm831x_add_devices(wm831x, wm831x_num,
+					 wm8320_devs, ARRAY_SIZE(wm8320_devs));
 		break;
 
 	default:
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index 75aa94dadf1c..d5d9d9600756 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -12,6 +12,7 @@
 
 struct wm831x;
 struct regulator_init_data;
+struct software_node;
 
 struct wm831x_backlight_pdata {
 	int isink;     /** ISINK to use, 1 or 2 */
@@ -132,6 +133,7 @@ struct wm831x_pdata {
 	struct wm831x_status_pdata *status[WM831X_MAX_STATUS];
 	/** DCDC1 = 0 and so on */
 	struct regulator_init_data *dcdc[WM831X_MAX_DCDC];
+	const struct software_node *dcdc_swnodes[WM831X_MAX_DCDC];
 	/** EPE1 = 0 and so on */
 	struct regulator_init_data *epe[WM831X_MAX_EPE];
 	/** LDO1 = 0 and so on */

-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v4 2/4] ARM: s3c: crag6410: convert PMIC DVS GPIO to software properties

[Dmitry Torokhov]

Convert the PMIC DVS GPIO configuration from a legacy lookup table to
software properties. We use the new 'dcdc_swnodes' field in 'struct
wm831x_pdata' to pass the software node to the regulator driver.
We keep the DVS configuration parameters (control source, startup
state) in the platform data.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 arch/arm/mach-s3c/mach-crag6410.c | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index 2264beef6dda..d0ec7697f366 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -456,6 +456,17 @@ static struct pca953x_platform_data crag6410_pca_data = {
 	.irq_base	= -1,
 };
 
+static const struct property_entry crag_dcdc1_properties[] = {
+	PROPERTY_ENTRY_GPIO("dvs-gpios",
+			    SAMSUNG_GPIO_NODE('K'), 0, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct software_node crag_dcdc1_swnode = {
+	.name = "wm831x-buckv-dcdc1",
+	.properties = crag_dcdc1_properties,
+};
+
 /* VDDARM is controlled by DVS1 connected to GPK(0) */
 static struct wm831x_buckv_pdata vddarm_pdata = {
 	.dvs_control_src = 1,
@@ -633,6 +644,9 @@ static struct wm831x_pdata crag_pmic_pdata = {
 		&vddint,  /* DCDC2 */
 		&vddmem,  /* DCDC3 */
 	},
+	.dcdc_swnodes = {
+		&crag_dcdc1_swnode,
+	},
 
 	.ldo = {
 		&vddsys,   /* LDO1 */
@@ -656,24 +670,6 @@ static struct wm831x_pdata crag_pmic_pdata = {
 	.touch = &touch_pdata,
 };
 
-/*
- * VDDARM is eventually ending up as a regulator hanging on the MFD cell device
- * "wm831x-buckv.1" spawn from drivers/mfd/wm831x-core.c.
- *
- * From the note on the platform data we can see that this is clearly DVS1
- * and assigned as dcdc1 resource to the MFD core which sets .id of the cell
- * spawning the DVS1 platform device to 1, then the cell platform device
- * name is calculated from 10*instance + id resulting in the device name
- * "wm831x-buckv.11"
- */
-static struct gpiod_lookup_table crag_pmic_gpiod_table = {
-	.dev_id = "wm831x-buckv.11",
-	.table = {
-		GPIO_LOOKUP("GPIOK", 0, "dvs", GPIO_ACTIVE_HIGH),
-		{ },
-	},
-};
-
 static struct i2c_board_info i2c_devs0[] = {
 	{ I2C_BOARD_INFO("24c08", 0x50), },
 	{ I2C_BOARD_INFO("tca6408", 0x20),
@@ -931,7 +927,7 @@ static void __init crag6410_machine_init(void)
 	s3c_fb_set_platdata(&crag6410_lcd_pdata);
 	dwc2_hsotg_set_platdata(&crag6410_hsotg_pdata);
 
-	gpiod_add_lookup_table(&crag_pmic_gpiod_table);
+	software_node_register(&crag_dcdc1_swnode);
 	i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
 	gpiod_add_lookup_table(&crag_wm1250_ev1_gpiod_table);
 	i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));

-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v4 3/4] ARM: s3c: crag6410: convert basic-mmio-gpio and LEDs to software properties

[Dmitry Torokhov]

Convert the basic-mmio-gpio device and the GPIO-controlled LEDs on the
Cragganmore 6410 board to use software nodes/properties. This allows
removing the crag_leds_table GPIO lookup table.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 arch/arm/mach-s3c/mach-crag6410.c | 117 +++++++++++++++++++++-----------------
 1 file changed, 64 insertions(+), 53 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index d0ec7697f366..2855d6d32fa3 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -319,12 +319,17 @@ static const struct property_entry crag6410_mmgpio_props[] = {
 	{ }
 };
 
+static const struct software_node crag6410_mmgpio_node = {
+	.name		= "basic-mmio-gpio",
+	.properties	= crag6410_mmgpio_props,
+};
+
 static struct platform_device_info crag6410_mmgpio_devinfo = {
 	.name		= "basic-mmio-gpio",
 	.id		= -1,
 	.res		= crag6410_mmgpio_resource,
 	.num_res	= ARRAY_SIZE(crag6410_mmgpio_resource),
-	.properties	= crag6410_mmgpio_props,
+	.swnode		= &crag6410_mmgpio_node,
 };
 
 static struct platform_device speyside_device = {
@@ -835,61 +840,68 @@ static struct s3c_sdhci_platdata crag6410_hsmmc0_pdata = {
 	.host_caps		= MMC_CAP_POWER_OFF_CARD,
 };
 
-static const struct gpio_led gpio_leds[] = {
-	{
-		.name = "d13:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d14:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d15:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d16:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d17:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d18:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d19:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
-	{
-		.name = "d20:green:",
-		.default_state = LEDS_GPIO_DEFSTATE_ON,
-	},
+static const struct software_node crag6410_leds_node = {
+	.name = "leds-gpio",
 };
 
-static struct gpiod_lookup_table crag_leds_table = {
-	.dev_id = "leds-gpio",
-	.table = {
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 0, "cs", 0, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 1, "cs", 1, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 2, "cs", 2, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 3, "cs", 3, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 4, "cs", 4, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 5, "cs", 5, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 6, "cs", 6, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("basic-mmio-gpio", 7, "cs", 7, GPIO_ACTIVE_LOW),
-		{ },
-	},
-};
+#define CRAG6410_LED_NODE(_idx, _name)					\
+static const struct property_entry crag6410_led##_idx##_props[] = {	\
+	PROPERTY_ENTRY_STRING("label", _name),				\
+	PROPERTY_ENTRY_GPIO("gpios", &crag6410_mmgpio_node,		\
+			    _idx, GPIO_ACTIVE_LOW),			\
+	PROPERTY_ENTRY_STRING("default-state", "on"),			\
+	{ }								\
+};									\
+static const struct software_node crag6410_led##_idx##_node = {	\
+	.parent = &crag6410_leds_node,					\
+	.properties = crag6410_led##_idx##_props,			\
+}
 
-static const struct gpio_led_platform_data gpio_leds_pdata = {
-	.leds = gpio_leds,
-	.num_leds = ARRAY_SIZE(gpio_leds),
+CRAG6410_LED_NODE(0, "d13:green:");
+CRAG6410_LED_NODE(1, "d14:green:");
+CRAG6410_LED_NODE(2, "d15:green:");
+CRAG6410_LED_NODE(3, "d16:green:");
+CRAG6410_LED_NODE(4, "d17:green:");
+CRAG6410_LED_NODE(5, "d18:green:");
+CRAG6410_LED_NODE(6, "d19:green:");
+CRAG6410_LED_NODE(7, "d20:green:");
+
+static const struct software_node *crag6410_leds_swnodes[] = {
+	&crag6410_leds_node,
+	&crag6410_led0_node,
+	&crag6410_led1_node,
+	&crag6410_led2_node,
+	&crag6410_led3_node,
+	&crag6410_led4_node,
+	&crag6410_led5_node,
+	&crag6410_led6_node,
+	&crag6410_led7_node,
+	NULL
 };
 
+static void __init crag6410_setup_leds(void)
+{
+	struct platform_device_info leds_info = {
+		.name	= "leds-gpio",
+		.id	= PLATFORM_DEVID_NONE,
+	};
+	struct platform_device *pd;
+	int err;
+
+	err = software_node_register_node_group(crag6410_leds_swnodes);
+	if (err) {
+		pr_err("failed to register leds software nodes: %d\n", err);
+		return;
+	}
+
+	leds_info.fwnode = software_node_fwnode(&crag6410_leds_node);
+
+	pd = platform_device_register_full(&leds_info);
+	err = PTR_ERR_OR_ZERO(pd);
+	if (err)
+		pr_err("failed to create leds-gpio device: %d\n", err);
+}
+
 static struct dwc2_hsotg_plat crag6410_hsotg_pdata;
 
 static struct gpiod_lookup_table crag_spi0_gpiod_table = {
@@ -939,12 +951,11 @@ static void __init crag6410_machine_init(void)
 	platform_add_devices(crag6410_devs0, ARRAY_SIZE(crag6410_devs0));
 	platform_device_register_full(&crag6410_mmgpio_devinfo);
 
-	gpiod_add_lookup_table(&crag_leds_table);
 	crag6410_setup_keypad();
 	crag6410_setup_gpio_keys();
 
 	platform_add_devices(crag6410_devs1, ARRAY_SIZE(crag6410_devs1));
-	gpio_led_register_device(-1, &gpio_leds_pdata);
+	crag6410_setup_leds();
 
 	regulator_has_full_constraints();
 

-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v4 4/4] ARM: s3c: crag6410: convert WM1250 and SPI0 GPIO lookup tables to property entries

[Dmitry Torokhov]

Static property entries support defining GPIOs and are more similar to
device tree properties and are not prone to losing link between device
and a lookup table because of changes in device name. Convert the board
to use them for WM1250 and SPI0 devices.

This also fixes issue with recent conversion to GPIO descriptors
where GPIO lookup tables were specifying incorrect GPIO chip name
("GPIO<N>" vs "GP<N>").

Fixes: 10a366f36e2a ("ASoC: wm1250-ev1: Convert to GPIO descriptors")
Fixes: a45cf3cc72dd ("spi: s3c64xx: Convert to use GPIO descriptors")
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 arch/arm/mach-s3c/devs.c          | 35 -----------------
 arch/arm/mach-s3c/devs.h          |  1 -
 arch/arm/mach-s3c/mach-crag6410.c | 83 ++++++++++++++++++++++++++++-----------
 3 files changed, 59 insertions(+), 60 deletions(-)

diff --git a/arch/arm/mach-s3c/devs.c b/arch/arm/mach-s3c/devs.c
index 35b98a9a9237..7c8dc29b994b 100644
--- a/arch/arm/mach-s3c/devs.c
+++ b/arch/arm/mach-s3c/devs.c
@@ -335,38 +335,3 @@ void __init dwc2_hsotg_set_platdata(struct dwc2_hsotg_plat *pd)
 		npd->phy_exit = s3c_usb_phy_exit;
 }
 #endif /* CONFIG_S3C_DEV_USB_HSOTG */
-
-#ifdef CONFIG_S3C64XX_DEV_SPI0
-static struct resource s3c64xx_spi0_resource[] = {
-	[0] = DEFINE_RES_MEM(S3C_PA_SPI0, SZ_256),
-	[1] = DEFINE_RES_IRQ(IRQ_SPI0),
-};
-
-struct platform_device s3c64xx_device_spi0 = {
-	.name		= "s3c6410-spi",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(s3c64xx_spi0_resource),
-	.resource	= s3c64xx_spi0_resource,
-	.dev = {
-		.dma_mask		= &samsung_device_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
-void __init s3c64xx_spi0_set_platdata(int src_clk_nr, int num_cs)
-{
-	struct s3c64xx_spi_info pd;
-
-	/* Reject invalid configuration */
-	if (!num_cs || src_clk_nr < 0) {
-		pr_err("%s: Invalid SPI configuration\n", __func__);
-		return;
-	}
-
-	pd.num_cs = num_cs;
-	pd.src_clk_nr = src_clk_nr;
-	pd.cfg_gpio = s3c64xx_spi0_cfg_gpio;
-
-	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
-}
-#endif /* CONFIG_S3C64XX_DEV_SPI0 */
diff --git a/arch/arm/mach-s3c/devs.h b/arch/arm/mach-s3c/devs.h
index 2737990063b1..90a86ade3570 100644
--- a/arch/arm/mach-s3c/devs.h
+++ b/arch/arm/mach-s3c/devs.h
@@ -27,7 +27,6 @@ extern struct platform_device *s3c24xx_uart_src[];
 
 extern struct platform_device s3c64xx_device_iis0;
 extern struct platform_device s3c64xx_device_iis1;
-extern struct platform_device s3c64xx_device_spi0;
 
 extern struct platform_device s3c_device_fb;
 extern struct platform_device s3c_device_hsmmc0;
diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index 2855d6d32fa3..330e8cf12ddc 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -443,7 +443,6 @@ static struct platform_device *crag6410_devs0[] __initdata = {
 
 static struct platform_device *crag6410_devs1[] __initdata = {
 	&crag6410_dm9k_device,
-	&s3c64xx_device_spi0,
 	&crag6410_lcd_powerdev,
 	&crag6410_backlight_device,
 	&speyside_device,
@@ -777,17 +776,22 @@ static struct wm831x_pdata glenfarclas_pmic_pdata = {
 	.disable_touch = true,
 };
 
-static struct gpiod_lookup_table crag_wm1250_ev1_gpiod_table = {
-	/* The WM1250-EV1 is device 0027 on I2C bus 1 */
-	.dev_id = "1-0027",
-	.table = {
-		GPIO_LOOKUP("GPION", 12, "clk-ena", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("GPIOL", 12, "clk-sel0", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("GPIOL", 13, "clk-sel1", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("GPIOL", 14, "osr", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("GPIOL", 8, "master", GPIO_ACTIVE_HIGH),
-		{ },
-	},
+static const struct property_entry crag_wm1250_ev1_properties[] = {
+	PROPERTY_ENTRY_GPIO("clk-ena-gpios",
+			    SAMSUNG_GPIO_NODE('N'), 12, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("clk-sel0-gpios",
+			    SAMSUNG_GPIO_NODE('L'), 12, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("clk-sel1-gpios",
+			    SAMSUNG_GPIO_NODE('L'), 13, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("osr-gpios",
+			    SAMSUNG_GPIO_NODE('L'), 14, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("master-gpios",
+			    SAMSUNG_GPIO_NODE('L'), 8, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct software_node crag_wm1250_ev1_swnode = {
+	.properties = crag_wm1250_ev1_properties,
 };
 
 static struct i2c_board_info i2c_devs1[] = {
@@ -800,7 +804,8 @@ static struct i2c_board_info i2c_devs1[] = {
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x24) },
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x25) },
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x26) },
-	{ I2C_BOARD_INFO("wm1250-ev1", 0x27), },
+	{ I2C_BOARD_INFO("wm1250-ev1", 0x27),
+	  .swnode = &crag_wm1250_ev1_swnode, },
 };
 
 static struct s3c2410_platform_i2c i2c1_pdata = {
@@ -904,15 +909,48 @@ static void __init crag6410_setup_leds(void)
 
 static struct dwc2_hsotg_plat crag6410_hsotg_pdata;
 
-static struct gpiod_lookup_table crag_spi0_gpiod_table = {
-	.dev_id = "s3c6410-spi.0",
-	.table = {
-		GPIO_LOOKUP_IDX("GPIOC", 3, "cs", 0, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("GPION", 5, "cs", 1, GPIO_ACTIVE_LOW),
-		{ },
-	},
+static const struct software_node_ref_args crag6410_spi0_gpio_refs[] = {
+	SOFTWARE_NODE_REFERENCE(SAMSUNG_GPIO_NODE('C'), 3, GPIO_ACTIVE_LOW),
+	SOFTWARE_NODE_REFERENCE(SAMSUNG_GPIO_NODE('N'), 5, GPIO_ACTIVE_LOW),
+};
+
+static const struct property_entry crag6410_spi0_properties[] __initconst = {
+	PROPERTY_ENTRY_REF_ARRAY("cs-gpios", crag6410_spi0_gpio_refs),
+	{ }
+};
+
+static const struct resource crag6410_spi0_resource[] __initconst = {
+	[0] = DEFINE_RES_MEM(S3C_PA_SPI0, SZ_256),
+	[1] = DEFINE_RES_IRQ(IRQ_SPI0),
+};
+
+static const struct s3c64xx_spi_info crag6410_spi0_platform_data __initconst = {
+	.num_cs = 2,
+	.cfg_gpio = s3c64xx_spi0_cfg_gpio,
 };
 
+static const struct platform_device_info crag6410_spi0_info __initconst = {
+	.name		= "s3c6410-spi",
+	.id		= 0,
+	.res		= crag6410_spi0_resource,
+	.num_res	= ARRAY_SIZE(crag6410_spi0_resource),
+	.data		= &crag6410_spi0_platform_data,
+	.size_data	= sizeof(crag6410_spi0_platform_data),
+	.dma_mask	= DMA_BIT_MASK(32),
+	.properties	= crag6410_spi0_properties,
+};
+
+static void __init crag6410_setup_spi0(void)
+{
+	struct platform_device *pd;
+	int err;
+
+	pd = platform_device_register_full(&crag6410_spi0_info);
+	err = PTR_ERR_OR_ZERO(pd);
+	if (err)
+		pr_err("failed to create spi0 device: %d\n", err);
+}
+
 static void __init crag6410_machine_init(void)
 {
 	/* Open drain IRQs need pullups */
@@ -941,18 +979,15 @@ static void __init crag6410_machine_init(void)
 
 	software_node_register(&crag_dcdc1_swnode);
 	i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
-	gpiod_add_lookup_table(&crag_wm1250_ev1_gpiod_table);
 	i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
 
-	gpiod_add_lookup_table(&crag_spi0_gpiod_table);
-	s3c64xx_spi0_set_platdata(0, 2);
-
 	pwm_add_table(crag6410_pwm_lookup, ARRAY_SIZE(crag6410_pwm_lookup));
 	platform_add_devices(crag6410_devs0, ARRAY_SIZE(crag6410_devs0));
 	platform_device_register_full(&crag6410_mmgpio_devinfo);
 
 	crag6410_setup_keypad();
 	crag6410_setup_gpio_keys();
+	crag6410_setup_spi0();
 
 	platform_add_devices(crag6410_devs1, ARRAY_SIZE(crag6410_devs1));
 	crag6410_setup_leds();

-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Charles Keepax]

On Sat, Oct 24, 2026 at 10:03:12PM -0700, Dmitry Torokhov wrote:
> Allow passing software nodes to wm831x DCDC regulators via PMIC platform
> data. This is useful for non-DT/non-ACPI platforms that want to
> associate device properties (like DVS GPIOs) with the regulator devices
> using software nodes.
> 
> Add software node pointers to the PMIC platform data and have the MFD
> core assign them to the buckv cells.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---

Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

Re: [PATCH v4 0/4] ARM: s3c: crag6410: Convert to software nodes and properties

[Arnd Bergmann]

On Sun, Oct 25, 2026, at 06:03, Dmitry Torokhov wrote:
> Hi,
>
> This series converts the Cragganmore 6410 board to generic software nodes
> and device properties, allowing the removal of legacy GPIO lookup tables.
>
> We add software node propagation support to the wm831x MFD core to route
> DVS GPIOs to the PMIC regulator, and convert the peripherals on the
> Cragganmore board (PMIC DVS GPIO, basic-mmio-gpio, LEDs, WM1250, and SPI0)
> from legacy GPIO lookup tables to software nodes and properties. This
> eliminates the legacy GPIO lookup tables on the board and fixes incorrect
> GPIO chip names from previous conversions.
>
> Hopefully Krzysztof can finish merging the series through the soc tree
> once Lee acks the MFD part.

Hi Dmitry,

This all looks good to me,

Acked-by: Arnd Bergmann <arnd@arndb.de>

I'm a bit unsure about how this fits into your wider plan, i.e. why it
is helpful to replace the lookup tables with device properties in
this file:
Are you working towards eliminating all gpio lookup tables from
the ~50 files currently defining them, or is there an immediate
benefit to doing this one in particular even without the others?

Do you plan to also eliminate the uses of the legacy gpio
interfaces in mach-s3c, e.g. the hardcoded numbers
in {pca953x,wm831x}_platform_data, crag6410_lcd_power_set(),
crag6410_machine_init(), or the pin config in
s3c64xx_i2s_cfg_gpio()?

     Arnd

Re: [PATCH v4 0/4] ARM: s3c: crag6410: Convert to software nodes and properties

[Dmitry Torokhov]

On Mon, Oct 26, 2026 at 02:51:16PM +0100, Arnd Bergmann wrote:
> On Sun, Oct 25, 2026, at 06:03, Dmitry Torokhov wrote:
> > Hi,
> >
> > This series converts the Cragganmore 6410 board to generic software nodes
> > and device properties, allowing the removal of legacy GPIO lookup tables.
> >
> > We add software node propagation support to the wm831x MFD core to route
> > DVS GPIOs to the PMIC regulator, and convert the peripherals on the
> > Cragganmore board (PMIC DVS GPIO, basic-mmio-gpio, LEDs, WM1250, and SPI0)
> > from legacy GPIO lookup tables to software nodes and properties. This
> > eliminates the legacy GPIO lookup tables on the board and fixes incorrect
> > GPIO chip names from previous conversions.
> >
> > Hopefully Krzysztof can finish merging the series through the soc tree
> > once Lee acks the MFD part.
> 
> Hi Dmitry,
> 
> This all looks good to me,
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> I'm a bit unsure about how this fits into your wider plan, i.e. why it
> is helpful to replace the lookup tables with device properties in
> this file:
> Are you working towards eliminating all gpio lookup tables from
> the ~50 files currently defining them, or is there an immediate
> benefit to doing this one in particular even without the others?

Yes, I would like to eventually remove the lookup tables and rely only
on software nodes. How quickly I can do that is a big question, but
I'll try ;)

> 
> Do you plan to also eliminate the uses of the legacy gpio
> interfaces in mach-s3c, e.g. the hardcoded numbers
> in {pca953x,wm831x}_platform_data, crag6410_lcd_power_set(),
> crag6410_machine_init(), or the pin config in
> s3c64xx_i2s_cfg_gpio()?

Let me take a look.

Thanks.

-- 
Dmitry

Re: [PATCH v4 2/4] ARM: s3c: crag6410: convert PMIC DVS GPIO to software properties

[Bartosz Golaszewski]

On Sun, 25 Oct 2026 06:03:13 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> Convert the PMIC DVS GPIO configuration from a legacy lookup table to
> software properties. We use the new 'dcdc_swnodes' field in 'struct
> wm831x_pdata' to pass the software node to the regulator driver.
> We keep the DVS configuration parameters (control source, startup
> state) in the platform data.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Bartosz Golaszewski]

On Sun, 25 Oct 2026 06:03:12 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> Allow passing software nodes to wm831x DCDC regulators via PMIC platform
> data. This is useful for non-DT/non-ACPI platforms that want to
> associate device properties (like DVS GPIOs) with the regulator devices
> using software nodes.
>
> Add software node pointers to the PMIC platform data and have the MFD
> core assign them to the buckv cells.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Lee Jones]

On Sat, 24 Oct 2026, Dmitry Torokhov wrote:

> Allow passing software nodes to wm831x DCDC regulators via PMIC platform
> data. This is useful for non-DT/non-ACPI platforms that want to
> associate device properties (like DVS GPIOs) with the regulator devices
> using software nodes.
> 
> Add software node pointers to the PMIC platform data and have the MFD
> core assign them to the buckv cells.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/mfd/wm831x-core.c        | 47 ++++++++++++++++++++++++++++++----------
>  include/linux/mfd/wm831x/pdata.h |  2 ++
>  2 files changed, 37 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
> index df8e76e000cc..c4793be419ba 100644
> --- a/drivers/mfd/wm831x-core.c
> +++ b/drivers/mfd/wm831x-core.c
> @@ -14,6 +14,7 @@
>  #include <linux/delay.h>
>  #include <linux/mfd/core.h>
>  #include <linux/slab.h>
> +#include <linux/string.h>
>  #include <linux/err.h>
>  
>  #include <linux/mfd/wm831x/core.h>
> @@ -1449,6 +1450,32 @@ const struct of_device_id wm831x_of_match[] = {
>  };
>  EXPORT_SYMBOL_GPL(wm831x_of_match);
>  
> +static int wm831x_add_devices(struct wm831x *wm831x, int wm831x_num,
> +			      const struct mfd_cell *cells, int num_cells)
> +{
> +	struct wm831x_pdata *pdata = &wm831x->pdata;
> +	int i;
> +
> +	struct mfd_cell *local_cells __free(kfree) =
> +		kmemdup_array(cells, num_cells, sizeof(*cells), GFP_KERNEL);
> +	if (!local_cells)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num_cells; i++) {
> +		struct mfd_cell *cell = &local_cells[i];
> +
> +		if (strcmp(cell->name, "wm831x-buckv") == 0) {
> +			int id = cell->id - 1;
> +
> +			if (id >= 0 && id < WM831X_MAX_DCDC)
> +				cell->swnode = pdata->dcdc_swnodes[id];
> +		}
> +	}

I can't begin to tell you how much I hate this.

Why are we duplicating massive static const structs just to add a S/W
node?  Is there no other way we can do this statically?

Since pdata is being populated already, why not just pass that on to the
consuming child device (the regulator)?

> +	return mfd_add_devices(wm831x->dev, wm831x_num, local_cells, num_cells,
> +			       NULL, 0, NULL);
> +}

-- 
Lee Jones

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Dmitry Torokhov]

Hi Lee,

On Wed, Nov 04, 2026 at 06:14:29PM +0000, Lee Jones wrote:
> On Sat, 24 Oct 2026, Dmitry Torokhov wrote:
> > +static int wm831x_add_devices(struct wm831x *wm831x, int wm831x_num,
> > +			      const struct mfd_cell *cells, int num_cells)
> > +{
> > +	struct wm831x_pdata *pdata = &wm831x->pdata;
> > +	int i;
> > +
> > +	struct mfd_cell *local_cells __free(kfree) =
> > +		kmemdup_array(cells, num_cells, sizeof(*cells), GFP_KERNEL);
> > +	if (!local_cells)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; i < num_cells; i++) {
> > +		struct mfd_cell *cell = &local_cells[i];
> > +
> > +		if (strcmp(cell->name, "wm831x-buckv") == 0) {
> > +			int id = cell->id - 1;
> > +
> > +			if (id >= 0 && id < WM831X_MAX_DCDC)
> > +				cell->swnode = pdata->dcdc_swnodes[id];
> > +		}
> > +	}
>
> I can't begin to tell you how much I hate this.
>
> Why are we duplicating massive static const structs just to add a S/W
> node?  Is there no other way we can do this statically?

The software node itself is defined statically in the board file
(crag_dcdc1_swnode in arch/arm/mach-s3c/mach-crag6410.c in patch 2/4),
as it describes board-specific and PMIC-instance-specific wiring -
specifically the host SoC GPIO wired to the PMIC's DVS pin (GPK(0) on
Cragganmore 6410).

Because wm831x-core.c is a generic PMIC driver that can be instantiated
on different boards or even multiple times on the same board (for
example, Cragganmore 6410 has two WM831x PMIC instances, only one of
which has a DVS GPIO wired to DCDC1), the shared static mfd_cell arrays
in wm831x-core.c cannot point to a board's software node at compile
time.

Note that local_cells is annotated with __free(kfree), so the duplicate
array only lives for the duration of the mfd_add_devices() call (which
makes its own per-device copy of each mfd_cell anyway) and is freed
immediately before wm831x_add_devices() returns.

> Since pdata is being populated already, why not just pass that on to the
> consuming child device (the regulator)?

The regulator driver (wm831x_buckv_dvs_init() in
drivers/regulator/wm831x-dcdc.c) acquires the DVS GPIO using
devm_gpiod_get(&pdev->dev, "dvs", ...). When converting the board file
away from legacy gpiod_lookup_table to software nodes (to drop the
fragile MFD device name matching and fix the GPIO chip label lookup),
gpiolib resolves the "dvs-gpios" property against the consumer device's
fwnode (&pdev->dev), so the software node needs to be attached to the
wm831x-buckv platform device.

In v2 of this series I actually tried passing the software_node pointer
through wm831x_buckv_pdata and attaching it to &pdev->dev inside the
regulator driver's probe() [1]. However, attaching a software node to
an already-registered platform device inside probe() is awkward and
requires manual teardown in the child driver, whereas mfd-core already
has built-in support for cell->swnode in mfd_add_device() (attaching
the node via device_add_software_node() before platform_device_add(),
and cleaning it up via device_remove_software_node() on error or
removal). Populating cell->swnode lets mfd-core manage the software
node lifecycle cleanly and keeps the regulator driver untouched.

If you prefer not to kmemdup the full cell table, another option would
be to split the buckv cells out of the main wm831x cell arrays and
register them via a separate mfd_add_devices() call, though that seemed
more intrusive across wm8310/wm8311/wm8312/wm8320. Please let me know
what you would prefer here.

[1] https://lore.kernel.org/all/20260708-samsung-kp-v2-7-3c6ed4c9b3b6@gmail.com/

Thanks.

-- 
Dmitry

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Lee Jones]

On Wed, 04 Nov 2026, Dmitry Torokhov wrote:

> Hi Lee,
> 
> On Wed, Nov 04, 2026 at 06:14:29PM +0000, Lee Jones wrote:
> > On Sat, 24 Oct 2026, Dmitry Torokhov wrote:
> > > +static int wm831x_add_devices(struct wm831x *wm831x, int wm831x_num,
> > > +			      const struct mfd_cell *cells, int num_cells)
> > > +{
> > > +	struct wm831x_pdata *pdata = &wm831x->pdata;
> > > +	int i;
> > > +
> > > +	struct mfd_cell *local_cells __free(kfree) =
> > > +		kmemdup_array(cells, num_cells, sizeof(*cells), GFP_KERNEL);
> > > +	if (!local_cells)
> > > +		return -ENOMEM;
> > > +
> > > +	for (i = 0; i < num_cells; i++) {
> > > +		struct mfd_cell *cell = &local_cells[i];
> > > +
> > > +		if (strcmp(cell->name, "wm831x-buckv") == 0) {
> > > +			int id = cell->id - 1;
> > > +
> > > +			if (id >= 0 && id < WM831X_MAX_DCDC)
> > > +				cell->swnode = pdata->dcdc_swnodes[id];
> > > +		}
> > > +	}
> >
> > I can't begin to tell you how much I hate this.
> >
> > Why are we duplicating massive static const structs just to add a S/W
> > node?  Is there no other way we can do this statically?
> 
> The software node itself is defined statically in the board file
> (crag_dcdc1_swnode in arch/arm/mach-s3c/mach-crag6410.c in patch 2/4),
> as it describes board-specific and PMIC-instance-specific wiring -
> specifically the host SoC GPIO wired to the PMIC's DVS pin (GPK(0) on
> Cragganmore 6410).
> 
> Because wm831x-core.c is a generic PMIC driver that can be instantiated
> on different boards or even multiple times on the same board (for
> example, Cragganmore 6410 has two WM831x PMIC instances, only one of
> which has a DVS GPIO wired to DCDC1), the shared static mfd_cell arrays
> in wm831x-core.c cannot point to a board's software node at compile
> time.
> 
> Note that local_cells is annotated with __free(kfree), so the duplicate
> array only lives for the duration of the mfd_add_devices() call (which
> makes its own per-device copy of each mfd_cell anyway) and is freed
> immediately before wm831x_add_devices() returns.
> 
> > Since pdata is being populated already, why not just pass that on to the
> > consuming child device (the regulator)?
> 
> The regulator driver (wm831x_buckv_dvs_init() in
> drivers/regulator/wm831x-dcdc.c) acquires the DVS GPIO using
> devm_gpiod_get(&pdev->dev, "dvs", ...). When converting the board file
> away from legacy gpiod_lookup_table to software nodes (to drop the
> fragile MFD device name matching and fix the GPIO chip label lookup),
> gpiolib resolves the "dvs-gpios" property against the consumer device's
> fwnode (&pdev->dev), so the software node needs to be attached to the
> wm831x-buckv platform device.
> 
> In v2 of this series I actually tried passing the software_node pointer
> through wm831x_buckv_pdata and attaching it to &pdev->dev inside the
> regulator driver's probe() [1]. However, attaching a software node to
> an already-registered platform device inside probe() is awkward and
> requires manual teardown in the child driver, whereas mfd-core already
> has built-in support for cell->swnode in mfd_add_device() (attaching
> the node via device_add_software_node() before platform_device_add(),
> and cleaning it up via device_remove_software_node() on error or
> removal). Populating cell->swnode lets mfd-core manage the software
> node lifecycle cleanly and keeps the regulator driver untouched.

Why do you need to attach the software_node to &pdev->dev at all?

All of the other DVS configuration (dvs_control_src, dvs_init_state) is
already passed to wm831x_buckv_dvs_init() via pdata.  If you put the
software node pointer in 'wm831x_buckv_pdata' (with the rest of the DVS
parameters, where it belongs), wm831x_buckv_dvs_init() can simply use
devm_fwnode_gpiod_get() to fetch it.

This then requires no device_add_software_node(), no manual tear-down in
the regulator driver and no "middle-man" changes to MFD at all.

> If you prefer not to kmemdup the full cell table, another option would
> be to split the buckv cells out of the main wm831x cell arrays and
> register them via a separate mfd_add_devices() call, though that seemed
> more intrusive across wm8310/wm8311/wm8312/wm8320. Please let me know
> what you would prefer here.

If there is a good reason why the above cannot be done in the regulator
driver (which I doubt), then yes, factoring the two identical
wm831x-buckv cells out of wm8310_devs/wm8311_devs/wm8312_devs/wm8320_devs
(just like touch_devs, rtc_devs and backlight_devs already are) is still
far better than kmemdup'ing the static const tables and matching cell
names with strcmp() in a loop.

> [1] https://lore.kernel.org/all/20260708-samsung-kp-v2-7-3c6ed4c9b3b6@gmail.com/

[2] Code talks, BS walks  =:-)

diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index 2264beef6dda..9657d74ca0c5 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -456,9 +456,21 @@ static struct pca953x_platform_data crag6410_pca_data = {
 	.irq_base	= -1,
 };
 
+static const struct property_entry crag_dcdc1_properties[] = {
+	PROPERTY_ENTRY_GPIO("dvs-gpios", SAMSUNG_GPIO_NODE('K'), 0, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct software_node crag_dcdc1_swnode = {
+	.name = "wm831x-buckv-dcdc1",
+	.properties = crag_dcdc1_properties,
+};
+
 /* VDDARM is controlled by DVS1 connected to GPK(0) */
 static struct wm831x_buckv_pdata vddarm_pdata = {
 	.dvs_control_src = 1,
+	.swnode = &crag_dcdc1_swnode,
 };
 
 static struct regulator_consumer_supply vddarm_consumers[] = {
@@ -656,24 +668,6 @@ static struct wm831x_pdata crag_pmic_pdata = {
 	.touch = &touch_pdata,
 };
 
-/*
- * VDDARM is eventually ending up as a regulator hanging on the MFD cell device
- * "wm831x-buckv.1" spawn from drivers/mfd/wm831x-core.c.
- *
- * From the note on the platform data we can see that this is clearly DVS1
- * and assigned as dcdc1 resource to the MFD core which sets .id of the cell
- * spawning the DVS1 platform device to 1, then the cell platform device
- * name is calculated from 10*instance + id resulting in the device name
- * "wm831x-buckv.11"
- */
-static struct gpiod_lookup_table crag_pmic_gpiod_table = {
-	.dev_id = "wm831x-buckv.11",
-	.table = {
-		GPIO_LOOKUP("GPIOK", 0, "dvs", GPIO_ACTIVE_HIGH),
-		{ },
-	},
-};
-
 static struct i2c_board_info i2c_devs0[] = {
 	{ I2C_BOARD_INFO("24c08", 0x50), },
 	{ I2C_BOARD_INFO("tca6408", 0x20),
@@ -931,7 +925,7 @@ static void __init crag6410_machine_init(void)
 	s3c_fb_set_platdata(&crag6410_lcd_pdata);
 	dwc2_hsotg_set_platdata(&crag6410_hsotg_pdata);
 
-	gpiod_add_lookup_table(&crag_pmic_gpiod_table);
+	software_node_register(&crag_dcdc1_swnode);
 	i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
 	gpiod_add_lookup_table(&crag_wm1250_ev1_gpiod_table);
 	i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 834d7c181971..957da3195974 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -16,6 +16,7 @@
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
 #include <linux/gpio/consumer.h>
+#include <linux/property.h>
 #include <linux/slab.h>
 
 #include <linux/mfd/wm831x/core.h>
@@ -330,6 +331,8 @@ static void wm831x_buckv_dvs_init(struct platform_device *pdev,
 				 struct wm831x_buckv_pdata *pdata)
 {
 	struct wm831x *wm831x = dcdc->wm831x;
+	struct fwnode_handle *fwnode;
+	enum gpiod_flags flags;
 	int ret;
 	u16 ctrl;
 
@@ -341,8 +344,15 @@ static void wm831x_buckv_dvs_init(struct platform_device *pdev,
 	*/
 	dcdc->dvs_gpio_state = pdata->dvs_init_state;
 
-	dcdc->dvs_gpiod = devm_gpiod_get(&pdev->dev, "dvs",
-			dcdc->dvs_gpio_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
+	flags = dcdc->dvs_gpio_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+	if (pdata->swnode) {
+		fwnode = software_node_fwnode(pdata->swnode);
+		dcdc->dvs_gpiod = devm_fwnode_gpiod_get(&pdev->dev, fwnode,
+						"dvs", flags, dcdc->name);
+	} else {
+		dcdc->dvs_gpiod = devm_gpiod_get(&pdev->dev, "dvs", flags);
+	}
+
 	if (IS_ERR(dcdc->dvs_gpiod)) {
 		dev_err(wm831x->dev, "Failed to get %s DVS GPIO: %ld\n",
 			dcdc->name, PTR_ERR(dcdc->dvs_gpiod));
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index 75aa94dadf1c..49501f155cc5 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -12,6 +12,7 @@
 
 struct wm831x;
 struct regulator_init_data;
+struct software_node;
 
 struct wm831x_backlight_pdata {
 	int isink;     /** ISINK to use, 1 or 2 */
@@ -50,6 +51,7 @@ struct wm831x_buckv_pdata {
 	int dvs_control_src; /** Hardware DVS source to use (1 or 2) */
 	int dvs_init_state;  /** DVS state to expect on startup */
 	int dvs_state_gpio;  /** CPU GPIO to use for monitoring status */
+	const struct software_node *swnode; /** Software node for DVS GPIOs */
 };
 
 /* Sources for status LED configuration.  Values are register values

-- 
Lee Jones

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Arnd Bergmann]

On Thu, Nov 5, 2026, at 09:53, Lee Jones wrote:
> On Wed, 04 Nov 2026, Dmitry Torokhov wrote:

>> On Wed, Nov 04, 2026 at 06:14:29PM +0000, Lee Jones wrote:
>> > On Sat, 24 Oct 2026, Dmitry Torokhov wrote:
>> > > +static int wm831x_add_devices(struct wm831x *wm831x, int wm831x_num,
>> > > +			      const struct mfd_cell *cells, int num_cells)
>> > > +{
>> > > +	struct wm831x_pdata *pdata = &wm831x->pdata;
>> > > +	int i;
>> > > +
>> > > +	struct mfd_cell *local_cells __free(kfree) =
>> > > +		kmemdup_array(cells, num_cells, sizeof(*cells), GFP_KERNEL);
>> > > +	if (!local_cells)
>> > > +		return -ENOMEM;
>> > > +
>> > > +	for (i = 0; i < num_cells; i++) {
>> > > +		struct mfd_cell *cell = &local_cells[i];
>> > > +
>> > > +		if (strcmp(cell->name, "wm831x-buckv") == 0) {
>> > > +			int id = cell->id - 1;
>> > > +
>> > > +			if (id >= 0 && id < WM831X_MAX_DCDC)
>> > > +				cell->swnode = pdata->dcdc_swnodes[id];
>> > > +		}
>> > > +	}
>> >
>> > I can't begin to tell you how much I hate this.
>> >
>> > Why are we duplicating massive static const structs just to add a S/W
>> > node?  Is there no other way we can do this statically?
>> 
>> The software node itself is defined statically in the board file
>> (crag_dcdc1_swnode in arch/arm/mach-s3c/mach-crag6410.c in patch 2/4),
>> as it describes board-specific and PMIC-instance-specific wiring -
>> specifically the host SoC GPIO wired to the PMIC's DVS pin (GPK(0) on
>> Cragganmore 6410).
>> 
>> Because wm831x-core.c is a generic PMIC driver that can be instantiated
>> on different boards or even multiple times on the same board (for
>> example, Cragganmore 6410 has two WM831x PMIC instances, only one of
>> which has a DVS GPIO wired to DCDC1), the shared static mfd_cell arrays
>> in wm831x-core.c cannot point to a board's software node at compile
>> time.

I think realistically this driver is not being shared across boards
and the documented but unused DT binding in
Documentation/devicetree/bindings/mfd/wm831x.txt does not describe
the gpio or actually match what the driver does.

I'm still not sure what your goal is with this series, but I feel
like there is no point in over-designing something that is not
going to matter anyway and that would be replaced with a different
DT binding if any new users should show up.

Why can't we just put the gpio property in the wm831x node itself
for simplicity?

>> In v2 of this series I actually tried passing the software_node pointer
>> through wm831x_buckv_pdata and attaching it to &pdev->dev inside the
>> regulator driver's probe() [1]. However, attaching a software node to
>> an already-registered platform device inside probe() is awkward and
>> requires manual teardown in the child driver, whereas mfd-core already
>> has built-in support for cell->swnode in mfd_add_device() (attaching
>> the node via device_add_software_node() before platform_device_add(),
>> and cleaning it up via device_remove_software_node() on error or
>> removal). Populating cell->swnode lets mfd-core manage the software
>> node lifecycle cleanly and keeps the regulator driver untouched.
>
> Why do you need to attach the software_node to &pdev->dev at all?
>
> All of the other DVS configuration (dvs_control_src, dvs_init_state) is
> already passed to wm831x_buckv_dvs_init() via pdata.  If you put the
> software node pointer in 'wm831x_buckv_pdata' (with the rest of the DVS
> parameters, where it belongs), wm831x_buckv_dvs_init() can simply use
> devm_fwnode_gpiod_get() to fetch it.
>
> This then requires no device_add_software_node(), no manual tear-down in
> the regulator driver and no "middle-man" changes to MFD at all.

I like this better than Dmitry's version, but it still feels like
adding complexity without a clear direction of how this should be
done for a complete driver.

> +
> +static const struct software_node crag_dcdc1_swnode = {
> +	.name = "wm831x-buckv-dcdc1",
> +	.properties = crag_dcdc1_properties,
> +};

specifically, this still adds a swnode with properties that don't
match either the documented binding or a potentially better one,
it's just another ad-hoc way of passing the gpio line.

> @@ -341,8 +344,15 @@ static void wm831x_buckv_dvs_init(struct 
> platform_device *pdev,
>  	*/
>  	dcdc->dvs_gpio_state = pdata->dvs_init_state;
> 
> -	dcdc->dvs_gpiod = devm_gpiod_get(&pdev->dev, "dvs",
> -			dcdc->dvs_gpio_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
> +	flags = dcdc->dvs_gpio_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> +	if (pdata->swnode) {
> +		fwnode = software_node_fwnode(pdata->swnode);
> +		dcdc->dvs_gpiod = devm_fwnode_gpiod_get(&pdev->dev, fwnode,
> +						"dvs", flags, dcdc->name);
> +	} else {
> +		dcdc->dvs_gpiod = devm_gpiod_get(&pdev->dev, "dvs", flags);
> +	}
> +

and this now has two ways of getting the gpio line, only one of which is
actually used, and neither of them matches the DT binding.

Instead of the piecemeal conversion, I'd prefer if we could either
do the entire wm831x driver properly or only do the absolute minimum:

- if there is a reason to expect any future user of the driver,
  extend the wlf,arizona.yaml binding to cover wm831x as well,
  replace all the platform data with swnode properties according
  to that binding and have the drivers use those.

- If crag6410 is the only thing that is ever going to use
  any of it, stop worrying about doing it cleanly. We can probably
  just stick a gpio_desc pointer in the platform_data and be
  done with removing the lookup table.

As far as I understand the situation, wm831x was used on the
reference board (Samsung smdk6410, removed in 2019) in addition
to crag6410 but never anywhere else upstream. The question
then is whether we'll ever see a DT conversion of crag6410.
This would require finding someone willing to actually do
the work, and coming up with a way to handle the autodetection
in mach-crag6410-module.c so the correct spi/i2c codec
child devices are probed.

      Arnd

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Charles Keepax]

On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 5, 2026, at 09:53, Lee Jones wrote:
> > On Wed, 04 Nov 2026, Dmitry Torokhov wrote:
> >> On Wed, Nov 04, 2026 at 06:14:29PM +0000, Lee Jones wrote:
> >> > On Sat, 24 Oct 2026, Dmitry Torokhov wrote:
> - if there is a reason to expect any future user of the driver,
>   extend the wlf,arizona.yaml binding to cover wm831x as well,
>   replace all the platform data with swnode properties according
>   to that binding and have the drivers use those.

I really don't like adding wm831x to the Arizona binding. Fine if
we want to create a new binding in a similar style but Arizona is
a binding for a specific series of audio parts, wm831x predates
those and is a pmic. Trying to combine them feels likely to cause
problems.

Thanks,
Charles

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Lee Jones]

On Thu, 05 Nov 2026, Charles Keepax wrote:

> On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:
> > On Thu, Nov 5, 2026, at 09:53, Lee Jones wrote:
> > > On Wed, 04 Nov 2026, Dmitry Torokhov wrote:
> > >> On Wed, Nov 04, 2026 at 06:14:29PM +0000, Lee Jones wrote:
> > >> > On Sat, 24 Oct 2026, Dmitry Torokhov wrote:
> > - if there is a reason to expect any future user of the driver,
> >   extend the wlf,arizona.yaml binding to cover wm831x as well,
> >   replace all the platform data with swnode properties according
> >   to that binding and have the drivers use those.
> 
> I really don't like adding wm831x to the Arizona binding. Fine if
> we want to create a new binding in a similar style but Arizona is
> a binding for a specific series of audio parts, wm831x predates
> those and is a pmic. Trying to combine them feels likely to cause
> problems.

I don't personally mind how this gets resolved, as long as we avoid the
monstrosity suggested in the original submission.  =:-]

-- 
Lee Jones

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Dmitry Torokhov]

On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:
> 
> As far as I understand the situation, wm831x was used on the
> reference board (Samsung smdk6410, removed in 2019) in addition
> to crag6410 but never anywhere else upstream. The question
> then is whether we'll ever see a DT conversion of crag6410.
> This would require finding someone willing to actually do
> the work, and coming up with a way to handle the autodetection
> in mach-crag6410-module.c so the correct spi/i2c codec
> child devices are probed.

So I guess the question then: do we need to keep this board at all? Or
it is time for it to go the way of the dodo? And then we could drop some
more drivers as well.

My goal for the series was to move along legacy gpio API conversions, as
well as move away from the GPIO lookup tables (ideally I want them gone
now that we have software nodes supporting describing GPIOs).

Thanks.

-- 
Dmitry

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Thu, Nov 05, 2026 at 09:12:38AM -0800, Dmitry Torokhov wrote:
> On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:

> > As far as I understand the situation, wm831x was used on the
> > reference board (Samsung smdk6410, removed in 2019) in addition
> > to crag6410 but never anywhere else upstream. The question
> > then is whether we'll ever see a DT conversion of crag6410.
> > This would require finding someone willing to actually do
> > the work, and coming up with a way to handle the autodetection
> > in mach-crag6410-module.c so the correct spi/i2c codec
> > child devices are probed.

> So I guess the question then: do we need to keep this board at all? Or
> it is time for it to go the way of the dodo? And then we could drop some
> more drivers as well.

I don't really have a great replacement for it.

> My goal for the series was to move along legacy gpio API conversions, as
> well as move away from the GPIO lookup tables (ideally I want them gone
> now that we have software nodes supporting describing GPIOs).

It is a bit hard to get enthused about software nodes :/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Arnd Bergmann]

On Thu, Nov 5, 2026, at 18:12, Dmitry Torokhov wrote:
> On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:
>> 
>> As far as I understand the situation, wm831x was used on the
>> reference board (Samsung smdk6410, removed in 2019) in addition
>> to crag6410 but never anywhere else upstream. The question
>> then is whether we'll ever see a DT conversion of crag6410.
>> This would require finding someone willing to actually do
>> the work, and coming up with a way to handle the autodetection
>> in mach-crag6410-module.c so the correct spi/i2c codec
>> child devices are probed.
>
> So I guess the question then: do we need to keep this board at all? Or
> it is time for it to go the way of the dodo? And then we could drop some
> more drivers as well.
>
> My goal for the series was to move along legacy gpio API conversions, as
> well as move away from the GPIO lookup tables (ideally I want them gone
> now that we have software nodes supporting describing GPIOs).

Mark Brown is using the board for testing eight Cirrus/Wolfson
audio codecs:

 - arizona and wm8994 have actual users with DT, but this is
   the board he has for testing with platform_data

 - wm0010, wm1250-ev1, wm5100, wm8996 and wm9081 have no other
   upstream users besides this board and no DT support, so arguably
   these are probably obsolete and could also be removed.

I assume Charles can comment on how important the testing still
is for the codec above, or if there is other hardware that could
be used for testing the arizona and wm8994 drivers in case the
other ones are in fact as obsolete as they appear.

       Arnd