[PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Josua Mayer]

Some Renesas SoC based boards mux SD and eMMC on a single sdio
controller, exposing user control by dip switch and software control by
gpio.

Purpose is to simplify development and provisioning by selecting boot
media at power-on, and again before starting linux.

Add binding and driver support for linking a (gpio) mux to renesas sdio
controller.

Introduce generic helper functions for getting managed and selected
mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v9:
- compile-tested on x86 with MULTIPLEXER=m/y/unset.
- fixed Kconfig changes so that CONFIG_MULTIPLEXER can be selected.
  through menuconfig / .config as intended.
- updated trailers
- document null return value for mux_control_get_optional.
- fix build error for CONFIG_MULTIPLEXER=m, found with x86_64
  allmodconfig: replaced ifdef ... with if IS_ENABLED(...).
  (Reported-by: Mark Brown <broonie@kernel.org>)
- Link to v8: https://lore.kernel.org/r/20260203-rz-sdio-mux-v8-0-024ea405863e@solid-run.com

Changes in v8:
- Add defensive null checks for all non-optional calls to internal
  mux_get function.
- Document NULL return value on applicable functions.
- Avoid IS_ERR_OR_NULL and ERR_PTR(0) to disarm smatch errors.
- Link to v7: https://lore.kernel.org/r/20260128-rz-sdio-mux-v7-0-92ebb6da0df8@solid-run.com

