[PATCH 0/2] Add TI's event mux router driver and build

[PATCH 0/2] Add TI's event mux router driver and build

[Rahul Sharma]

This series contains the event mux router support present in TI's K3
platforms. The event mux router are of 2 types
1) gpio-mux router
2) timesync router

In normal scenarios, GPIO signals are received by CPU via GIC, but the
gpio mux router routes the incoming GPIO signal to BCDMA(Block copy
DMA) which the DMA upon receiving uses as HW triger to perform a single
block transfer or as configured.

Time sync router achieves the same but for the time synchronization based
events.

This driver supports both the routers but this patch series adds support
only for GPIO-mux router.

Rahul Sharma (2):
  dt-bindings: mux-controller: ti: add binding for event mux router
  mux-controller: ti: add driver for event mux router

 .../mux/ti,am62l-event-mux-router.yaml        |  79 ++++++
 drivers/mux/Kconfig                           |  15 ++
 drivers/mux/Makefile                          |   2 +
 drivers/mux/ti-k3-event-mux.c                 | 235 ++++++++++++++++++
 4 files changed, 331 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
 create mode 100644 drivers/mux/ti-k3-event-mux.c

-- 
2.34.1

[PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router

[Rahul Sharma]

Add binding for the event mux router of TI's K3 based SoC AM62L.

The TI K3 mux routers which route the GPIO input events or Time-Sync
events b/w peripherals instead of routing to a CPU.

Refer Section 10.2 and 10.2.1 of https://www.ti.com/lit/pdf/sprujb4

Signed-off-by: Rahul Sharma <r-sharma3@ti.com>
---
 .../mux/ti,am62l-event-mux-router.yaml        | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml

diff --git a/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
new file mode 100644
index 000000000000..a5ba7f78a156
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mux/ti,am62l-event-mux-router.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Event Multiplexer on K3 SoCs
+
+maintainers:
+  - Rahul Sharma <r-sharma3@ti.com>
+
+description:
+  The TI K3 mux routers routes the GPIO input events or Time
+  Sync events between peripherals instead of routing to a CPU.
+
+allOf:
+  - $ref: mux-controller.yaml#
+
+properties:
+  compatible:
+    const: ti,am62l-event-mux-router
+
+  reg:
+    description: Register base address and size.
+    maxItems: 1
+
+  '#mux-control-cells':
+    const: 1
+    description:
+      Number of cells in a mux control specifier. This should be 1.
+      The cell specifies which mux control to use (0-based index).
+
+  ti,reg-mask-val:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+    items:
+      items:
+        - description: Register offset (relative to reg base)
+        - description: Bit mask for the mux control bits
+        - description: Value to write when mux is active (state 1)
+    minItems: 1
+    description: |
+      Array of triplets specifying register offset, mask, and value for each
+      mux control. Each triplet contains:
+      - register offset (relative to reg base)
+      - bit mask for the mux control bits
+      - value to write when mux is active (state 1)
+
+  idle-states:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description: |
+      Idle state for each mux control. Each entry corresponds to a mux control:
+      - 0: clear masked bits when idle, also refers to inactive state
+      - 1: set configured value when idle, also refers to active state
+      - MUX_IDLE_AS_IS (-1): keep current state when idle
+
+required:
+  - compatible
+  - reg
+  - '#mux-control-cells'
+  - ti,reg-mask-val
+  - idle-states
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/mux/mux.h>
+
+    // Example 1: TI AM62L GPIO Mux Router
+    mux-controller@a00000 {
+        compatible = "ti,am62l-event-mux-router";
+        reg = <0xa00000 0x400>;
+        #mux-control-cells = <1>;
+
+        /* Mux Register addresses: 0xa00004 + (J × 4) */
+        /* GPIO0_40 -> BCDMA trigger 15 */
+        ti,reg-mask-val = <0x40 0x000ff 0x00028>;
+        idle-states = <0>;
+    };
-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Type conflict in `idle-states` prevents usage of `-1` (MUX_IDLE_AS_IS)
--

commit 62dcdc2062832a1a63ed2621fea7779807b815a5
Author: Rahul Sharma <r-sharma3@ti.com>

dt-bindings: mux-controller: ti: add binding for event mux router

Add binding for the event mux router of TI's K3 based SoC AM62L.
The TI K3 mux routers route GPIO input events or Time-Sync events between
peripherals instead of routing to a CPU.

> diff --git a/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
> new file mode 100644
> index 0000000000000..a5ba7f78a1567
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml

[ ... ]

> +  idle-states:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array

[Severity: Medium]
Will this uint32-array type prevent the usage of -1 (MUX_IDLE_AS_IS)?

The idle-states property is locally typed as uint32-array, which conflicts
with the int32-array definition in the base mux-controller.yaml included
via allOf.

Since the property description explicitly supports -1 (MUX_IDLE_AS_IS),
dt-schema validation will fail when a device tree uses it (either because -1
mapped to an unsigned 32-bit int exceeds the maximum value for int32, or
because a signed -1 violates the minimum value of 0 for uint32).

> +    description: |
> +      Idle state for each mux control. Each entry corresponds to a mux control:
> +      - 0: clear masked bits when idle, also refers to inactive state
> +      - 1: set configured value when idle, also refers to active state
> +      - MUX_IDLE_AS_IS (-1): keep current state when idle
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#mux-control-cells'
> +  - ti,reg-mask-val
> +  - idle-states

[Severity: Medium]
Does making this property required prevent users from working around the type
conflict?

Because the property is mandatory, device tree authors cannot bypass the schema
validation failure by simply omitting the property to achieve the default
keep-as-is behavior.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828100615.1700223-1-r-sharma3@ti.com?part=1

Re: [PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router

[Alvin Šipraga]

Hi Rahul,

On Fri, Aug 28, 2026 at 03:36:14PM +0530, Rahul Sharma wrote:
> Add binding for the event mux router of TI's K3 based SoC AM62L.

[...]

> +  ti,reg-mask-val:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    items:
> +      items:
> +        - description: Register offset (relative to reg base)
> +        - description: Bit mask for the mux control bits
> +        - description: Value to write when mux is active (state 1)
> +    minItems: 1
> +    description: |
> +      Array of triplets specifying register offset, mask, and value for each
> +      mux control. Each triplet contains:
> +      - register offset (relative to reg base)
> +      - bit mask for the mux control bits
> +      - value to write when mux is active (state 1)

As I understand it, you are creating a binary (0=off / 1=on) mux control
for each reg-mask-val triplet. But couldn't you just use the mmio-mux
binding/driver for this, delegating the value setting to the consumer?

[...]

> +examples:
> +  - |
> +    #include <dt-bindings/mux/mux.h>
> +
> +    // Example 1: TI AM62L GPIO Mux Router
> +    mux-controller@a00000 {
> +        compatible = "ti,am62l-event-mux-router";
> +        reg = <0xa00000 0x400>;
> +        #mux-control-cells = <1>;
> +
> +        /* Mux Register addresses: 0xa00004 + (J × 4) */
> +        /* GPIO0_40 -> BCDMA trigger 15 */
> +        ti,reg-mask-val = <0x40 0x000ff 0x00028>;
> +        idle-states = <0>;
> +    };

Alternatively,

 foo_mux: mux-controller {
   compatible = "mmio-mux";
   reg = <...>;
   #mux-control-cells = <1>;
   mux-reg-masks = <0x40 0x000ff>;
   idle-states = <0>;
 };

 toto-consumer {
   compatible = "toto";
   mux-states = <&foo_mux 0 0x00028>;
   mux-state-names = "gpio-trigger";
 };

What's wrong with that?

Kind regards,
Alvin

Re: [PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router

[Conor Dooley]

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

On Fri, Aug 28, 2026 at 03:36:14PM +0530, Rahul Sharma wrote:
> Add binding for the event mux router of TI's K3 based SoC AM62L.
> 
> The TI K3 mux routers which route the GPIO input events or Time-Sync
> events b/w peripherals instead of routing to a CPU.
> 
> Refer Section 10.2 and 10.2.1 of https://www.ti.com/lit/pdf/sprujb4
> 
> Signed-off-by: Rahul Sharma <r-sharma3@ti.com>
> ---
>  .../mux/ti,am62l-event-mux-router.yaml        | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
> new file mode 100644
> index 000000000000..a5ba7f78a156
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mux/ti,am62l-event-mux-router.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI Event Multiplexer on K3 SoCs
> +
> +maintainers:
> +  - Rahul Sharma <r-sharma3@ti.com>
> +
> +description:
> +  The TI K3 mux routers routes the GPIO input events or Time
> +  Sync events between peripherals instead of routing to a CPU.
> +
> +allOf:
> +  - $ref: mux-controller.yaml#
> +
> +properties:
> +  compatible:
> +    const: ti,am62l-event-mux-router
> +
> +  reg:
> +    description: Register base address and size.
> +    maxItems: 1
> +
> +  '#mux-control-cells':
> +    const: 1
> +    description:
> +      Number of cells in a mux control specifier. This should be 1.
> +      The cell specifies which mux control to use (0-based index).
> +
> +  ti,reg-mask-val:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    items:
> +      items:
> +        - description: Register offset (relative to reg base)
> +        - description: Bit mask for the mux control bits
> +        - description: Value to write when mux is active (state 1)
> +    minItems: 1
> +    description: |
> +      Array of triplets specifying register offset, mask, and value for each
> +      mux control. Each triplet contains:
> +      - register offset (relative to reg base)
> +      - bit mask for the mux control bits
> +      - value to write when mux is active (state 1)

You have a device-specific compatible, why do you need this? If the
active setting depends on the device or w/e, why can that not come from
a mux-control-cell?

> +
> +  idle-states:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array

This is not needed, you get the type from mux-controller.yaml.

pw-bot: changes-requested

Thanks,
Conor.

> +    description: |
> +      Idle state for each mux control. Each entry corresponds to a mux control:
> +      - 0: clear masked bits when idle, also refers to inactive state
> +      - 1: set configured value when idle, also refers to active state
> +      - MUX_IDLE_AS_IS (-1): keep current state when idle
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#mux-control-cells'
> +  - ti,reg-mask-val
> +  - idle-states
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/mux/mux.h>
> +
> +    // Example 1: TI AM62L GPIO Mux Router
> +    mux-controller@a00000 {
> +        compatible = "ti,am62l-event-mux-router";
> +        reg = <0xa00000 0x400>;
> +        #mux-control-cells = <1>;
> +
> +        /* Mux Register addresses: 0xa00004 + (J × 4) */
> +        /* GPIO0_40 -> BCDMA trigger 15 */
> +        ti,reg-mask-val = <0x40 0x000ff 0x00028>;
> +        idle-states = <0>;
> +    };
> -- 
> 2.34.1
> 

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

[PATCH 2/2] mux-controller: ti: add driver for event mux router

[Rahul Sharma]

The driver supports event muxing routers like gpio mux router and timesync
router. This driver is adaptation of original reg-mux driver, along with
changes specific to support TI's mux router.

The idle states this driver supports are only 2 which active(represented
by 1 in dt-node) and in-active(represented by 0 in dt-node).

Signed-off-by: Rahul Sharma <r-sharma3@ti.com>
---
 drivers/mux/Kconfig           |  15 +++
 drivers/mux/Makefile          |   2 +
 drivers/mux/ti-k3-event-mux.c | 235 ++++++++++++++++++++++++++++++++++
 3 files changed, 252 insertions(+)
 create mode 100644 drivers/mux/ti-k3-event-mux.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index eb34457beaab..58739a01f0d5 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -83,6 +83,21 @@ config MUX_RZV2H_VBENCTL
 	  To compile the driver as a module, choose M here: the module will
 	  be called mux-rzv2h-vbenctl.
 
+config MUX_TI_K3_EVENT_ROUTER
+	tristate "TI Event Mux Router using MMIO registers"
+	depends on OF && (REGMAP_MMIO || COMPILE_TEST)
+	help
+	  This is extension of MMIO mux for  timesync router and gpiomux
+	  routers on TI K3 SoCs. This driver supports the 3-field format for
+	  mux control: <register-offset mask value>.
+
+	  The driver allows configuration of hardware mux routers using
+	  memory-mapped registers. It's based on the mmio-mux driver but
+	  supports the extended 3-field format for more precise control.
+
+	  To compile the driver as a module, choose M here: the module will
+	  be called mux-ti-k3-event.
+
 endmenu
 
 endif # MULTIPLEXER
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 0854c04613b9..114abf88b75e 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -9,6 +9,7 @@ mux-adgs1408-objs		:= adgs1408.o
 mux-gpio-objs			:= gpio.o
 mux-mmio-objs			:= mmio.o
 mux-rzv2h-vbenctl-objs		:= rzv2h-vbenctl.o
+mux-ti-k3-event-objs		:= ti-k3-event-mux.o
 
 obj-$(CONFIG_MULTIPLEXER)	+= mux-core.o
 obj-$(CONFIG_MUX_ADG792A)	+= mux-adg792a.o
@@ -16,3 +17,4 @@ obj-$(CONFIG_MUX_ADGS1408)	+= mux-adgs1408.o
 obj-$(CONFIG_MUX_GPIO)		+= mux-gpio.o
 obj-$(CONFIG_MUX_MMIO)		+= mux-mmio.o
 obj-$(CONFIG_MUX_RZV2H_VBENCTL)	+= mux-rzv2h-vbenctl.o
+obj-$(CONFIG_MUX_TI_K3_EVENT_ROUTER)	+= mux-ti-k3-event.o
diff --git a/drivers/mux/ti-k3-event-mux.c b/drivers/mux/ti-k3-event-mux.c
new file mode 100644
index 000000000000..2469500d1b48
--- /dev/null
+++ b/drivers/mux/ti-k3-event-mux.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MMIO register bit-field controlled multiplexer driver
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com
+ *
+ * Based on drivers/mux/mmio.c by Philipp Zabel <kernel@pengutronix.de>
+ * Modified to support 3-field format: reg-offset, mask & value
+ *
+ * Author: Rahul Sharma <r-sharma3@ti.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/mux/driver.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+#define MUX_ENABLE_INTR BIT(16)
+
+struct mux_ti_k3_event {
+	struct regmap *regmap;
+	u32 reg;
+	u32 mask;
+	u32 value;
+};
+
+struct mux_ti_k3_event_chip {
+	struct mux_chip *mux_chip;
+	struct mux_ti_k3_event *fields;
+	int num_fields;
+	u32 *saved_states;
+};
+
+static int mux_ti_k3_event_suspend(struct device *dev)
+{
+	struct mux_ti_k3_event_chip *chip = dev_get_drvdata(dev);
+	int i, ret;
+
+	if (!chip->saved_states) {
+		chip->saved_states = devm_kcalloc(dev, chip->num_fields,
+						  sizeof(u32), GFP_KERNEL);
+		if (!chip->saved_states)
+			return -ENOMEM;
+	}
+
+	for (i = 0; i < chip->num_fields; i++) {
+		struct mux_ti_k3_event *field = &chip->fields[i];
+
+		ret = regmap_read(field->regmap, field->reg,
+				  &chip->saved_states[i]);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int mux_ti_k3_event_resume(struct device *dev)
+{
+	struct mux_ti_k3_event_chip *chip = dev_get_drvdata(dev);
+	int i, ret;
+
+	if (!chip->saved_states)
+		return 0;
+
+	for (i = 0; i < chip->num_fields; i++) {
+		struct mux_ti_k3_event *field = &chip->fields[i];
+
+		ret = regmap_write(field->regmap, field->reg,
+				   chip->saved_states[i]);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(mux_ti_k3_event_pm_ops,
+				mux_ti_k3_event_suspend,
+				mux_ti_k3_event_resume);
+
+/*
+ * State behavior:
+ * - state 0: Clears the mask bits in the target register (inactive state)
+ * - state 1: Sets both the value bits and enable bit (bit 16) in the register
+ */
+static int mux_ti_k3_event_set(struct mux_control *mux, int state)
+{
+	struct mux_ti_k3_event *fields = mux_chip_priv(mux->chip);
+	struct mux_ti_k3_event *field = &fields[mux_control_get_index(mux)];
+
+	if (!state)
+		return regmap_update_bits(field->regmap, field->reg, field->mask, 0);
+
+	return regmap_update_bits(field->regmap, field->reg, field->mask | MUX_ENABLE_INTR,
+		field->value | MUX_ENABLE_INTR);
+}
+
+static const struct mux_control_ops mux_ti_k3_event_ops = {
+	.set = mux_ti_k3_event_set,
+};
+
+static const struct regmap_config mux_ti_k3_event_regmap_cfg = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+};
+
+static int mux_ti_k3_event_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mux_ti_k3_event_chip *chip;
+	struct mux_ti_k3_event *fields;
+	struct mux_chip *mux_chip;
+	struct regmap *regmap;
+	void __iomem *base;
+	int num_fields;
+	int ret;
+	int i;
+
+	chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
+	if (!chip)
+		return -ENOMEM;
+
+	base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(base)) {
+		return dev_err_probe(dev, -ENODEV,
+				     "failed to get base address\n");
+	} else {
+		regmap = devm_regmap_init_mmio(dev, base, &mux_ti_k3_event_regmap_cfg);
+	}
+	if (IS_ERR(regmap)) {
+		iounmap(base);
+		return dev_err_probe(dev, PTR_ERR(regmap),
+				     "failed to get regmap\n");
+	}
+
+	ret = of_property_count_u32_elems(np, "ti,reg-mask-val");
+	if (!ret || ret % 3) {
+		ret = -EINVAL;
+		dev_err(dev, "ti,reg-mask-val property missing or invalid: %d\n",
+			ret);
+		return ret;
+	}
+
+	num_fields = ret / 3;
+	mux_chip = devm_mux_chip_alloc(dev, num_fields, num_fields *
+				       sizeof(*fields));
+	if (IS_ERR(mux_chip))
+		return PTR_ERR(mux_chip);
+
+	fields = mux_chip_priv(mux_chip);
+	chip->mux_chip = mux_chip;
+	chip->fields = fields;
+	chip->num_fields = num_fields;
+
+	platform_set_drvdata(pdev, chip);
+
+	for (i = 0; i < num_fields; i++) {
+		struct mux_control *mux = &mux_chip->mux[i];
+		s32 idle_state = MUX_IDLE_AS_IS;
+		u32 reg, mask, value;
+
+		ret = of_property_read_u32_index(np, "ti,reg-mask-val",
+						 3 * i, &reg);
+		if (!ret)
+			ret = of_property_read_u32_index(np, "ti,reg-mask-val",
+							 3 * i + 1, &mask);
+		if (!ret)
+			ret = of_property_read_u32_index(np, "ti,reg-mask-val",
+							 3 * i + 2, &value);
+		if (ret < 0) {
+			dev_err(dev, "field %d: failed to read ti,reg-mask-val property: %d\n",
+				i, ret);
+			return ret;
+		}
+
+		/* Validate that value bits are within mask */
+		if (value & ~mask) {
+			dev_err(dev, "field %d: value 0x%x has bits outside mask 0x%x\n",
+				i, value, mask);
+			return -EINVAL;
+		}
+
+		fields[i].regmap = regmap;
+		fields[i].reg = reg;
+		fields[i].mask = mask;
+		fields[i].value = value;
+
+		/* This driver supports binary mux (2 states: 0 and active) */
+		mux->states = 2;
+
+		of_property_read_u32_index(np, "idle-states", i,
+					   (u32 *)&idle_state);
+		if (idle_state != MUX_IDLE_AS_IS) {
+			if (idle_state < 0 || idle_state >= mux->states) {
+				dev_err(dev, "field: %d: out of range idle state %d\n",
+					i, idle_state);
+				return -EINVAL;
+			}
+
+			mux->idle_state = idle_state;
+		}
+	}
+
+	mux_chip->ops = &mux_ti_k3_event_ops;
+
+	return devm_mux_chip_register(dev, mux_chip);
+}
+
+static const struct of_device_id mux_ti_k3_event_dt_ids[] = {
+	{ .compatible = "ti,am62l-event-mux-router", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mux_ti_k3_event_dt_ids);
+
+static struct platform_driver mux_ti_k3_event_driver = {
+	.driver = {
+		.name = "ti-k3-event-mux",
+		.of_match_table	= mux_ti_k3_event_dt_ids,
+		.pm = &mux_ti_k3_event_pm_ops,
+	},
+	.probe = mux_ti_k3_event_probe,
+};
+module_platform_driver(mux_ti_k3_event_driver);
+
+MODULE_DESCRIPTION("TI K3 Bit-field Controlled Event Multiplexer driver");
+MODULE_AUTHOR("Rahul Sharma <r-sharma3@ti.com>");
+MODULE_LICENSE("GPL");
-- 
2.34.1

Re: [PATCH 2/2] mux-controller: ti: add driver for event mux router

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Explicit iounmap() called on a devres-managed memory region on the error path.
- [High] Blocking memory allocation with GFP_KERNEL is used inside a PM suspend callback.
- [Medium] Disabling the mux (state 0) fails to clear the interrupt enable bit (MUX_ENABLE_INTR).
- [Medium] Brittle error check using modulo operator bypasses negative error codes that are multiples of 3.
- [Medium] Masking of original error code from devm_platform_ioremap_resource drops context like -EPROBE_DEFER.
- [Low] Driver enables COMPILE_TEST but fails to select REGMAP_MMIO, causing linker errors.
--

commit 4ce655ff4ffe60f566fd3744fe5da650083548ce
Author: Rahul Sharma <r-sharma3@ti.com>

mux-controller: ti: add driver for event mux router

The driver supports event muxing routers like gpio mux router and timesync
router. It allows configuration of hardware mux routers using memory-mapped
registers and supports a 3-field format for precise control.

> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index eb34457beaab3..58739a01f0d53 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
[ ... ]
> @@ -83,6 +83,21 @@ config MUX_RZV2H_VBENCTL
>  	  To compile the driver as a module, choose M here: the module will
>  	  be called mux-rzv2h-vbenctl.
>  
> +config MUX_TI_K3_EVENT_ROUTER
> +	tristate "TI Event Mux Router using MMIO registers"
> +	depends on OF && (REGMAP_MMIO || COMPILE_TEST)

[Severity: Low]
Does this dependency expose the driver to build failures? When compiling with
CONFIG_COMPILE_TEST=y and CONFIG_REGMAP_MMIO=n, this allows the driver to be
built, but devm_regmap_init_mmio() lacks an inline stub when REGMAP_MMIO is
disabled, which can cause linker errors. Should this select REGMAP_MMIO if
COMPILE_TEST is enabled, or depend directly on REGMAP_MMIO?

> +	help
> +	  This is extension of MMIO mux for  timesync router and gpiomux
[ ... ]
> diff --git a/drivers/mux/ti-k3-event-mux.c b/drivers/mux/ti-k3-event-mux.c
> new file mode 100644
> index 0000000000000..2469500d1b48c
> --- /dev/null
> +++ b/drivers/mux/ti-k3-event-mux.c
[ ... ]
> +static int mux_ti_k3_event_suspend(struct device *dev)
> +{
> +	struct mux_ti_k3_event_chip *chip = dev_get_drvdata(dev);
> +	int i, ret;
> +
> +	if (!chip->saved_states) {
> +		chip->saved_states = devm_kcalloc(dev, chip->num_fields,
> +						  sizeof(u32), GFP_KERNEL);

[Severity: High]
Can this blocking allocation cause a deadlock during system suspend? The
mux_ti_k3_event_suspend() callback dynamically allocates memory using
GFP_KERNEL on the first system suspend. Executing GFP_KERNEL allocations
during system suspend is unsafe because user processes are frozen and devices
may already be suspended, potentially triggering memory reclaim and writeback
that waits on a suspended device.

> +		if (!chip->saved_states)
> +			return -ENOMEM;
> +	}
[ ... ]
> +static int mux_ti_k3_event_set(struct mux_control *mux, int state)
> +{
> +	struct mux_ti_k3_event *fields = mux_chip_priv(mux->chip);
> +	struct mux_ti_k3_event *field = &fields[mux_control_get_index(mux)];
> +
> +	if (!state)
> +		return regmap_update_bits(field->regmap, field->reg, field->mask, 0);

[Severity: Medium]
Does transitioning to the inactive state (0) fail to clear the interrupt
enable bit? The active state (1) forces MUX_ENABLE_INTR to be set. However,
the inactive state updates the register using only field->mask with value 0.
Because MUX_ENABLE_INTR is not part of field->mask read from the device tree,
regmap_update_bits() will leave the hardware mux channel partially enabled.

> +
> +	return regmap_update_bits(field->regmap, field->reg, field->mask | MUX_ENABLE_INTR,
> +		field->value | MUX_ENABLE_INTR);
> +}
[ ... ]
> +static int mux_ti_k3_event_probe(struct platform_device *pdev)
> +{
[ ... ]
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base)) {
> +		return dev_err_probe(dev, -ENODEV,
> +				     "failed to get base address\n");

[Severity: Medium]
Does hardcoding the return value to -ENODEV break deferred probing? Masking
the original error code from devm_platform_ioremap_resource() discards
context like -EPROBE_DEFER, preventing the core subsystem from correctly
deferring the probe when resources are unavailable.

> +	} else {
> +		regmap = devm_regmap_init_mmio(dev, base, &mux_ti_k3_event_regmap_cfg);
> +	}
> +	if (IS_ERR(regmap)) {
> +		iounmap(base);

[Severity: High]
Does this explicit iounmap() cause a double-free of the ioremap mapping?
Because base was allocated using devm_platform_ioremap_resource(), the
devres framework will automatically attempt to unmap it again during the
probe rollback if devm_regmap_init_mmio() fails.

> +		return dev_err_probe(dev, PTR_ERR(regmap),
> +				     "failed to get regmap\n");
> +	}
> +
> +	ret = of_property_count_u32_elems(np, "ti,reg-mask-val");
> +	if (!ret || ret % 3) {

[Severity: Medium]
Could this error check bypass negative error codes that are multiples of 3?
If of_property_count_u32_elems() returns an error code like -EOVERFLOW (-75),
ret % 3 evaluates to false. This results in the driver calculating a negative
num_fields and proceeding to devm_mux_chip_alloc() with a wrapped size,
hiding the true configuration error and failing with -ENOMEM later.

> +		ret = -EINVAL;
> +		dev_err(dev, "ti,reg-mask-val property missing or invalid: %d\n",
> +			ret);
> +		return ret;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828100615.1700223-1-r-sharma3@ti.com?part=2