Changes in v7:
- picked up reviewed-tags
- fix Kconfig change to add the missing prompt for CONFIG_MULTIPLEXER,
  and enable it by default when COMPILE_TEST is set.
  (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
- fix another kernel build robot warning: undocumented C struct member
- Link to v6: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-0-38aa39527928@solid-run.com

Changes in v6:
- replaced /* with /** for devm_mux_state_state function description.
- collected review tags.
- fixed checkpatch warnings (space-before-tab, void-return).
  (Reported-by: Geert Uytterhoeven)
- fixed use-after-free in mux core mux_get function.
  (Reported-by: Geert Uytterhoeven)
- fix mux helper error path uninitialised return code variable.
  (Reported-by: kernel test robot <lkp@intel.com>)
- Link to v5: https://lore.kernel.org/r/20260118-rz-sdio-mux-v5-0-3c37e8872683@solid-run.com

Changes in v5:
- implemented automatic mux deselect for devm_*_selected.
  (Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>)
- because of semantic changes I dropped reviewed and acks from omap-i2c
  patch (Andreas Kemnade / Wolfram Sang).
- fix invalid return value in void function for mux helper stubs
  (Reported-by: kernel test robot <lkp@intel.com>)
- Link to v4: https://lore.kernel.org/r/20251229-rz-sdio-mux-v4-0-a023e55758fe@solid-run.com

Changes in v4:
- added MULTIPLEXER Kconfig help text.
- removed "select MULTIPLEXER" from renesas sdhi Kconfig, as it is
  not required for all devices using this driver.
- added stubs for all symbols exported by mux core.
  (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
- refactored mux core logic to silence ENOENT errors only on optional
  code paths, keeping error printing unchanged otherwise.
  (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
- picked up various reviewed- and acked-by tags
- Link to v3: https://lore.kernel.org/r/20251210-rz-sdio-mux-v3-0-ca628db56d60@solid-run.com

Changes in v3:
- updated omap-i2c and phy-can-transceiver to use new helpers.
- created generic helper functions for getting managed optional mux-state.
  (Reported-by: Rob Herring <robh@kernel.org>)
- picked up binding ack by Rob Herring.
- replaced use of "SDIO" with "SD/SDIO/eMMC" in binding document and
  commit descriptions.
  (Reported-by: Ulf Hansson <ulf.hansson@linaro.org>)
- Link to v2: https://lore.kernel.org/r/20251201-rz-sdio-mux-v2-0-bcb581b88dd7@solid-run.com

Changes in v2:
- dropped mux-controller node from dt binding example
  (Reported-by: Conor Dooley <conor@kernel.org>
   Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
- Link to v1: https://lore.kernel.org/r/20251128-rz-sdio-mux-v1-0-1ede318d160f@solid-run.com

---
Josua Mayer (7):
      phy: can-transceiver: rename temporary helper function to avoid conflict
      mux: Add helper functions for getting optional and selected mux-state
      mux: add help text for MULTIPLEXER config option
      phy: can-transceiver: drop temporary helper getting optional mux-state
      i2c: omap: switch to new generic helper for getting selected mux-state
      dt-bindings: mmc: renesas,sdhi: Add mux-states property
      mmc: host: renesas_sdhi_core: support selecting an optional mux

 .../devicetree/bindings/mmc/renesas,sdhi.yaml      |   6 +
 drivers/i2c/busses/i2c-omap.c                      |  24 +--
 drivers/mmc/host/renesas_sdhi_core.c               |   6 +
 drivers/mux/Kconfig                                |   9 +-
 drivers/mux/core.c                                 | 206 +++++++++++++++++----
 drivers/phy/phy-can-transceiver.c                  |  10 -
 include/linux/mux/consumer.h                       | 108 ++++++++++-
 7 files changed, 304 insertions(+), 65 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251128-rz-sdio-mux-acc5137f1618

Best regards,
-- 
Josua Mayer <josua@solid-run.com>

[PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Josua Mayer]

Rename the temporary devm_mux_state_get_optional function to avoid
conflict with upcoming implementation in multiplexer subsystem.

Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/phy/phy-can-transceiver.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 330356706ad7..81591d247128 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -128,7 +128,7 @@ MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
 
 /* Temporary wrapper until the multiplexer subsystem supports optional muxes */
 static inline struct mux_state *
-devm_mux_state_get_optional(struct device *dev, const char *mux_name)
+temp_devm_mux_state_get_optional(struct device *dev, const char *mux_name)
 {
 	if (!of_property_present(dev->of_node, "mux-states"))
 		return NULL;
@@ -183,7 +183,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 	priv->num_ch = num_ch;
 	platform_set_drvdata(pdev, priv);
 
-	mux_state = devm_mux_state_get_optional(dev, NULL);
+	mux_state = temp_devm_mux_state_get_optional(dev, NULL);
 	if (IS_ERR(mux_state))
 		return PTR_ERR(mux_state);
 

-- 
2.43.0

[PATCH v9 2/7] mux: Add helper functions for getting optional and selected mux-state

[Josua Mayer]

In-tree phy-can-transceiver driver has already implemented a local
version of devm_mux_state_get_optional.

The omap-i2c driver gets and selects an optional mux in its probe
function without using any helper.

Add new helper functions covering both aforementioned use-cases:

- mux_control_get_optional:
  Get a mux-control if specified in dt, return NULL otherwise.
- devm_mux_state_get_optional:
  Get a mux-state if specified in dt, return NULL otherwise.
- devm_mux_state_get_selected:
  Get and select a mux-state specified in dt, return error otherwise.
- devm_mux_state_get_optional_selected:
  Get and select a mux-state if specified in dt, return error or NULL.

Existing mux_get helper function is changed to take an extra argument
indicating whether the mux is optional.
In this case no error is printed, and NULL returned in case of ENOENT.

Calling code is adapted to handle NULL return case, and to pass optional
argument as required.

To support automatic deselect for _selected helper, a new structure is
created storing an exit pointer similar to clock core which is called on
release.

To facilitate code sharing between optional/mandatory/selected helpers,
a new internal helper function is added to handle quiet (optional) and
verbose (mandatory) errors, as well as storing the correct callback for
devm release: __devm_mux_state_get

Due to this structure devm_mux_state_get_*_selected can no longer print
a useful error message when select fails. Instead callers should print
errors where needed.

Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
property presence check") noted that "mux_get() always prints an error
message in case of an error, including when the property is not present,
confusing the user."

The first error message covers the case that a mux name is not matched
in dt. The second error message is based on of_parse_phandle_with_args
return value.

In optional case no error is printed and NULL is returned.
This ensures that the new helper functions will not confuse the user
either.

With the addition of optional helper functions it became clear that
drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
Add stubs for all symbols exported by mux core.

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/mux/core.c           | 206 ++++++++++++++++++++++++++++++++++++-------
 include/linux/mux/consumer.h | 108 ++++++++++++++++++++++-
 2 files changed, 279 insertions(+), 35 deletions(-)

diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index a3840fe0995f..b3ed3a094a09 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -46,6 +46,16 @@ static const struct class mux_class = {
 	.name = "mux",
 };
 
+/**
+ * struct devm_mux_state_state -	Tracks managed resources for mux-state objects.
+ * @mstate:				Pointer to a mux state.
+ * @exit:				An optional callback to execute before free.
+ */
+struct devm_mux_state_state {
+	struct mux_state *mstate;
+	int (*exit)(struct mux_state *mstate);
+};
+
 static DEFINE_IDA(mux_ida);
 
 static int __init mux_init(void)
@@ -516,17 +526,19 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
 	return dev ? to_mux_chip(dev) : NULL;
 }
 
-/*
+/**
  * mux_get() - Get the mux-control for a device.
  * @dev: The device that needs a mux-control.
  * @mux_name: The name identifying the mux-control.
  * @state: Pointer to where the requested state is returned, or NULL when
  *         the required multiplexer states are handled by other means.
+ * @optional: Whether to return NULL and silence errors when mux doesn't exist.
  *
- * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
+ * Return: Pointer to the mux-control on success, an ERR_PTR with a negative errno on error,
+ * or NULL if optional is true and mux doesn't exist.
  */
 static struct mux_control *mux_get(struct device *dev, const char *mux_name,
-				   unsigned int *state)
+				   unsigned int *state, bool optional)
 {
 	struct device_node *np = dev->of_node;
 	struct of_phandle_args args;
@@ -542,7 +554,9 @@ static struct mux_control *mux_get(struct device *dev, const char *mux_name,
 		else
 			index = of_property_match_string(np, "mux-control-names",
 							 mux_name);
-		if (index < 0) {
+		if (index < 0 && optional) {
+			return NULL;
+		} else if (index < 0) {
 			dev_err(dev, "mux controller '%s' not found\n",
 				mux_name);
 			return ERR_PTR(index);
@@ -558,8 +572,12 @@ static struct mux_control *mux_get(struct device *dev, const char *mux_name,
 						 "mux-controls", "#mux-control-cells",
 						 index, &args);
 	if (ret) {
+		if (optional && ret == -ENOENT)
+			return NULL;
+
 		dev_err(dev, "%pOF: failed to get mux-%s %s(%i)\n",
-			np, state ? "state" : "control", mux_name ?: "", index);
+			np, state ? "state" : "control",
+			mux_name ?: "", index);
 		return ERR_PTR(ret);
 	}
 
@@ -617,10 +635,29 @@ static struct mux_control *mux_get(struct device *dev, const char *mux_name,
  */
 struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
 {
-	return mux_get(dev, mux_name, NULL);
+	struct mux_control *mux = mux_get(dev, mux_name, NULL, false);
+
+	if (!mux)
+		return ERR_PTR(-ENOENT);
+
+	return mux;
 }
 EXPORT_SYMBOL_GPL(mux_control_get);
 
+/**
+ * mux_control_get_optional() - Get the optional mux-control for a device.
+ * @dev: The device that needs a mux-control.
+ * @mux_name: The name identifying the mux-control.
+ *
+ * Return: Pointer to the mux-state on success, an ERR_PTR with a negative errno on error,
+ * or NULL if mux doesn't exist.
+ */
+struct mux_control *mux_control_get_optional(struct device *dev, const char *mux_name)
+{
+	return mux_get(dev, mux_name, NULL, true);
+}
+EXPORT_SYMBOL_GPL(mux_control_get_optional);
+
 /**
  * mux_control_put() - Put away the mux-control for good.
  * @mux: The mux-control to put away.
@@ -657,10 +694,13 @@ struct mux_control *devm_mux_control_get(struct device *dev,
 	if (!ptr)
 		return ERR_PTR(-ENOMEM);
 
-	mux = mux_control_get(dev, mux_name);
+	mux = mux_get(dev, mux_name, NULL, false);
 	if (IS_ERR(mux)) {
 		devres_free(ptr);
 		return mux;
+	} else if (!mux) {
+		devres_free(ptr);
+		return ERR_PTR(-ENOENT);
 	}
 
 	*ptr = mux;
@@ -670,14 +710,16 @@ struct mux_control *devm_mux_control_get(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_mux_control_get);
 
-/*
+/**
  * mux_state_get() - Get the mux-state for a device.
  * @dev: The device that needs a mux-state.
  * @mux_name: The name identifying the mux-state.
+ * @optional: Whether to return NULL and silence errors when mux doesn't exist.
  *
- * Return: A pointer to the mux-state, or an ERR_PTR with a negative errno.
+ * Return: Pointer to the mux-state on success, an ERR_PTR with a negative errno on error,
+ * or NULL if optional is true and mux doesn't exist.
  */
-static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
+static struct mux_state *mux_state_get(struct device *dev, const char *mux_name, bool optional)
 {
 	struct mux_state *mstate;
 
@@ -685,12 +727,16 @@ static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
 	if (!mstate)
 		return ERR_PTR(-ENOMEM);
 
-	mstate->mux = mux_get(dev, mux_name, &mstate->state);
+	mstate->mux = mux_get(dev, mux_name, &mstate->state, optional);
 	if (IS_ERR(mstate->mux)) {
-		int err = PTR_ERR(mstate->mux);
-
 		kfree(mstate);
-		return ERR_PTR(err);
+		return ERR_CAST(mstate->mux);
+	} else if (optional && !mstate->mux) {
+		kfree(mstate);
+		return NULL;
+	} else if (!mstate->mux) {
+		kfree(mstate);
+		return ERR_PTR(-ENOENT);
 	}
 
 	return mstate;
@@ -710,9 +756,66 @@ static void mux_state_put(struct mux_state *mstate)
 
 static void devm_mux_state_release(struct device *dev, void *res)
 {
-	struct mux_state *mstate = *(struct mux_state **)res;
+	struct devm_mux_state_state *devm_state = res;
 
+	if (devm_state->exit)
+		devm_state->exit(devm_state->mstate);
+
+	mux_state_put(devm_state->mstate);
+}
+
+/**
+ * __devm_mux_state_get() - Get the optional mux-state for a device,
+ *			    with resource management.
+ * @dev: The device that needs a mux-state.
+ * @mux_name: The name identifying the mux-state.
+ * @optional: Whether to return NULL and silence errors when mux doesn't exist.
+ * @init: Optional function pointer for mux-state object initialisation.
+ * @exit: Optional function pointer for mux-state object cleanup on release.
+ *
+ * Return: Pointer to the mux-state on success, an ERR_PTR with a negative errno on error,
+ * or NULL if optional is true and mux doesn't exist.
+ */
+static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
+					      bool optional,
+					      int (*init)(struct mux_state *mstate),
+					      int (*exit)(struct mux_state *mstate))
+{
+	struct devm_mux_state_state *devm_state;
+	struct mux_state *mstate;
+	int ret;
+
+	mstate = mux_state_get(dev, mux_name, optional);
+	if (IS_ERR(mstate))
+		return ERR_CAST(mstate);
+	else if (optional && !mstate)
+		return NULL;
+	else if (!mstate)
+		return ERR_PTR(-ENOENT);
+
+	devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
+	if (!devm_state) {
+		ret = -ENOMEM;
+		goto err_devres_alloc;
+	}
+
+	if (init) {
+		ret = init(mstate);
+		if (ret)
+			goto err_mux_state_init;
+	}
+
+	devm_state->mstate = mstate;
+	devm_state->exit = exit;
+	devres_add(dev, devm_state);
+
+	return mstate;
+
+err_mux_state_init:
+	devres_free(devm_state);
+err_devres_alloc:
 	mux_state_put(mstate);
+	return ERR_PTR(ret);
 }
 
 /**
@@ -722,28 +825,69 @@ static void devm_mux_state_release(struct device *dev, void *res)
  * @mux_name: The name identifying the mux-control.
  *
  * Return: Pointer to the mux-state, or an ERR_PTR with a negative errno.
+ *
+ * The mux-state will automatically be freed on release.
  */
-struct mux_state *devm_mux_state_get(struct device *dev,
-				     const char *mux_name)
+struct mux_state *devm_mux_state_get(struct device *dev, const char *mux_name)
 {
-	struct mux_state **ptr, *mstate;
-
-	ptr = devres_alloc(devm_mux_state_release, sizeof(*ptr), GFP_KERNEL);
-	if (!ptr)
-		return ERR_PTR(-ENOMEM);
+	return __devm_mux_state_get(dev, mux_name, false, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(devm_mux_state_get);
 
-	mstate = mux_state_get(dev, mux_name);
-	if (IS_ERR(mstate)) {
-		devres_free(ptr);
-		return mstate;
-	}
+/**
+ * devm_mux_state_get_optional() - Get the optional mux-state for a device,
+ *				   with resource management.
+ * @dev: The device that needs a mux-state.
+ * @mux_name: The name identifying the mux-state.
+ *
+ * Return: Pointer to the mux-state on success, an ERR_PTR with a negative errno on error,
+ * or NULL if mux doesn't exist.
+ *
+ * The mux-state will automatically be freed on release.
+ */
+struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name)
+{
+	return __devm_mux_state_get(dev, mux_name, true, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(devm_mux_state_get_optional);
 
-	*ptr = mstate;
-	devres_add(dev, ptr);
+/**
+ * devm_mux_state_get_selected() - Get the mux-state for a device, with
+ *				   resource management.
+ * @dev: The device that needs a mux-state.
+ * @mux_name: The name identifying the mux-state.
+ *
+ * Return: Pointer to the mux-state, or an ERR_PTR with a negative errno.
+ *
+ * The returned mux-state (if valid) is already selected.
+ *
+ * The mux-state will automatically be deselected and freed on release.
+ */
+struct mux_state *devm_mux_state_get_selected(struct device *dev, const char *mux_name)
+{
+	return __devm_mux_state_get(dev, mux_name, false, mux_state_select, mux_state_deselect);
+}
+EXPORT_SYMBOL_GPL(devm_mux_state_get_selected);
 
-	return mstate;
+/**
+ * devm_mux_state_get_optional_selected() - Get the optional mux-state for
+ *					    a device, with resource management.
+ * @dev: The device that needs a mux-state.
+ * @mux_name: The name identifying the mux-state.
+ *
+ * Return: Pointer to the mux-state on success, an ERR_PTR with a negative errno on error,
+ * or NULL if mux doesn't exist.
+ *
+ * The returned mux-state (if valid) is already selected.
+ *
+ * The mux-state will automatically be deselected and freed on release.
+ */
+struct mux_state *devm_mux_state_get_optional_selected(struct device *dev,
+						       const char *mux_name)
+{
+	return __devm_mux_state_get(dev, mux_name, true, mux_state_select, mux_state_deselect);
 }
-EXPORT_SYMBOL_GPL(devm_mux_state_get);
+EXPORT_SYMBOL_GPL(devm_mux_state_get_optional_selected);
 
 /*
  * Using subsys_initcall instead of module_init here to try to ensure - for
diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
index 2e25c838f831..a961861a503b 100644
--- a/include/linux/mux/consumer.h
+++ b/include/linux/mux/consumer.h
@@ -16,6 +16,8 @@ struct device;
 struct mux_control;
 struct mux_state;
 
+#if IS_ENABLED(CONFIG_MULTIPLEXER)
+
 unsigned int mux_control_states(struct mux_control *mux);
 int __must_check mux_control_select_delay(struct mux_control *mux,
 					  unsigned int state,
@@ -54,11 +56,109 @@ int mux_control_deselect(struct mux_control *mux);
 int mux_state_deselect(struct mux_state *mstate);
 
 struct mux_control *mux_control_get(struct device *dev, const char *mux_name);
+struct mux_control *mux_control_get_optional(struct device *dev, const char *mux_name);
 void mux_control_put(struct mux_control *mux);
 
-struct mux_control *devm_mux_control_get(struct device *dev,
-					 const char *mux_name);
-struct mux_state *devm_mux_state_get(struct device *dev,
-				     const char *mux_name);
+struct mux_control *devm_mux_control_get(struct device *dev, const char *mux_name);
+struct mux_state *devm_mux_state_get(struct device *dev, const char *mux_name);
+struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
+struct mux_state *devm_mux_state_get_selected(struct device *dev, const char *mux_name);
+struct mux_state *devm_mux_state_get_optional_selected(struct device *dev, const char *mux_name);
+
+#else
+
+static inline unsigned int mux_control_states(struct mux_control *mux)
+{
+	return 0;
+}
+static inline int __must_check mux_control_select_delay(struct mux_control *mux,
+							unsigned int state, unsigned int delay_us)
+{
+	return -EOPNOTSUPP;
+}
+static inline int __must_check mux_state_select_delay(struct mux_state *mstate,
+						      unsigned int delay_us)
+{
+	return -EOPNOTSUPP;
+}
+static inline int __must_check mux_control_try_select_delay(struct mux_control *mux,
+							    unsigned int state,
+							    unsigned int delay_us)
+{
+	return -EOPNOTSUPP;
+}
+static inline int __must_check mux_state_try_select_delay(struct mux_state *mstate,
+							  unsigned int delay_us)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int __must_check mux_control_select(struct mux_control *mux,
+						  unsigned int state)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int __must_check mux_state_select(struct mux_state *mstate)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int __must_check mux_control_try_select(struct mux_control *mux,
+						      unsigned int state)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int __must_check mux_state_try_select(struct mux_state *mstate)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int mux_control_deselect(struct mux_control *mux)
+{
+	return -EOPNOTSUPP;
+}
+static inline int mux_state_deselect(struct mux_state *mstate)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+static inline struct mux_control *mux_control_get_optional(struct device *dev,
+							   const char *mux_name)
+{
+	return NULL;
+}
+static inline void mux_control_put(struct mux_control *mux) {}
+
+static inline struct mux_control *devm_mux_control_get(struct device *dev, const char *mux_name)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+static inline struct mux_state *devm_mux_state_get(struct device *dev, const char *mux_name)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+static inline struct mux_state *devm_mux_state_get_optional(struct device *dev,
+							    const char *mux_name)
+{
+	return NULL;
+}
+static inline struct mux_state *devm_mux_state_get_selected(struct device *dev,
+							    const char *mux_name)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+static inline struct mux_state *devm_mux_state_get_optional_selected(struct device *dev,
+								     const char *mux_name)
+{
+	return NULL;
+}
+
+#endif /* CONFIG_MULTIPLEXER */
 
 #endif /* _LINUX_MUX_CONSUMER_H */

-- 
2.43.0

[PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Josua Mayer]

Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
option thorugh the kernel configuration without explicit "select" driver
dependencies.

Select it by default when COMPILE_TEST is set for better coverage.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/mux/Kconfig | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index c68132e38138..4f7c6bb86fc6 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -4,7 +4,14 @@
 #
 
 config MULTIPLEXER
-	tristate
+	tristate "Generic Multiplexer Support"
+	default m if COMPILE_TEST
+	help
+	  This framework is designed to abstract multiplexer handling for
+	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
+	  controller chips.
+
+	  If unsure, say no.
 
 menu "Multiplexer drivers"
 	depends on MULTIPLEXER

-- 
2.43.0

[PATCH v9 4/7] phy: can-transceiver: drop temporary helper getting optional mux-state

[Josua Mayer]

Multiplexer subsystem has now added helpers for getting managed optional
mux-state.

Switch to the new devm_mux_state_get_optional helper.

This change is only compile-tested.

Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/phy/phy-can-transceiver.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 81591d247128..2b52e47f247a 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -126,16 +126,6 @@ static const struct of_device_id can_transceiver_phy_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
 
-/* Temporary wrapper until the multiplexer subsystem supports optional muxes */
-static inline struct mux_state *
-temp_devm_mux_state_get_optional(struct device *dev, const char *mux_name)
-{
-	if (!of_property_present(dev->of_node, "mux-states"))
-		return NULL;
-
-	return devm_mux_state_get(dev, mux_name);
-}
-
 static struct phy *can_transceiver_phy_xlate(struct device *dev,
 					     const struct of_phandle_args *args)
 {
@@ -183,7 +173,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 	priv->num_ch = num_ch;
 	platform_set_drvdata(pdev, priv);
 
-	mux_state = temp_devm_mux_state_get_optional(dev, NULL);
+	mux_state = devm_mux_state_get_optional(dev, NULL);
 	if (IS_ERR(mux_state))
 		return PTR_ERR(mux_state);
 

-- 
2.43.0

[PATCH v9 5/7] i2c: omap: switch to new generic helper for getting selected mux-state

[Josua Mayer]

Multiplexer subsystem has added generic helper functions for getting an
already selected mux-state object.

Replace existing logic in probe with the equivalent helper function.

There is a functional difference in that the mux is now automatically
deselected on release, replacing the explicit mux_state_deselect call.

This change is only compile-tested.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/i2c/busses/i2c-omap.c | 24 +++++-------------------
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d9f590f0c384..f02d294db42a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1453,27 +1453,16 @@ omap_i2c_probe(struct platform_device *pdev)
 				       (1000 * omap->speed / 8);
 	}
 
-	if (of_property_present(node, "mux-states")) {
-		struct mux_state *mux_state;
-
-		mux_state = devm_mux_state_get(&pdev->dev, NULL);
-		if (IS_ERR(mux_state)) {
-			r = PTR_ERR(mux_state);
-			dev_dbg(&pdev->dev, "failed to get I2C mux: %d\n", r);
-			goto err_put_pm;
-		}
-		omap->mux_state = mux_state;
-		r = mux_state_select(omap->mux_state);
-		if (r) {
-			dev_err(&pdev->dev, "failed to select I2C mux: %d\n", r);
-			goto err_put_pm;
-		}
+	omap->mux_state = devm_mux_state_get_optional_selected(&pdev->dev, NULL);
+	if (IS_ERR(omap->mux_state)) {
+		r = PTR_ERR(omap->mux_state);
+		goto err_put_pm;
 	}
 
 	/* reset ASAP, clearing any IRQs */
 	r = omap_i2c_init(omap);
 	if (r)
-		goto err_mux_state_deselect;
+		goto err_put_pm;
 
 	if (omap->rev < OMAP_I2C_OMAP1_REV_2)
 		r = devm_request_irq(&pdev->dev, omap->irq, omap_i2c_omap1_isr,
@@ -1515,9 +1504,6 @@ omap_i2c_probe(struct platform_device *pdev)
 
 err_unuse_clocks:
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
-err_mux_state_deselect:
-	if (omap->mux_state)
-		mux_state_deselect(omap->mux_state);
 err_put_pm:
 	pm_runtime_put_sync(omap->dev);
 err_disable_pm:

-- 
2.43.0

[PATCH v9 6/7] dt-bindings: mmc: renesas,sdhi: Add mux-states property

[Josua Mayer]

Add mux controller support for data or control lines that are muxed
between a host and multiple cards.

There are several devices supporting a choice of eMMC or SD on a single
board by both dip switch and gpio, e.g. Renesas RZ/G2L SMARC SoM and
SolidRun RZ/G2L SoM.

In-tree dts for the Renesas boards currently rely on preprocessor macros
and gpio hogs to describe the respective cards.

By adding mux-states property to sdhi controller description, boards can
correctly describe the mux that already exists in hardware - and drivers
can coordinate between mux selection and probing for cards.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
index c754ea71f51f..64fac0d11329 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -106,6 +106,11 @@ properties:
   iommus:
     maxItems: 1
 
+  mux-states:
+    description:
+      mux controller node to route the SD/SDIO/eMMC signals from SoC to cards.
+    maxItems: 1
+
   power-domains:
     maxItems: 1
 
@@ -275,6 +280,7 @@ examples:
         max-frequency = <195000000>;
         power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
         resets = <&cpg 314>;
+        mux-states = <&mux 0>;
     };
 
     sdhi1: mmc@ee120000 {

-- 
2.43.0

[PATCH v9 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux

[Josua Mayer]

Some hardware designs route data or control signals through a mux to
support multiple devices on a single sdhi controller.

In particular SolidRun RZ/G2L/G2LC/V2L System on Module use a mux for
switching between soldered eMMC and an optional microSD on a carrier
board, e.g. for development or provisioning.

SD/SDIO/eMMC are not well suited for runtime switching between different
cards, however boot-time selection is possible and useful - in
particular considering dt overlays.

Add support for an optional SD/SDIO/eMMC mux defined in dt, and select
it during probe.

Similar functionality already exists in other places, e.g. i2c-omap.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 drivers/mmc/host/renesas_sdhi_core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index 2a310a145785..f9ec78d699f4 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -26,6 +26,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/mmc/slot-gpio.h>
 #include <linux/module.h>
+#include <linux/mux/consumer.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/pinctrl/pinctrl-state.h>
 #include <linux/platform_data/tmio.h>
@@ -1062,6 +1063,7 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 	struct regulator_dev *rdev;
 	struct renesas_sdhi_dma *dma_priv;
 	struct device *dev = &pdev->dev;
+	struct mux_state *mux_state;
 	struct tmio_mmc_host *host;
 	struct renesas_sdhi *priv;
 	int num_irqs, irq, ret, i;
@@ -1116,6 +1118,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 						"state_uhs");
 	}
 
+	mux_state = devm_mux_state_get_optional_selected(&pdev->dev, NULL);
+	if (IS_ERR(mux_state))
+		return PTR_ERR(mux_state);
+
 	host = tmio_mmc_host_alloc(pdev, mmc_data);
 	if (IS_ERR(host))
 		return PTR_ERR(host);

-- 
2.43.0

Re: [PATCH v9 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux

[kernel test robot]

Hi Josua,

kernel test robot noticed the following build errors:

[auto build test ERROR on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]

url:    https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260208-234345
base:   8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link:    https://lore.kernel.org/r/20260208-rz-sdio-mux-v9-7-9a3be13c1280%40solid-run.com
patch subject: [PATCH v9 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
config: s390-randconfig-r054-20260209 (https://download.01.org/0day-ci/archive/20260209/202602091037.wNIGJdbh-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260209/202602091037.wNIGJdbh-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/202602091037.wNIGJdbh-lkp@intel.com/

All errors (new ones prefixed by >>):

   s390-linux-ld: drivers/mmc/host/renesas_sdhi_core.o: in function `renesas_sdhi_probe':
>> renesas_sdhi_core.c:(.text+0x1996): undefined reference to `devm_mux_state_get_optional_selected'

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

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Geert Uytterhoeven]

Hi Josua,

On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> option thorugh the kernel configuration without explicit "select" driver
> dependencies.
>
> Select it by default when COMPILE_TEST is set for better coverage.

Merely enabling COMPILE_TEST must not enable additional functionality.

> Signed-off-by: Josua Mayer <josua@solid-run.com>

Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Ulf Hansson]

On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
>
> Some Renesas SoC based boards mux SD and eMMC on a single sdio
> controller, exposing user control by dip switch and software control by
> gpio.
>
> Purpose is to simplify development and provisioning by selecting boot
> media at power-on, and again before starting linux.
>
> Add binding and driver support for linking a (gpio) mux to renesas sdio
> controller.
>
> Introduce generic helper functions for getting managed and selected
> mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v9:
> - compile-tested on x86 with MULTIPLEXER=m/y/unset.
> - fixed Kconfig changes so that CONFIG_MULTIPLEXER can be selected.
>   through menuconfig / .config as intended.
> - updated trailers
> - document null return value for mux_control_get_optional.
> - fix build error for CONFIG_MULTIPLEXER=m, found with x86_64
>   allmodconfig: replaced ifdef ... with if IS_ENABLED(...).
>   (Reported-by: Mark Brown <broonie@kernel.org>)
> - Link to v8: https://lore.kernel.org/r/20260203-rz-sdio-mux-v8-0-024ea405863e@solid-run.com

[...]

I have already applied for v8 and it's going to be in my pull-request
for v7.0 in a few hours.

Please send incremental fixes on top instead of a new version of the
series, then I can pick them as fixes for v7.0.

Kind regards
Uffe

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Josua Mayer]

On 09/02/2026 11:57, Ulf Hansson wrote:
> On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
>> Some Renesas SoC based boards mux SD and eMMC on a single sdio
>> controller, exposing user control by dip switch and software control by
>> gpio.
>>
>> Purpose is to simplify development and provisioning by selecting boot
>> media at power-on, and again before starting linux.
>>
>> Add binding and driver support for linking a (gpio) mux to renesas sdio
>> controller.
>>
>> Introduce generic helper functions for getting managed and selected
>> mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> Changes in v9:
>> - compile-tested on x86 with MULTIPLEXER=m/y/unset.
>> - fixed Kconfig changes so that CONFIG_MULTIPLEXER can be selected.
>>    through menuconfig / .config as intended.
>> - updated trailers
>> - document null return value for mux_control_get_optional.
>> - fix build error for CONFIG_MULTIPLEXER=m, found with x86_64
>>    allmodconfig: replaced ifdef ... with if IS_ENABLED(...).
>>    (Reported-by: Mark Brown <broonie@kernel.org>)
>> - Link to v8: https://lore.kernel.org/r/20260203-rz-sdio-mux-v8-0-024ea405863e@solid-run.com
> [...]
>
> I have already applied for v8 and it's going to be in my pull-request
> for v7.0 in a few hours.
>
> Please send incremental fixes on top instead of a new version of the
> series, then I can pick them as fixes for v7.0.

Okay, I'll send a minimal patch to fix the build error only in that case.

Thanks!

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Peter Rosin]

Hi!

2026-02-08 at 16:38, Josua Mayer wrote:
> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> option thorugh the kernel configuration without explicit "select" driver
> dependencies.
> 
> Select it by default when COMPILE_TEST is set for better coverage.
> 
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
>  drivers/mux/Kconfig | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index c68132e38138..4f7c6bb86fc6 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -4,7 +4,14 @@
>  #
>  
>  config MULTIPLEXER
> -	tristate
> +	tristate "Generic Multiplexer Support"
> +	default m if COMPILE_TEST
> +	help
> +	  This framework is designed to abstract multiplexer handling for
> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
> +	  controller chips.
> +
> +	  If unsure, say no.
>  
>  menu "Multiplexer drivers"
>  	depends on MULTIPLEXER
> 

I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
be selected when needed (and there are a dozen or so instances). The kbuild
docs has this on the subject:

	"In general use select only for non-visible symbols (no prompts
	 anywhere) and for symbols with no dependencies."

Cheers,
Peter

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Josua Mayer]

Hi Peter,

On 09/02/2026 13:10, Peter Rosin wrote:
> Hi!
>
> 2026-02-08 at 16:38, Josua Mayer wrote:
>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>> option thorugh the kernel configuration without explicit "select" driver
>> dependencies.
>>
>> Select it by default when COMPILE_TEST is set for better coverage.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>>   drivers/mux/Kconfig | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>> index c68132e38138..4f7c6bb86fc6 100644
>> --- a/drivers/mux/Kconfig
>> +++ b/drivers/mux/Kconfig
>> @@ -4,7 +4,14 @@
>>   #
>>   
>>   config MULTIPLEXER
>> -	tristate
>> +	tristate "Generic Multiplexer Support"
>> +	default m if COMPILE_TEST
>> +	help
>> +	  This framework is designed to abstract multiplexer handling for
>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>> +	  controller chips.
>> +
>> +	  If unsure, say no.
>>   
>>   menu "Multiplexer drivers"
>>   	depends on MULTIPLEXER
>>
> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
> be selected when needed (and there are a dozen or so instances). The kbuild
> docs has this on the subject:
>
> 	"In general use select only for non-visible symbols (no prompts
> 	 anywhere) and for symbols with no dependencies."
The patch description didn't make the decision logic clear,
and I plan to submit a standalone patch for this after v7.0-rc1.

Basically existing drivers using mux core used "select" to enable it,
even though the core can function standalone with device-tree.

Some of these users (phy-can-transceiver) function perfectly
perfectly fine without mux, and use it as an optional feature.

Likely drivers only used "select" to avoid writing helper functions,
prompt, kconfig description and stubs - which this patch-set added.

So I will argue that some existing users relying on "select" was wrong,
and that the mux framework is generally useful on its own.

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Peter Rosin]

Hi!

2026-02-09 at 12:31, Josua Mayer wrote:
> Hi Peter,
> 
> On 09/02/2026 13:10, Peter Rosin wrote:
>> Hi!
>>
>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>> option thorugh the kernel configuration without explicit "select" driver
>>> dependencies.
>>>
>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>> ---
>>>   drivers/mux/Kconfig | 9 ++++++++-
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index c68132e38138..4f7c6bb86fc6 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -4,7 +4,14 @@
>>>   #
>>>   
>>>   config MULTIPLEXER
>>> -	tristate
>>> +	tristate "Generic Multiplexer Support"
>>> +	default m if COMPILE_TEST
>>> +	help
>>> +	  This framework is designed to abstract multiplexer handling for
>>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>> +	  controller chips.
>>> +
>>> +	  If unsure, say no.
>>>   
>>>   menu "Multiplexer drivers"
>>>   	depends on MULTIPLEXER
>>>
>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>> be selected when needed (and there are a dozen or so instances). The kbuild
>> docs has this on the subject:
>>
>> 	"In general use select only for non-visible symbols (no prompts
>> 	 anywhere) and for symbols with no dependencies."
> The patch description didn't make the decision logic clear,
> and I plan to submit a standalone patch for this after v7.0-rc1.
> 
> Basically existing drivers using mux core used "select" to enable it,
> even though the core can function standalone with device-tree.
> 
> Some of these users (phy-can-transceiver) function perfectly
> perfectly fine without mux, and use it as an optional feature.
> 
> Likely drivers only used "select" to avoid writing helper functions,
> prompt, kconfig description and stubs - which this patch-set added.
> 
> So I will argue that some existing users relying on "select" was wrong,
> and that the mux framework is generally useful on its own.

When I wrote the mux sub-system it was very much intentional and by
design that drivers needing a mux should select MULTIPLEXER, and that
MULTIPLEXER should not be a visible symbol.

You say that it could be useful to have it visible, which is all fine
I suppose. But, you fail to address that quote from the kbuild docs.
Why is it OK to have the preexisting drivers select a visible symbol,
when the kbuild documentation states that it should not be done that
way?

Cheers,
Peter

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Josua Mayer]

On 09/02/2026 13:43, Peter Rosin wrote:
> Hi!
>
> 2026-02-09 at 12:31, Josua Mayer wrote:
>> Hi Peter,
>>
>> On 09/02/2026 13:10, Peter Rosin wrote:
>>> Hi!
>>>
>>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>> option thorugh the kernel configuration without explicit "select" driver
>>>> dependencies.
>>>>
>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>
>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>> ---
>>>>    drivers/mux/Kconfig | 9 ++++++++-
>>>>    1 file changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>> index c68132e38138..4f7c6bb86fc6 100644
>>>> --- a/drivers/mux/Kconfig
>>>> +++ b/drivers/mux/Kconfig
>>>> @@ -4,7 +4,14 @@
>>>>    #
>>>>    
>>>>    config MULTIPLEXER
>>>> -	tristate
>>>> +	tristate "Generic Multiplexer Support"
>>>> +	default m if COMPILE_TEST
>>>> +	help
>>>> +	  This framework is designed to abstract multiplexer handling for
>>>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>>> +	  controller chips.
>>>> +
>>>> +	  If unsure, say no.
>>>>    
>>>>    menu "Multiplexer drivers"
>>>>    	depends on MULTIPLEXER
>>>>
>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>>> be selected when needed (and there are a dozen or so instances). The kbuild
>>> docs has this on the subject:
>>>
>>> 	"In general use select only for non-visible symbols (no prompts
>>> 	 anywhere) and for symbols with no dependencies."
>> The patch description didn't make the decision logic clear,
>> and I plan to submit a standalone patch for this after v7.0-rc1.
>>
>> Basically existing drivers using mux core used "select" to enable it,
>> even though the core can function standalone with device-tree.
>>
>> Some of these users (phy-can-transceiver) function perfectly
>> perfectly fine without mux, and use it as an optional feature.
>>
>> Likely drivers only used "select" to avoid writing helper functions,
>> prompt, kconfig description and stubs - which this patch-set added.
>>
>> So I will argue that some existing users relying on "select" was wrong,
>> and that the mux framework is generally useful on its own.
> When I wrote the mux sub-system it was very much intentional and by
> design that drivers needing a mux should select MULTIPLEXER, and that
> MULTIPLEXER should not be a visible symbol.
Need is a strong word here, and doesn't address the optional case.
> You say that it could be useful to have it visible, which is all fine
> I suppose. But, you fail to address that quote from the kbuild docs.
> Why is it OK to have the preexisting drivers select a visible symbol,
> when the kbuild documentation states that it should not be done that
> way?

It might have been okay for a transitional period.
My original patch-set had already exploded due to the request to
introduce general purpose devm_*_optional_* helpers,
and the fact phy-can-transceiver already had a local version of the same.

So perhaps if I will submit a patch-set changing to visible symbol,
I shall also change the few drivers that are now using "select"?

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Peter Rosin]

Hi!

2026-02-09 at 13:07, Josua Mayer wrote:
> On 09/02/2026 13:43, Peter Rosin wrote:
>> Hi!
>>
>> 2026-02-09 at 12:31, Josua Mayer wrote:
>>> Hi Peter,
>>>
>>> On 09/02/2026 13:10, Peter Rosin wrote:
>>>> Hi!
>>>>
>>>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>>> option thorugh the kernel configuration without explicit "select" driver
>>>>> dependencies.
>>>>>
>>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>>
>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>> ---
>>>>>    drivers/mux/Kconfig | 9 ++++++++-
>>>>>    1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>> index c68132e38138..4f7c6bb86fc6 100644
>>>>> --- a/drivers/mux/Kconfig
>>>>> +++ b/drivers/mux/Kconfig
>>>>> @@ -4,7 +4,14 @@
>>>>>    #
>>>>>    
>>>>>    config MULTIPLEXER
>>>>> -	tristate
>>>>> +	tristate "Generic Multiplexer Support"
>>>>> +	default m if COMPILE_TEST
>>>>> +	help
>>>>> +	  This framework is designed to abstract multiplexer handling for
>>>>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>>>> +	  controller chips.
>>>>> +
>>>>> +	  If unsure, say no.
>>>>>    
>>>>>    menu "Multiplexer drivers"
>>>>>    	depends on MULTIPLEXER
>>>>>
>>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>>>> be selected when needed (and there are a dozen or so instances). The kbuild
>>>> docs has this on the subject:
>>>>
>>>> 	"In general use select only for non-visible symbols (no prompts
>>>> 	 anywhere) and for symbols with no dependencies."
>>> The patch description didn't make the decision logic clear,
>>> and I plan to submit a standalone patch for this after v7.0-rc1.
>>>
>>> Basically existing drivers using mux core used "select" to enable it,
>>> even though the core can function standalone with device-tree.
>>>
>>> Some of these users (phy-can-transceiver) function perfectly
>>> perfectly fine without mux, and use it as an optional feature.
>>>
>>> Likely drivers only used "select" to avoid writing helper functions,
>>> prompt, kconfig description and stubs - which this patch-set added.
>>>
>>> So I will argue that some existing users relying on "select" was wrong,
>>> and that the mux framework is generally useful on its own.
>> When I wrote the mux sub-system it was very much intentional and by
>> design that drivers needing a mux should select MULTIPLEXER, and that
>> MULTIPLEXER should not be a visible symbol.
> Need is a strong word here, and doesn't address the optional case.

"Need" was the correct verb up until you needed the subsystem to be
optional. If you need the mux subsystem to be optional, you need to
do it in a way that does not introduce headaches.

>> You say that it could be useful to have it visible, which is all fine
>> I suppose. But, you fail to address that quote from the kbuild docs.
>> Why is it OK to have the preexisting drivers select a visible symbol,
>> when the kbuild documentation states that it should not be done that
>> way?
> 
> It might have been okay for a transitional period.

What would be ok for a transitional period? Introducing potentially
problematic kbuild dependencies? I'd rather not...

> My original patch-set had already exploded due to the request to
> introduce general purpose devm_*_optional_* helpers,
> and the fact phy-can-transceiver already had a local version of the same.
> 
> So perhaps if I will submit a patch-set changing to visible symbol,
> I shall also change the few drivers that are now using "select"?

I think it would be simpler to introduce some new visible symbol
that triggers select MULTIPLEXER, making it perfectly fine to
leave all the existing select MULTIPLEXER users as-is?

Cheers,
Peter

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Peter Rosin]

2026-02-09 at 10:57, Ulf Hansson wrote:
> I have already applied for v8 and it's going to be in my pull-request
> for v7.0 in a few hours.
> 
> Please send incremental fixes on top instead of a new version of the
> series, then I can pick them as fixes for v7.0.

Hi!

Sorry for being late with this, but as the mux maintainer I'm not
fond of

028ec00381f5 ("mux: add help text for MULTIPLEXER config option"

and would not like to see it in rc1. Can you prevent that some way?

Cheers,
Peter

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Ulf Hansson]

On Mon, 9 Feb 2026 at 14:16, Peter Rosin <peda@axentia.se> wrote:
>
> 2026-02-09 at 10:57, Ulf Hansson wrote:
> > I have already applied for v8 and it's going to be in my pull-request
> > for v7.0 in a few hours.
> >
> > Please send incremental fixes on top instead of a new version of the
> > series, then I can pick them as fixes for v7.0.
>
> Hi!
>
> Sorry for being late with this, but as the mux maintainer I'm not
> fond of
>
> 028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
>
> and would not like to see it in rc1. Can you prevent that some way?

Sorry, but my pull-request and branch was already prepared.

Please send an incremental patch on top then I can pick it up as a fix
for 7.0-rc1. Unless you want to manage this yourself via your tree.

Kind regards
Uffe

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Peter Rosin]

Hi!

2026-02-09 at 14:39, Ulf Hansson wrote:
> On Mon, 9 Feb 2026 at 14:16, Peter Rosin <peda@axentia.se> wrote:
>>
>> 2026-02-09 at 10:57, Ulf Hansson wrote:
>>> I have already applied for v8 and it's going to be in my pull-request
>>> for v7.0 in a few hours.
>>>
>>> Please send incremental fixes on top instead of a new version of the
>>> series, then I can pick them as fixes for v7.0.
>>
>> Hi!
>>
>> Sorry for being late with this, but as the mux maintainer I'm not
>> fond of
>>
>> 028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
>>
>> and would not like to see it in rc1. Can you prevent that some way?
> 
> Sorry, but my pull-request and branch was already prepared.
> 
> Please send an incremental patch on top then I can pick it up as a fix
> for 7.0-rc1. Unless you want to manage this yourself via your tree.

That unfortunate. The patch series has not yet made it to the next
tree since it has not seen any updates the last few days. What testing
has these patches received?

Cheers,
Peter

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Ulf Hansson]

On Mon, 9 Feb 2026 at 14:50, Peter Rosin <peda@axentia.se> wrote:
>
> Hi!
>
> 2026-02-09 at 14:39, Ulf Hansson wrote:
> > On Mon, 9 Feb 2026 at 14:16, Peter Rosin <peda@axentia.se> wrote:
> >>
> >> 2026-02-09 at 10:57, Ulf Hansson wrote:
> >>> I have already applied for v8 and it's going to be in my pull-request
> >>> for v7.0 in a few hours.
> >>>
> >>> Please send incremental fixes on top instead of a new version of the
> >>> series, then I can pick them as fixes for v7.0.
> >>
> >> Hi!
> >>
> >> Sorry for being late with this, but as the mux maintainer I'm not
> >> fond of
> >>
> >> 028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
> >>
> >> and would not like to see it in rc1. Can you prevent that some way?
> >
> > Sorry, but my pull-request and branch was already prepared.
> >
> > Please send an incremental patch on top then I can pick it up as a fix
> > for 7.0-rc1. Unless you want to manage this yourself via your tree.
>
> That unfortunate. The patch series has not yet made it to the next
> tree since it has not seen any updates the last few days. What testing
> has these patches received?

The patches didn't make it to next, for some reason. I queued them up
last week on the 4th Feb, definitely a bit of a stretch to pick them,
I admit that, but I trust Josua to help with any kind of problem to
show up.

In regards to additional tests and reviews, lots of people have been
helping out with this and we have also received patchbot reports that
Josua fixed too, along the road. Moreover, the first version of the
series was posted already in November last year.

As I said, let's fix any of the problems on top, it should be that hard, right?

Kind regards
Uffe

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Ulf Hansson]

On Mon, 9 Feb 2026 at 17:48, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Mon, 9 Feb 2026 at 14:50, Peter Rosin <peda@axentia.se> wrote:
> >
> > Hi!
> >
> > 2026-02-09 at 14:39, Ulf Hansson wrote:
> > > On Mon, 9 Feb 2026 at 14:16, Peter Rosin <peda@axentia.se> wrote:
> > >>
> > >> 2026-02-09 at 10:57, Ulf Hansson wrote:
> > >>> I have already applied for v8 and it's going to be in my pull-request
> > >>> for v7.0 in a few hours.
> > >>>
> > >>> Please send incremental fixes on top instead of a new version of the
> > >>> series, then I can pick them as fixes for v7.0.
> > >>
> > >> Hi!
> > >>
> > >> Sorry for being late with this, but as the mux maintainer I'm not
> > >> fond of
> > >>
> > >> 028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
> > >>
> > >> and would not like to see it in rc1. Can you prevent that some way?
> > >
> > > Sorry, but my pull-request and branch was already prepared.
> > >
> > > Please send an incremental patch on top then I can pick it up as a fix
> > > for 7.0-rc1. Unless you want to manage this yourself via your tree.
> >
> > That unfortunate. The patch series has not yet made it to the next
> > tree since it has not seen any updates the last few days. What testing
> > has these patches received?
>
> The patches didn't make it to next, for some reason. I queued them up
> last week on the 4th Feb, definitely a bit of a stretch to pick them,
> I admit that, but I trust Josua to help with any kind of problem to
> show up.
>
> In regards to additional tests and reviews, lots of people have been
> helping out with this and we have also received patchbot reports that
> Josua fixed too, along the road. Moreover, the first version of the
> series was posted already in November last year.
>
> As I said, let's fix any of the problems on top, it should be that hard, right?

/s/should/should not

Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux

[Josua Mayer]

On 2/9/26 18:49, Ulf Hansson wrote:
> On Mon, 9 Feb 2026 at 17:48, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On Mon, 9 Feb 2026 at 14:50, Peter Rosin <peda@axentia.se> wrote:
>>> Hi!
>>>
>>> 2026-02-09 at 14:39, Ulf Hansson wrote:
>>>> On Mon, 9 Feb 2026 at 14:16, Peter Rosin <peda@axentia.se> wrote:
>>>>> 2026-02-09 at 10:57, Ulf Hansson wrote:
>>>>>> I have already applied for v8 and it's going to be in my pull-request
>>>>>> for v7.0 in a few hours.
>>>>>>
>>>>>> Please send incremental fixes on top instead of a new version of the
>>>>>> series, then I can pick them as fixes for v7.0.
>>>>> Hi!
>>>>>
>>>>> Sorry for being late with this, but as the mux maintainer I'm not
>>>>> fond of
>>>>>
>>>>> 028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
>>>>>
>>>>> and would not like to see it in rc1. Can you prevent that some way?
>>>> Sorry, but my pull-request and branch was already prepared.
>>>>
>>>> Please send an incremental patch on top then I can pick it up as a fix
>>>> for 7.0-rc1. Unless you want to manage this yourself via your tree.
>>> That unfortunate. The patch series has not yet made it to the next
>>> tree since it has not seen any updates the last few days. What testing
>>> has these patches received?
>> The patches didn't make it to next, for some reason. I queued them up
>> last week on the 4th Feb, definitely a bit of a stretch to pick them,
>> I admit that, but I trust Josua to help with any kind of problem to
>> show up.
>>
>> In regards to additional tests and reviews, lots of people have been
>> helping out with this and we have also received patchbot reports that
>> Josua fixed too, along the road. Moreover, the first version of the
>> series was posted already in November last year.
>>
>> As I said, let's fix any of the problems on top, it should be that hard, right?
> /s/should/should not

I sent the compile fix with b4, but it reduced the lists and people CC'd,
I wasn't sure if I should be CCing mmc list again:

https://lore.kernel.org/r/20260209-rz-sdio-mux-fix-v1-1-8ea0da565b14@solid-run.com

Any other changes I proposed with v9 can be re-proposed
and discussed in a future patch-set.

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Josua Mayer]

On 2/9/26 15:08, Peter Rosin wrote:
> Hi!
>
> 2026-02-09 at 13:07, Josua Mayer wrote:
>> On 09/02/2026 13:43, Peter Rosin wrote:
>>> Hi!
>>>
>>> 2026-02-09 at 12:31, Josua Mayer wrote:
>>>> Hi Peter,
>>>>
>>>> On 09/02/2026 13:10, Peter Rosin wrote:
>>>>> Hi!
>>>>>
>>>>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>>>> option thorugh the kernel configuration without explicit "select" driver
>>>>>> dependencies.
>>>>>>
>>>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>>>
>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>> ---
>>>>>>     drivers/mux/Kconfig | 9 ++++++++-
>>>>>>     1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>>> index c68132e38138..4f7c6bb86fc6 100644
>>>>>> --- a/drivers/mux/Kconfig
>>>>>> +++ b/drivers/mux/Kconfig
>>>>>> @@ -4,7 +4,14 @@
>>>>>>     #
>>>>>>     
>>>>>>     config MULTIPLEXER
>>>>>> -	tristate
>>>>>> +	tristate "Generic Multiplexer Support"
>>>>>> +	default m if COMPILE_TEST
>>>>>> +	help
>>>>>> +	  This framework is designed to abstract multiplexer handling for
>>>>>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>>>>> +	  controller chips.
>>>>>> +
>>>>>> +	  If unsure, say no.
>>>>>>     
>>>>>>     menu "Multiplexer drivers"
>>>>>>     	depends on MULTIPLEXER
>>>>>>
>>>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>>>>> be selected when needed (and there are a dozen or so instances). The kbuild
>>>>> docs has this on the subject:
>>>>>
>>>>> 	"In general use select only for non-visible symbols (no prompts
>>>>> 	 anywhere) and for symbols with no dependencies."
>>>> The patch description didn't make the decision logic clear,
>>>> and I plan to submit a standalone patch for this after v7.0-rc1.
>>>>
>>>> Basically existing drivers using mux core used "select" to enable it,
>>>> even though the core can function standalone with device-tree.
>>>>
>>>> Some of these users (phy-can-transceiver) function perfectly
>>>> perfectly fine without mux, and use it as an optional feature.
>>>>
>>>> Likely drivers only used "select" to avoid writing helper functions,
>>>> prompt, kconfig description and stubs - which this patch-set added.
>>>>
>>>> So I will argue that some existing users relying on "select" was wrong,
>>>> and that the mux framework is generally useful on its own.
>>> When I wrote the mux sub-system it was very much intentional and by
>>> design that drivers needing a mux should select MULTIPLEXER, and that
>>> MULTIPLEXER should not be a visible symbol.
>> Need is a strong word here, and doesn't address the optional case.
> "Need" was the correct verb up until you needed the subsystem to be
> optional. If you need the mux subsystem to be optional, you need to
> do it in a way that does not introduce headaches.
>
>>> You say that it could be useful to have it visible, which is all fine
>>> I suppose. But, you fail to address that quote from the kbuild docs.
>>> Why is it OK to have the preexisting drivers select a visible symbol,
>>> when the kbuild documentation states that it should not be done that
>>> way?
>> It might have been okay for a transitional period.
> What would be ok for a transitional period? Introducing potentially
> problematic kbuild dependencies? I'd rather not...
>
>> My original patch-set had already exploded due to the request to
>> introduce general purpose devm_*_optional_* helpers,
>> and the fact phy-can-transceiver already had a local version of the same.
>>
>> So perhaps if I will submit a patch-set changing to visible symbol,
>> I shall also change the few drivers that are now using "select"?
> I think it would be simpler to introduce some new visible symbol
> that triggers select MULTIPLEXER,

Considering the large number of existing users, I tend to agree here:

drivers/gpu/drm/bridge/Kconfig: select MULTIPLEXER
drivers/i2c/busses/Kconfig:     select MULTIPLEXER
drivers/i2c/muxes/Kconfig:      select MULTIPLEXER
drivers/iio/multiplexer/Kconfig:        select MULTIPLEXER
drivers/media/platform/Kconfig: select MULTIPLEXER
drivers/mtd/hyperbus/Kconfig:   select MULTIPLEXER
drivers/mtd/maps/Kconfig:       select MULTIPLEXER
drivers/net/mdio/Kconfig:       select MULTIPLEXER
drivers/phy/ti/Kconfig: select MULTIPLEXER
drivers/phy/ti/Kconfig: select MULTIPLEXER
drivers/phy/Kconfig:    select MULTIPLEXER
drivers/spi/Kconfig:    select MULTIPLEXER
drivers/spi/Kconfig:    select MULTIPLEXER
sound/soc/codecs/Kconfig:       select MULTIPLEXER

> making it perfectly fine to
> leave all the existing select MULTIPLEXER users as-is?
However I think each of them should be reviewed as to whether
their use of mux is mandatory or optional (phy-can-transceiver).

A "depends" relationship might be clearer long-term,
and perhaps all users should be converted eventually.

It is rather frustrating that the consideration to make mux framework
an optional dependency to drivers, rather than mandatory,
came after so many uses were already established.

Any suggestion how to name the new config symbol that can have
a visible prompt?

- regards
Josua Mayer

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Geert Uytterhoeven]

Hi Peter,

On Mon, 9 Feb 2026 at 14:09, Peter Rosin <peda@axentia.se> wrote:
> 2026-02-09 at 13:07, Josua Mayer wrote:
> > On 09/02/2026 13:43, Peter Rosin wrote:
> >> 2026-02-09 at 12:31, Josua Mayer wrote:
> >>> On 09/02/2026 13:10, Peter Rosin wrote:
> >>>> 2026-02-08 at 16:38, Josua Mayer wrote:
> >>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> >>>>> option thorugh the kernel configuration without explicit "select" driver
> >>>>> dependencies.
> >>>>>
> >>>>> Select it by default when COMPILE_TEST is set for better coverage.
> >>>>>
> >>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
> >>>>> ---
> >>>>>    drivers/mux/Kconfig | 9 ++++++++-
> >>>>>    1 file changed, 8 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> >>>>> index c68132e38138..4f7c6bb86fc6 100644
> >>>>> --- a/drivers/mux/Kconfig
> >>>>> +++ b/drivers/mux/Kconfig
> >>>>> @@ -4,7 +4,14 @@
> >>>>>    #
> >>>>>
> >>>>>    config MULTIPLEXER
> >>>>> - tristate
> >>>>> + tristate "Generic Multiplexer Support"
> >>>>> + default m if COMPILE_TEST
> >>>>> + help
> >>>>> +   This framework is designed to abstract multiplexer handling for
> >>>>> +   devices via various GPIO-, MMIO/Regmap or specific multiplexer
> >>>>> +   controller chips.
> >>>>> +
> >>>>> +   If unsure, say no.
> >>>>>
> >>>>>    menu "Multiplexer drivers"
> >>>>>           depends on MULTIPLEXER
> >>>>>
> >>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
> >>>> be selected when needed (and there are a dozen or so instances). The kbuild
> >>>> docs has this on the subject:
> >>>>
> >>>>    "In general use select only for non-visible symbols (no prompts
> >>>>     anywhere) and for symbols with no dependencies."
> >>> The patch description didn't make the decision logic clear,
> >>> and I plan to submit a standalone patch for this after v7.0-rc1.
> >>>
> >>> Basically existing drivers using mux core used "select" to enable it,
> >>> even though the core can function standalone with device-tree.
> >>>
> >>> Some of these users (phy-can-transceiver) function perfectly
> >>> perfectly fine without mux, and use it as an optional feature.
> >>>
> >>> Likely drivers only used "select" to avoid writing helper functions,
> >>> prompt, kconfig description and stubs - which this patch-set added.
> >>>
> >>> So I will argue that some existing users relying on "select" was wrong,
> >>> and that the mux framework is generally useful on its own.
> >> When I wrote the mux sub-system it was very much intentional and by
> >> design that drivers needing a mux should select MULTIPLEXER, and that
> >> MULTIPLEXER should not be a visible symbol.
> > Need is a strong word here, and doesn't address the optional case.
>
> "Need" was the correct verb up until you needed the subsystem to be
> optional. If you need the mux subsystem to be optional, you need to
> do it in a way that does not introduce headaches.

In the other thread, Josua pointed out that there are already several
drivers that cannot be enabled if MULTIPLEXER is not selected by
something else:

drivers/mux/Kconfig:

    menu "Multiplexer drivers"
            depends on MULTIPLEXER

    config MUX_ADG792A
            tristate "Analog Devices ADG792A/ADG792G Multiplexers"
            depends on I2C

    config MUX_ADGS1408
            tristate "Analog Devices ADGS1408/ADGS1409 Multiplexers"
            depends on SPI

    config MUX_GPIO
            tristate "GPIO-controlled Multiplexer"
            depends on GPIOLIB || COMPILE_TEST

    config MUX_MMIO
            tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
            depends on OF

While MUX_MMIO is selected by some/all(?) symbols that need it,
the other three are not.  Are these three really dependent on another
symbol selecting MULTIPLEXER?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Peter Rosin]

Hi!

2026-02-09 at 21:02, Josua Mayer wrote:
> Any suggestion how to name the new config symbol that can have
> a visible prompt?

MULTIPLEXER_CORE perhaps? Or maybe just MUX_CORE?

Cheers,
Peter

Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

[Peter Rosin]

Hi!

2026-02-10 at 08:50, Geert Uytterhoeven wrote:
> In the other thread, Josua pointed out that there are already several
> drivers that cannot be enabled if MULTIPLEXER is not selected by
> something else:
> 
> drivers/mux/Kconfig:
> 
>     menu "Multiplexer drivers"
>             depends on MULTIPLEXER
> 
>     config MUX_ADG792A
>             tristate "Analog Devices ADG792A/ADG792G Multiplexers"
>             depends on I2C
> 
>     config MUX_ADGS1408
>             tristate "Analog Devices ADGS1408/ADGS1409 Multiplexers"
>             depends on SPI
> 
>     config MUX_GPIO
>             tristate "GPIO-controlled Multiplexer"
>             depends on GPIOLIB || COMPILE_TEST
> 
>     config MUX_MMIO
>             tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
>             depends on OF
> 
> While MUX_MMIO is selected by some/all(?) symbols that need it,
> the other three are not.  Are these three really dependent on another
> symbol selecting MULTIPLEXER?

I think you have the gist of it, yes. It's of course not ideal...

Cheers,
Peter

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Vladimir Oltean]

Hi Josua,

On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
> Rename the temporary devm_mux_state_get_optional function to avoid
> conflict with upcoming implementation in multiplexer subsystem.
> 
> Acked-by: Vinod Koul <vkoul@kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---

In the future, when you have a series with cross-tree dependencies,
please try to think of it as individual mini-series for each tree's
'next' branch, and specify clearly that you need stable tags (to be
pulled into other trees). Telling maintainers what is your expected
merge strategy helps avoid making mistakes.

For example, if you did that in this set, you wouldn't have missed the
fact that in linux-phy/next, phy-can-transceiver is _not_ the only
occurrence of devm_mux_state_get_optional(). There's another one in
drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
handled in order for trees to not enter inconsistent states.

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Geert Uytterhoeven]

Hi Vladimir,

On Thu, 12 Feb 2026 at 17:48, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
> > Rename the temporary devm_mux_state_get_optional function to avoid
> > conflict with upcoming implementation in multiplexer subsystem.
> >
> > Acked-by: Vinod Koul <vkoul@kernel.org>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
>
> In the future, when you have a series with cross-tree dependencies,
> please try to think of it as individual mini-series for each tree's
> 'next' branch, and specify clearly that you need stable tags (to be
> pulled into other trees). Telling maintainers what is your expected
> merge strategy helps avoid making mistakes.
>
> For example, if you did that in this set, you wouldn't have missed the
> fact that in linux-phy/next, phy-can-transceiver is _not_ the only
> occurrence of devm_mux_state_get_optional(). There's another one in
> drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
> handled in order for trees to not enter inconsistent states.

To his defense, the one in drivers/phy/renesas/phy-rcar-gen3-usb2.c
is a recent addition.

So this is yet another case of "convert all current users" (i.e. those
present in the typical subsystem base, typically *-rc1), with new
users popping up in -next in parallel, which happens all the time...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Josua Mayer]

Hi,

On 12/02/2026 18:53, Geert Uytterhoeven wrote:
> Hi Vladimir,
>
> On Thu, 12 Feb 2026 at 17:48, Vladimir Oltean <olteanv@gmail.com> wrote:
>> On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
>>> Rename the temporary devm_mux_state_get_optional function to avoid
>>> conflict with upcoming implementation in multiplexer subsystem.
>>>
>>> Acked-by: Vinod Koul <vkoul@kernel.org>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> In the future, when you have a series with cross-tree dependencies,
>> please try to think of it as individual mini-series for each tree's
>> 'next' branch, and specify clearly that you need stable tags (to be
>> pulled into other trees).

I don't really understand how I could split my series up to avoid this 
issue.

Due to the fact that one (and now two) drivers implemented local
mux helpers, to undo that an atomic change must be made tree-wide.

Meanwhile it must be avoided that while the mux core helpers are being
tested / reviewed, that any tree adds another driver-local mux helper
like appears to have happened here.

Note that my patch-set did go to linux-phy@lists.infradead.org list, too.

The second challenge for this series was that mux framework is being
enabled only by drivers Kconfig "select" - and not possible by menuconfig.
This is e.g. responsible for being unable to test =m build with arm64
defconfig - and lead to it only being detected through kernel robot
x86_64 allmodconfig.

>> Telling maintainers what is your expected
>> merge strategy helps avoid making mistakes.
>>
>> For example, if you did that in this set, you wouldn't have missed the
>> fact that in linux-phy/next, phy-can-transceiver is _not_ the only
>> occurrence of devm_mux_state_get_optional(). There's another one in
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
>> handled in order for trees to not enter inconsistent states.
> To his defense, the one in drivers/phy/renesas/phy-rcar-gen3-usb2.c
> is a recent addition.
>
> So this is yet another case of "convert all current users" (i.e. those
> present in the typical subsystem base, typically *-rc1), with new
> users popping up in -next in parallel, which happens all the time...
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Vladimir Oltean]

Hi Josua,

On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> >> In the future, when you have a series with cross-tree dependencies,
> >> please try to think of it as individual mini-series for each tree's
> >> 'next' branch, and specify clearly that you need stable tags (to be
> >> pulled into other trees).
> 
> I don't really understand how I could split my series up to avoid this 
> issue.
> 
> Due to the fact that one (and now two) drivers implemented local
> mux helpers, to undo that an atomic change must be made tree-wide.
> 
> Meanwhile it must be avoided that while the mux core helpers are being
> tested / reviewed, that any tree adds another driver-local mux helper
> like appears to have happened here.
> 
> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
> 
> The second challenge for this series was that mux framework is being
> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
> This is e.g. responsible for being unable to test =m build with arm64
> defconfig - and lead to it only being detected through kernel robot
> x86_64 allmodconfig.

To avoid this, a combination of developer due diligence + maintainer due
diligence is probably required.

From linux-phy perspective, there will be some automated build testing
(which did not exist at the time of your submission). This would have
caught the 'hidden' devm_mux_state_get_optional() call present only in
linux-phy/next, when testing patch 2/7.

But, to work, the build automation needs to be able to apply the entire
patch set on linux-phy/next. So expect some pushback if it doesn't
(hence the recommendation to send a mini-series to linux-phy first, and
request a stable tag).

These are the tools we have, we need to find a way to make them work somehow.

Then there is the fact that local definitions of devm_mux_state_get_optional()
keep popping up, possibly in unrelated trees (not the case here). This seems
to be a bad practice which should be discouraged during review if caught.
Otherwise, some 'retries' will be required from the developer until all
occurrences are removed.

Note that the upcoming linux-phy automated build testing does have an
x86_64 allmodconfig test too.

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Geert Uytterhoeven]

Hi Vladimir,

On Mon, 16 Feb 2026 at 10:29, Vladimir Oltean <olteanv@gmail.com> wrote:
> Then there is the fact that local definitions of devm_mux_state_get_optional()
> keep popping up, possibly in unrelated trees (not the case here). This seems
> to be a bad practice which should be discouraged during review if caught.

This was done on purpose, to (1) avoid having to make too many changes
to the file when a common helper would be introduced later, and (2) make
it easy to find all locations where a future common helper could be used.

The alternative is to use a completely different name (which is thus harder
to find), and having to fix up all the users of that name too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Andreas Kemnade]

On Mon, 16 Feb 2026 11:29:14 +0200
Vladimir Oltean <olteanv@gmail.com> wrote:

> Hi Josua,
> 
> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> > >> In the future, when you have a series with cross-tree dependencies,
> > >> please try to think of it as individual mini-series for each tree's
> > >> 'next' branch, and specify clearly that you need stable tags (to be
> > >> pulled into other trees).  
> > 
> > I don't really understand how I could split my series up to avoid this 
> > issue.
> > 
> > Due to the fact that one (and now two) drivers implemented local
> > mux helpers, to undo that an atomic change must be made tree-wide.
> > 
> > Meanwhile it must be avoided that while the mux core helpers are being
> > tested / reviewed, that any tree adds another driver-local mux helper
> > like appears to have happened here.
> > 
> > Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
> > 
> > The second challenge for this series was that mux framework is being
> > enabled only by drivers Kconfig "select" - and not possible by menuconfig.
> > This is e.g. responsible for being unable to test =m build with arm64
> > defconfig - and lead to it only being detected through kernel robot
> > x86_64 allmodconfig.  
> 
> To avoid this, a combination of developer due diligence + maintainer due
> diligence is probably required.
> 
> From linux-phy perspective, there will be some automated build testing
> (which did not exist at the time of your submission). This would have
> caught the 'hidden' devm_mux_state_get_optional() call present only in
> linux-phy/next, when testing patch 2/7.
> 
> But, to work, the build automation needs to be able to apply the entire
> patch set on linux-phy/next. So expect some pushback if it doesn't
> (hence the recommendation to send a mini-series to linux-phy first, and
> request a stable tag).
> 
I do not think that is at all the duty of the patch submitter. I think as
long as every dependencies and side effects are documented, it is IMHO up to the
maintainers to decide how it can be merged best. They know best whether there
is any danger of conflicts in their working tree because that is an area 
where people are working on. Especially this patchset is around for months.

 In MFD where it is
more common practice to have cross-subsystem patchsets, once acks from
everyone are there, MFD Maintainer creates an immutable branch with a tag.
The maintainers of the affected subsystems pull it in. 

Regards,
Andreas

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Josua Mayer]

Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> On Mon, 16 Feb 2026 11:29:14 +0200
> Vladimir Oltean <olteanv@gmail.com> wrote:
>
>> Hi Josua,
>>
>> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
>>>>> In the future, when you have a series with cross-tree dependencies,
>>>>> please try to think of it as individual mini-series for each tree's
>>>>> 'next' branch, and specify clearly that you need stable tags (to be
>>>>> pulled into other trees).  
>>> I don't really understand how I could split my series up to avoid this 
>>> issue.
>>>
>>> Due to the fact that one (and now two) drivers implemented local
>>> mux helpers, to undo that an atomic change must be made tree-wide.
>>>
>>> Meanwhile it must be avoided that while the mux core helpers are being
>>> tested / reviewed, that any tree adds another driver-local mux helper
>>> like appears to have happened here.
>>>
>>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
>>>
>>> The second challenge for this series was that mux framework is being
>>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
>>> This is e.g. responsible for being unable to test =m build with arm64
>>> defconfig - and lead to it only being detected through kernel robot
>>> x86_64 allmodconfig.  
>> To avoid this, a combination of developer due diligence + maintainer due
>> diligence is probably required.
>>
>> From linux-phy perspective, there will be some automated build testing
>> (which did not exist at the time of your submission). This would have
>> caught the 'hidden' devm_mux_state_get_optional() call present only in
>> linux-phy/next, when testing patch 2/7.
Excellent!
>>
>> But, to work, the build automation needs to be able to apply the entire
>> patch set on linux-phy/next. So expect some pushback if it doesn't
>> (hence the recommendation to send a mini-series to linux-phy first, and
>> request a stable tag).
It would help immensely if there was a way to get the patches renaming
driver-local conflicting helper-functions very early, before anything else.

Would this sort of patch be acceptable in linux-next now, so it can make
it into v7.0-rc1?

If not then that mini-patchset would be the first one I shall submit after
v7.0-rc1 is released.

Then I can treat the actual implementation of the devm_mux_* helpers
as a second standalone patch-set.

And finally patching all drivers with local helpers to use the new global ones
can be patch-set number 3.

Any opinions on this?

> I do not think that is at all the duty of the patch submitter. I think as
> long as every dependencies and side effects are documented, it is IMHO up to the
> maintainers to decide how it can be merged best. They know best whether there
> is any danger of conflicts in their working tree because that is an area 
> where people are working on. Especially this patchset is around for months.
>
>  In MFD where it is
> more common practice to have cross-subsystem patchsets, once acks from
> everyone are there, MFD Maintainer creates an immutable branch with a tag.
> The maintainers of the affected subsystems pull it in. 
This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
>
> Regards,
> Andreas
>

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Vladimir Oltean]

On Mon, Feb 23, 2026 at 12:43:48PM +0000, Josua Mayer wrote:
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
> 
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
> 
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.

v7.0-rc1 was already tagged as commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f.

Additionally, patches are not accepted directly *in* linux-next. They
are accepted in subsystem trees (linux-phy, mmc, etc) which are then
integrated all together in linux-next.

> 
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
> 
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
> 
> Any opinions on this?

From linux-phy perspective, I think in this particular case the following
would help:
- submit the patches at the beginning of the development cycle (i.e.
  now) while the subsystem trees didn't diverge too much
- submit the patch series *in full* (to get build testing of the later
  devm_mux_state_get_optional() introduction too, even if that is not
  for linux-phy)
- keep all patches pertaining to linux-phy (the mini-patchset) together
  and close to the beginning of the series, so they can be picked
  without other dependencies
- be clear in the cover letter if you require a stable tag for the
  linux-phy patches to be picked in other trees. You seem to be in the
  best position to be aware of all dependencies.

I don't know what is the exact status with the MULTIPLEXER SUBSYSTEM
which is marked as Odd Fixes and doesn't have appear to have a subsystem
tree. I have no recommendation there.

Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Ulf Hansson]

On Mon, 23 Feb 2026 at 13:44, Josua Mayer <josua@solid-run.com> wrote:
>
> Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> > On Mon, 16 Feb 2026 11:29:14 +0200
> > Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> >> Hi Josua,
> >>
> >> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> >>>>> In the future, when you have a series with cross-tree dependencies,
> >>>>> please try to think of it as individual mini-series for each tree's
> >>>>> 'next' branch, and specify clearly that you need stable tags (to be
> >>>>> pulled into other trees).
> >>> I don't really understand how I could split my series up to avoid this
> >>> issue.
> >>>
> >>> Due to the fact that one (and now two) drivers implemented local
> >>> mux helpers, to undo that an atomic change must be made tree-wide.
> >>>
> >>> Meanwhile it must be avoided that while the mux core helpers are being
> >>> tested / reviewed, that any tree adds another driver-local mux helper
> >>> like appears to have happened here.
> >>>
> >>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
> >>>
> >>> The second challenge for this series was that mux framework is being
> >>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
> >>> This is e.g. responsible for being unable to test =m build with arm64
> >>> defconfig - and lead to it only being detected through kernel robot
> >>> x86_64 allmodconfig.
> >> To avoid this, a combination of developer due diligence + maintainer due
> >> diligence is probably required.
> >>
> >> From linux-phy perspective, there will be some automated build testing
> >> (which did not exist at the time of your submission). This would have
> >> caught the 'hidden' devm_mux_state_get_optional() call present only in
> >> linux-phy/next, when testing patch 2/7.
> Excellent!
> >>
> >> But, to work, the build automation needs to be able to apply the entire
> >> patch set on linux-phy/next. So expect some pushback if it doesn't
> >> (hence the recommendation to send a mini-series to linux-phy first, and
> >> request a stable tag).
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
>
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
>
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.
>
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
>
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
>
> Any opinions on this?
>
> > I do not think that is at all the duty of the patch submitter. I think as
> > long as every dependencies and side effects are documented, it is IMHO up to the
> > maintainers to decide how it can be merged best. They know best whether there
> > is any danger of conflicts in their working tree because that is an area
> > where people are working on. Especially this patchset is around for months.
> >
> >  In MFD where it is
> > more common practice to have cross-subsystem patchsets, once acks from
> > everyone are there, MFD Maintainer creates an immutable branch with a tag.
> > The maintainers of the affected subsystems pull it in.
> This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.

I agree with this approach as it should provide less churns for all of
us. Especially since the changes to the consumer drivers here are few
and trivial.

I am willing to help with hosting the immutable branch (unless someone
else wants of course). Once all acks have been received for the
series, I can set it up. Then other subsystem maintainers can pull it
in if there is a need to avoid conflicts/build-errors.

Kind regards
Uffe