Add device tree binding documentation for the NXP MC33978 and MC34978
Multiple Switch Detection Interface (MSDI) devices.

These ICs monitor up to 22 mechanical switch contacts in automotive and
industrial environments. They provide configurable wetting currents to
break through contact oxidation and feature extensive hardware
protection against thermal overload and voltage transients (load
dumps/brown-outs).

The device interfaces via SPI and provides multiple functions. To
accurately represent the hardware without unnecessary DT overhead, the
binding is structured as follows:
- pinctrl: A dedicated child node managing the 22 switch inputs (SG/SP
  pins) and their GPIO configurations.
- hwmon: Integrated into the parent node, exposing critical hardware
  faults (OT, OV, UV) and static voltage/temperature thresholds.
- mux: Integrated into the parent node, controlling the 24-to-1 analog
  multiplexer to route pin voltages, internal temperature, or battery
  voltage to an external SoC ADC.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
changes v2:
- Squashed MFD, pinctrl, hwmon, and mux bindings into a single patch
- Removed the empty hwmon child node
- Folded the mux-controller node into the parent MFD node
- Added vbatp-supply and vddq-supply to the required properties block
- Changed the example node name from mc33978@0 to gpio@0
- Removed unnecessary literal block scalars (|) from descriptions
- Documented SG, SP, and SB pin acronyms in the pinctrl description
- Added consumer polarity guidance (GPIO_ACTIVE_LOW/HIGH) for SG/SB
  inputs, with a note on output circuit dependency
- Updated commit message
---
 .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
 .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
 2 files changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml

diff --git a/Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml b/Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
new file mode 100644
index 000000000000..9deb5de0ce23
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,mc33978.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP MC33978/MC34978 Multiple Switch Detection Interface
+
+maintainers:
+  - David Jander <david@protonic.nl>
+  - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description:
+  The MC33978 and MC34978 are Multiple Switch Detection Interface (MSDI)
+  devices with 22 switch inputs, integrated fault detection, and analog
+  multiplexer (AMUX) for voltage/temperature monitoring.
+
+allOf:
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+  $nodename:
+    pattern: "^gpio(@.*)?$"
+
+  compatible:
+    enum:
+      - nxp,mc33978
+      - nxp,mc34978
+
+  reg:
+    maxItems: 1
+    description: SPI chip select number
+
+  spi-max-frequency:
+    maximum: 8000000
+    description: Maximum SPI clock frequency (up to 8 MHz)
+
+  interrupts:
+    maxItems: 1
+    description:
+      INT_B pin interrupt. Active-low, indicates pin state changes or
+      fault conditions.
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+    const: 2
+    description:
+      First cell is the IRQ number (0-21 for pins, 22 for faults).
+      Second cell is the trigger type (IRQ_TYPE_* from interrupt-controller.h).
+
+  '#mux-control-cells':
+    const: 0
+    description:
+      Present if the device AMUX selector is used as a mux provider.
+      Consumers (e.g. io-channel-mux) must provide settle-time-us for the
+      external ADC sampling path.
+
+  vddq-supply:
+    description: Digital supply voltage
+
+  vbatp-supply:
+    description: Battery/power supply
+
+patternProperties:
+  "^pinctrl(@.*)?":
+    type: object
+    $ref: /schemas/pinctrl/nxp,mc33978-pinctrl.yaml#
+    description:
+      Pinctrl and GPIO controller child node for the 22 switch inputs.
+
+required:
+  - compatible
+  - interrupt-controller
+  - '#interrupt-cells'
+  - interrupts
+  - reg
+  - vbatp-supply
+  - vddq-supply
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/gpio/gpio.h>
+
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        msdi: gpio@0 {
+            compatible = "nxp,mc33978";
+            reg = <0>;
+            spi-max-frequency = <4000000>;
+
+            interrupt-parent = <&gpiog>;
+            interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
+            interrupt-controller;
+            #interrupt-cells = <2>;
+
+            vddq-supply = <&reg_3v3>;
+            vbatp-supply = <&reg_12v>;
+
+            #mux-control-cells = <0>;
+
+            pinctrl {
+                compatible = "nxp,mc33978-pinctrl";
+                gpio-controller;
+                #gpio-cells = <2>;
+            };
+
+        };
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
new file mode 100644
index 000000000000..f8257d55d466
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nxp,mc33978-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP MC33978/MC34978 Pinctrl/GPIO Driver
+
+maintainers:
+  - David Jander <david@protonic.nl>
+  - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description: |
+  Pin control and GPIO driver for the MC33978/MC34978 MSDI device.
+
+  Pin numbering:
+  - Pins 0-13: SG0-SG13 (Switch-to-Ground inputs). These pins monitor
+    contacts closed to ground and typically require GPIO_ACTIVE_LOW
+    flags when used as digital inputs.
+  - Pins 14-21: SP0-SP7 (Programmable inputs). These can be configured
+    as SG (Switch-to-Ground) or SB (Switch-to-Battery) inputs. SB
+    inputs monitor contacts closed to the battery voltage and typically
+    require GPIO_ACTIVE_HIGH flags when used as digital inputs.
+
+  Output Emulation:
+  The hardware lacks standard push-pull output drivers. Outputs are emulated
+  by toggling the programmable wetting current sources (acting as pull-ups or
+  pull-downs) and the hardware tri-state registers. Because of this physical
+  constraint:
+  - Consumers using pins as outputs MUST flag them with GPIO_OPEN_DRAIN or
+    GPIO_OPEN_SOURCE in the device tree.
+  - Push-pull configurations are physically unsupported.
+  - The active polarity depends entirely on the external circuit (e.g., how an
+    LED is wired) and must be flagged accordingly by the consumer.
+
+properties:
+  compatible:
+    enum:
+      - nxp,mc33978-pinctrl
+      - nxp,mc34978-pinctrl
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    const: 2
+
+  ngpios:
+    const: 22
+
+patternProperties:
+  "^.*-grp$":
+    type: object
+    $ref: pincfg-node.yaml#
+    additionalProperties: false
+    description:
+      Pin configuration subnodes.
+    properties:
+      pins: true
+      bias-pull-up: true
+      bias-pull-down: true
+      bias-high-impedance: true
+
+required:
+  - compatible
+  - gpio-controller
+  - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    pinctrl {
+        compatible = "nxp,mc33978-pinctrl";
+        gpio-controller;
+        #gpio-cells = <2>;
+        ngpios = <22>;
+
+        door-grp {
+            pins = "sg0";
+            bias-high-impedance;
+        };
+    };
-- 
2.47.3

On Tue, Mar 03, 2026 at 02:39:41PM +0100, Oleksij Rempel wrote:
> +  '#mux-control-cells':
> +    const: 0
> +    description:
> +      Present if the device AMUX selector is used as a mux provider.
> +      Consumers (e.g. io-channel-mux) must provide settle-time-us for the
> +      external ADC sampling path.
> +
> +  vddq-supply:
> +    description: Digital supply voltage
> +
> +  vbatp-supply:
> +    description: Battery/power supply
> +
> +patternProperties:
> +  "^pinctrl(@.*)?":

Drop @ part. Your binding does not allow addressing anyway.

> +    type: object
> +    $ref: /schemas/pinctrl/nxp,mc33978-pinctrl.yaml#
> +    description:
> +      Pinctrl and GPIO controller child node for the 22 switch inputs.
> +
> +required:
> +  - compatible
> +  - interrupt-controller
> +  - '#interrupt-cells'
> +  - interrupts
> +  - reg

Odd order. Keep the same as in the list of properties.

> +  - vbatp-supply
> +  - vddq-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        msdi: gpio@0 {
> +            compatible = "nxp,mc33978";
> +            reg = <0>;
> +            spi-max-frequency = <4000000>;
> +
> +            interrupt-parent = <&gpiog>;
> +            interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
> +            interrupt-controller;
> +            #interrupt-cells = <2>;
> +
> +            vddq-supply = <&reg_3v3>;
> +            vbatp-supply = <&reg_12v>;
> +
> +            #mux-control-cells = <0>;
> +
> +            pinctrl {
> +                compatible = "nxp,mc33978-pinctrl";
> +                gpio-controller;
> +                #gpio-cells = <2>;
> +            };
> +

Stray blank line

> +        };
> +    };
> diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> new file mode 100644
> index 000000000000..f8257d55d466
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/nxp,mc33978-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP MC33978/MC34978 Pinctrl/GPIO Driver
> +
> +maintainers:
> +  - David Jander <david@protonic.nl>
> +  - Oleksij Rempel <o.rempel@pengutronix.de>
> +
> +description: |
> +  Pin control and GPIO driver for the MC33978/MC34978 MSDI device.
> +
> +  Pin numbering:
> +  - Pins 0-13: SG0-SG13 (Switch-to-Ground inputs). These pins monitor
> +    contacts closed to ground and typically require GPIO_ACTIVE_LOW
> +    flags when used as digital inputs.
> +  - Pins 14-21: SP0-SP7 (Programmable inputs). These can be configured
> +    as SG (Switch-to-Ground) or SB (Switch-to-Battery) inputs. SB
> +    inputs monitor contacts closed to the battery voltage and typically
> +    require GPIO_ACTIVE_HIGH flags when used as digital inputs.
> +
> +  Output Emulation:
> +  The hardware lacks standard push-pull output drivers. Outputs are emulated
> +  by toggling the programmable wetting current sources (acting as pull-ups or
> +  pull-downs) and the hardware tri-state registers. Because of this physical
> +  constraint:
> +  - Consumers using pins as outputs MUST flag them with GPIO_OPEN_DRAIN or
> +    GPIO_OPEN_SOURCE in the device tree.
> +  - Push-pull configurations are physically unsupported.
> +  - The active polarity depends entirely on the external circuit (e.g., how an
> +    LED is wired) and must be flagged accordingly by the consumer.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - nxp,mc33978-pinctrl
> +      - nxp,mc34978-pinctrl
> +
> +  gpio-controller: true
> +
> +  '#gpio-cells':
> +    const: 2
> +
> +  ngpios:
> +    const: 22
> +
> +patternProperties:
> +  "^.*-grp$":
> +    type: object
> +    $ref: pincfg-node.yaml#
> +    additionalProperties: false
> +    description:
> +      Pin configuration subnodes.
> +    properties:
> +      pins: true
> +      bias-pull-up: true
> +      bias-pull-down: true
> +      bias-high-impedance: true
> +
> +required:
> +  - compatible
> +  - gpio-controller
> +  - '#gpio-cells'
> +
> +unevaluatedProperties: false

additionalProperties instead

> +
> +examples:
> +  - |
> +    pinctrl {
> +        compatible = "nxp,mc33978-pinctrl";
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +        ngpios = <22>;
> +
> +        door-grp {
> +            pins = "sg0";
> +            bias-high-impedance;
> +        };
> +    };
> -- 
> 2.47.3
>

On Tue, 03 Mar 2026 14:39:41 +0100, Oleksij Rempel wrote:
> Add device tree binding documentation for the NXP MC33978 and MC34978
> Multiple Switch Detection Interface (MSDI) devices.
> 
> These ICs monitor up to 22 mechanical switch contacts in automotive and
> industrial environments. They provide configurable wetting currents to
> break through contact oxidation and feature extensive hardware
> protection against thermal overload and voltage transients (load
> dumps/brown-outs).
> 
> The device interfaces via SPI and provides multiple functions. To
> accurately represent the hardware without unnecessary DT overhead, the
> binding is structured as follows:
> - pinctrl: A dedicated child node managing the 22 switch inputs (SG/SP
>   pins) and their GPIO configurations.
> - hwmon: Integrated into the parent node, exposing critical hardware
>   faults (OT, OV, UV) and static voltage/temperature thresholds.
> - mux: Integrated into the parent node, controlling the 24-to-1 analog
>   multiplexer to route pin voltages, internal temperature, or battery
>   voltage to an external SoC ADC.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> changes v2:
> - Squashed MFD, pinctrl, hwmon, and mux bindings into a single patch
> - Removed the empty hwmon child node
> - Folded the mux-controller node into the parent MFD node
> - Added vbatp-supply and vddq-supply to the required properties block
> - Changed the example node name from mc33978@0 to gpio@0
> - Removed unnecessary literal block scalars (|) from descriptions
> - Documented SG, SP, and SB pin acronyms in the pinctrl description
> - Added consumer polarity guidance (GPIO_ACTIVE_LOW/HIGH) for SG/SB
>   inputs, with a note on output circuit dependency
> - Updated commit message
> ---
>  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
>  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
>  2 files changed, 196 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260303133947.1123575-2-o.rempel@pengutronix.de

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Hi Krzysztof and Rob,

On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:
> >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> >  2 files changed, 196 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> 

Folding the mux node into the parent as suggested [1] causes this error.
Because the parent now has #mux-control-cells, the generic
mux-controller.yaml forces the node name to be mux-controller. Since
this chip is primarily a switch/GPIO controller, naming the parent SPI
node mux-controller@0 is misleading.

What is the preferred way to go here?

[1] https://lore.kernel.org/all/20260226-clever-rustling-dolphin-871aff@quoll/

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

On Tue, Mar 3, 2026 at 10:10 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
>
> Hi Krzysztof and Rob,
>
> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:
> > >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> > >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> > >  2 files changed, 196 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > >
> >
> > My bot found errors running 'make dt_binding_check' on your patch:
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> >       from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> >
>
> Folding the mux node into the parent as suggested [1] causes this error.
> Because the parent now has #mux-control-cells, the generic
> mux-controller.yaml forces the node name to be mux-controller. Since
> this chip is primarily a switch/GPIO controller, naming the parent SPI
> node mux-controller@0 is misleading.
>
> What is the preferred way to go here?

I think there was another series dropping the mux-controller node
name. Not sure what happened to it, but that's what we need to do
here.

Rob

On Wed, Mar 04, 2026 at 12:26:17PM -0600, Rob Herring wrote:
> On Tue, Mar 3, 2026 at 10:10 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >
> > Hi Krzysztof and Rob,
> >
> > On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:
> > > >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> > > >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> > > >  2 files changed, 196 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> > > >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > > >
> > >
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> > >       from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> > >
> >
> > Folding the mux node into the parent as suggested [1] causes this error.
> > Because the parent now has #mux-control-cells, the generic
> > mux-controller.yaml forces the node name to be mux-controller. Since
> > this chip is primarily a switch/GPIO controller, naming the parent SPI
> > node mux-controller@0 is misleading.
> >
> > What is the preferred way to go here?
> 
> I think there was another series dropping the mux-controller node
> name. Not sure what happened to it, but that's what we need to do
> here.

It's here:
https://lore.kernel.org/all/cover.1769703480.git.tommaso.merciai.xr@bp.renesas.com/

Tommaso pinged me about it wondering what to do. Mux maintainer has been
unresponsive. Maybe you should grab the binding portion since it is
blocking other work?
https://lore.kernel.org/all/cover.1769703480.git.tommaso.merciai.xr@bp.renesas.com/

> 
> Rob

On Wed, Mar 04, 2026 at 06:33:34PM +0000, Conor Dooley wrote:
> On Wed, Mar 04, 2026 at 12:26:17PM -0600, Rob Herring wrote:
> > On Tue, Mar 3, 2026 at 10:10 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > >
> > > Hi Krzysztof and Rob,
> > >
> > > On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:
> > > > >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> > > > >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> > > > >  2 files changed, 196 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> > > > >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > > > >
> > > >
> > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > >
> > > > yamllint warnings/errors:
> > > >
> > > > dtschema/dtc warnings/errors:
> > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> > > >       from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> > > >
> > >
> > > Folding the mux node into the parent as suggested [1] causes this error.
> > > Because the parent now has #mux-control-cells, the generic
> > > mux-controller.yaml forces the node name to be mux-controller. Since
> > > this chip is primarily a switch/GPIO controller, naming the parent SPI
> > > node mux-controller@0 is misleading.
> > >
> > > What is the preferred way to go here?
> > 
> > I think there was another series dropping the mux-controller node
> > name. Not sure what happened to it, but that's what we need to do
> > here.
> 
> It's here:
> https://lore.kernel.org/all/cover.1769703480.git.tommaso.merciai.xr@bp.renesas.com/
> 
> Tommaso pinged me about it wondering what to do. Mux maintainer has been
> unresponsive. Maybe you should grab the binding portion since it is
> blocking other work?
> https://lore.kernel.org/all/cover.1769703480.git.tommaso.merciai.xr@bp.renesas.com/

It is now applied.

Rob

On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:
> Hi Krzysztof and Rob,
> 
> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:
> > >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> > >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> > >  2 files changed, 196 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > > 
> > 
> > My bot found errors running 'make dt_binding_check' on your patch:
> > 
> > yamllint warnings/errors:
> > 
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> > 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> > 
> 
> Folding the mux node into the parent as suggested [1] causes this error.
> Because the parent now has #mux-control-cells, the generic
> mux-controller.yaml forces the node name to be mux-controller. Since
> this chip is primarily a switch/GPIO controller, naming the parent SPI
> node mux-controller@0 is misleading.
> 
> What is the preferred way to go here?

https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978

Name of the mc33978 device is "programmable analog mux" and further
description says "analog multiplexer for reading analog inputs ", so I
don't find "mux-controller" a confusing name. It is EXACTLY a
mux, so mux-controller.

Anyway if you want gpio, then please add a patch extending the pattern
in mux-controller.yaml to allow "gpio".

Alternative, because it is rather a mux than a controller of a mux,
would be to call it just "mux" or "io-mux" (maybe the latter, since we
have "i2c-mux" in the spec) and allow that pattern to be in
mux-controller.


Best regards,
Krzysztof

Hi Krzysztof,

On Wed, 4 Mar 2026 09:05:11 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:
> > Hi Krzysztof and Rob,
> > 
> > On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:  
> > > >  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> > > >  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> > > >  2 files changed, 196 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> > > >  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> > > >   
> > > 
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > > 
> > > yamllint warnings/errors:
> > > 
> > > dtschema/dtc warnings/errors:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> > > 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> > >   
> > 
> > Folding the mux node into the parent as suggested [1] causes this error.
> > Because the parent now has #mux-control-cells, the generic
> > mux-controller.yaml forces the node name to be mux-controller. Since
> > this chip is primarily a switch/GPIO controller, naming the parent SPI
> > node mux-controller@0 is misleading.
> > 
> > What is the preferred way to go here?  
> 
> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978
> 
> Name of the mc33978 device is "programmable analog mux" and further
> description says "analog multiplexer for reading analog inputs ", so I
> don't find "mux-controller" a confusing name. It is EXACTLY a
> mux, so mux-controller.

Sorry to chime in here. I'm afraid the NXP description on that link you posted
is a typo. It is not correct. This chip is primarily a "Switch Detection
Interface", or in other wordt a switch input interface. Wee here for the same
page for the MC34978, which is the exact same chip:

https://www.nxp.com/products/interfaces/multi-switch-detection-interface/switch-detection-interface-22-i-os-programmable-wetting-current-temp-sensor-3-3-v-5-0-v-spi:MC34978

It has an additional function that can be used as an analog MUX, but it is an
extra feature and definitely NOT its primary function.

Not sure if this is relevant, but I fear there might be some confusion.

Best regards,

> Anyway if you want gpio, then please add a patch extending the pattern
> in mux-controller.yaml to allow "gpio".
> 
> Alternative, because it is rather a mux than a controller of a mux,
> would be to call it just "mux" or "io-mux" (maybe the latter, since we
> have "i2c-mux" in the spec) and allow that pattern to be in
> mux-controller.
> 
> 
> Best regards,
> Krzysztof

-- 
David Jander

On 04/03/2026 10:06, David Jander wrote:
> 
> Hi Krzysztof,
> 
> On Wed, 4 Mar 2026 09:05:11 +0100
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>> On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:
>>> Hi Krzysztof and Rob,
>>>
>>> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:  
>>>>>  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
>>>>>  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
>>>>>  2 files changed, 196 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
>>>>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
>>>>>   
>>>>
>>>> My bot found errors running 'make dt_binding_check' on your patch:
>>>>
>>>> yamllint warnings/errors:
>>>>
>>>> dtschema/dtc warnings/errors:
>>>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
>>>> 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
>>>>   
>>>
>>> Folding the mux node into the parent as suggested [1] causes this error.
>>> Because the parent now has #mux-control-cells, the generic
>>> mux-controller.yaml forces the node name to be mux-controller. Since
>>> this chip is primarily a switch/GPIO controller, naming the parent SPI
>>> node mux-controller@0 is misleading.
>>>
>>> What is the preferred way to go here?  
>>
>> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978
>>
>> Name of the mc33978 device is "programmable analog mux" and further
>> description says "analog multiplexer for reading analog inputs ", so I
>> don't find "mux-controller" a confusing name. It is EXACTLY a
>> mux, so mux-controller.
> 
> Sorry to chime in here. I'm afraid the NXP description on that link you posted
> is a typo. It is not correct. This chip is primarily a "Switch Detection
> Interface", or in other wordt a switch input interface. Wee here for the same
> page for the MC34978, which is the exact same chip:
> 
> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/switch-detection-interface-22-i-os-programmable-wetting-current-temp-sensor-3-3-v-5-0-v-spi:MC34978

That's MC34978 and I commented on MC33978.

What is the primary function of MC33978 being described here as the base?

> 
> It has an additional function that can be used as an analog MUX, but it is an
> extra feature and definitely NOT its primary function.
> 
> Not sure if this is relevant, but I fear there might be some confusion.
> 
> Best regards,
> 
>> Anyway if you want gpio, then please add a patch extending the pattern
>> in mux-controller.yaml to allow "gpio".
>>
>> Alternative, because it is rather a mux than a controller of a mux,
>> would be to call it just "mux" or "io-mux" (maybe the latter, since we
>> have "i2c-mux" in the spec) and allow that pattern to be in
>> mux-controller.
>>
>>
>> Best regards,
>> Krzysztof
> 


Best regards,
Krzysztof

On Wed, 4 Mar 2026 10:49:06 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 04/03/2026 10:06, David Jander wrote:
> > 
> > Hi Krzysztof,
> > 
> > On Wed, 4 Mar 2026 09:05:11 +0100
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >   
> >> On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:  
> >>> Hi Krzysztof and Rob,
> >>>
> >>> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:    
> >>>>>  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> >>>>>  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> >>>>>  2 files changed, 196 insertions(+)
> >>>>>  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> >>>>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> >>>>>     
> >>>>
> >>>> My bot found errors running 'make dt_binding_check' on your patch:
> >>>>
> >>>> yamllint warnings/errors:
> >>>>
> >>>> dtschema/dtc warnings/errors:
> >>>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> >>>> 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> >>>>     
> >>>
> >>> Folding the mux node into the parent as suggested [1] causes this error.
> >>> Because the parent now has #mux-control-cells, the generic
> >>> mux-controller.yaml forces the node name to be mux-controller. Since
> >>> this chip is primarily a switch/GPIO controller, naming the parent SPI
> >>> node mux-controller@0 is misleading.
> >>>
> >>> What is the preferred way to go here?    
> >>
> >> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978
> >>
> >> Name of the mc33978 device is "programmable analog mux" and further
> >> description says "analog multiplexer for reading analog inputs ", so I
> >> don't find "mux-controller" a confusing name. It is EXACTLY a
> >> mux, so mux-controller.  
> > 
> > Sorry to chime in here. I'm afraid the NXP description on that link you posted
> > is a typo. It is not correct. This chip is primarily a "Switch Detection
> > Interface", or in other wordt a switch input interface. Wee here for the same
> > page for the MC34978, which is the exact same chip:
> > 
> > https://www.nxp.com/products/interfaces/multi-switch-detection-interface/switch-detection-interface-22-i-os-programmable-wetting-current-temp-sensor-3-3-v-5-0-v-spi:MC34978  
> 
> That's MC34978 and I commented on MC33978.
> 
> What is the primary function of MC33978 being described here as the base?

The MC34978 and MC33978 are the exact same part (except for the temperature
range). The fact that NXP has two different web-pages with two different
descriptions of it certainly doesn't help, but you can also check the
datasheet[1] description: "MC33978: 22-channel multiple switch detection
interface with programmable wetting current"

Further down in the description it says: "It also features a 24-to-1 analog
multiplexer for reading inputs as analog."
IMHO this makes it clear that this is NOT primarily a MUX.

Actually, I doubt many users of this chip will use the analog MUX function at
all since it has quite a few limitations that make it not very practical to
use.

The most fitting Linux framework for this chip's primary funtcion IMHO is
pinctrl/gpio, but there are some caveats unfortunately.

[1] https://www.nxp.com/docs/en/data-sheet/MC33978.pdf

Best regards,

> > It has an additional function that can be used as an analog MUX, but it is an
> > extra feature and definitely NOT its primary function.
> > 
> > Not sure if this is relevant, but I fear there might be some confusion.
> > 
> > Best regards,
> >   
> >> Anyway if you want gpio, then please add a patch extending the pattern
> >> in mux-controller.yaml to allow "gpio".
> >>
> >> Alternative, because it is rather a mux than a controller of a mux,
> >> would be to call it just "mux" or "io-mux" (maybe the latter, since we
> >> have "i2c-mux" in the spec) and allow that pattern to be in
> >> mux-controller.


-- 
David Jander

On 04/03/2026 11:25, David Jander wrote:
> On Wed, 4 Mar 2026 10:49:06 +0100
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>> On 04/03/2026 10:06, David Jander wrote:
>>>
>>> Hi Krzysztof,
>>>
>>> On Wed, 4 Mar 2026 09:05:11 +0100
>>> Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>   
>>>> On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:  
>>>>> Hi Krzysztof and Rob,
>>>>>
>>>>> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:    
>>>>>>>  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
>>>>>>>  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
>>>>>>>  2 files changed, 196 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
>>>>>>>     
>>>>>>
>>>>>> My bot found errors running 'make dt_binding_check' on your patch:
>>>>>>
>>>>>> yamllint warnings/errors:
>>>>>>
>>>>>> dtschema/dtc warnings/errors:
>>>>>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
>>>>>> 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
>>>>>>     
>>>>>
>>>>> Folding the mux node into the parent as suggested [1] causes this error.
>>>>> Because the parent now has #mux-control-cells, the generic
>>>>> mux-controller.yaml forces the node name to be mux-controller. Since
>>>>> this chip is primarily a switch/GPIO controller, naming the parent SPI
>>>>> node mux-controller@0 is misleading.
>>>>>
>>>>> What is the preferred way to go here?    
>>>>
>>>> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978
>>>>
>>>> Name of the mc33978 device is "programmable analog mux" and further
>>>> description says "analog multiplexer for reading analog inputs ", so I
>>>> don't find "mux-controller" a confusing name. It is EXACTLY a
>>>> mux, so mux-controller.  
>>>
>>> Sorry to chime in here. I'm afraid the NXP description on that link you posted
>>> is a typo. It is not correct. This chip is primarily a "Switch Detection
>>> Interface", or in other wordt a switch input interface. Wee here for the same
>>> page for the MC34978, which is the exact same chip:
>>>
>>> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/switch-detection-interface-22-i-os-programmable-wetting-current-temp-sensor-3-3-v-5-0-v-spi:MC34978  
>>
>> That's MC34978 and I commented on MC33978.
>>
>> What is the primary function of MC33978 being described here as the base?
> 
> The MC34978 and MC33978 are the exact same part (except for the temperature
> range). The fact that NXP has two different web-pages with two different
> descriptions of it certainly doesn't help, but you can also check the
> datasheet[1] description: "MC33978: 22-channel multiple switch detection
> interface with programmable wetting current"
> 
> Further down in the description it says: "It also features a 24-to-1 analog
> multiplexer for reading inputs as analog."
> IMHO this makes it clear that this is NOT primarily a MUX.
> 
> Actually, I doubt many users of this chip will use the analog MUX function at
> all since it has quite a few limitations that make it not very practical to
> use.
> 
> The most fitting Linux framework for this chip's primary funtcion IMHO is
> pinctrl/gpio, but there are some caveats unfortunately.
> 
> [1] https://www.nxp.com/docs/en/data-sheet/MC33978.pdf

OK, thanks for the explanation, but then primary function is not GPIO
either, because nothing on linked page says it is a generic purpose IO.
It says it is switch detection. Maybe better generic name is then
"pinctrl", thus also "pinctrl" child should be folded into the parent...
but switch detection is also not a pinctrl. :/

Best regards,
Krzysztof

On Wed, 4 Mar 2026 12:41:37 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 04/03/2026 11:25, David Jander wrote:
> > On Wed, 4 Mar 2026 10:49:06 +0100
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >   
> >> On 04/03/2026 10:06, David Jander wrote:  
> >>>
> >>> Hi Krzysztof,
> >>>
> >>> On Wed, 4 Mar 2026 09:05:11 +0100
> >>> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>     
> >>>> On Tue, Mar 03, 2026 at 05:10:20PM +0100, Oleksij Rempel wrote:    
> >>>>> Hi Krzysztof and Rob,
> >>>>>
> >>>>> On Tue, Mar 03, 2026 at 08:40:55AM -0600, Rob Herring (Arm) wrote:      
> >>>>>>>  .../devicetree/bindings/mfd/nxp,mc33978.yaml  | 114 ++++++++++++++++++
> >>>>>>>  .../bindings/pinctrl/nxp,mc33978-pinctrl.yaml |  82 +++++++++++++
> >>>>>>>  2 files changed, 196 insertions(+)
> >>>>>>>  create mode 100644 Documentation/devicetree/bindings/mfd/nxp,mc33978.yaml
> >>>>>>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978-pinctrl.yaml
> >>>>>>>       
> >>>>>>
> >>>>>> My bot found errors running 'make dt_binding_check' on your patch:
> >>>>>>
> >>>>>> yamllint warnings/errors:
> >>>>>>
> >>>>>> dtschema/dtc warnings/errors:
> >>>>>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
> >>>>>> 	from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
> >>>>>>       
> >>>>>
> >>>>> Folding the mux node into the parent as suggested [1] causes this error.
> >>>>> Because the parent now has #mux-control-cells, the generic
> >>>>> mux-controller.yaml forces the node name to be mux-controller. Since
> >>>>> this chip is primarily a switch/GPIO controller, naming the parent SPI
> >>>>> node mux-controller@0 is misleading.
> >>>>>
> >>>>> What is the preferred way to go here?      
> >>>>
> >>>> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/22-i-o-msdi-programmable-current-analog-mux:MC33978
> >>>>
> >>>> Name of the mc33978 device is "programmable analog mux" and further
> >>>> description says "analog multiplexer for reading analog inputs ", so I
> >>>> don't find "mux-controller" a confusing name. It is EXACTLY a
> >>>> mux, so mux-controller.    
> >>>
> >>> Sorry to chime in here. I'm afraid the NXP description on that link you posted
> >>> is a typo. It is not correct. This chip is primarily a "Switch Detection
> >>> Interface", or in other wordt a switch input interface. Wee here for the same
> >>> page for the MC34978, which is the exact same chip:
> >>>
> >>> https://www.nxp.com/products/interfaces/multi-switch-detection-interface/switch-detection-interface-22-i-os-programmable-wetting-current-temp-sensor-3-3-v-5-0-v-spi:MC34978    
> >>
> >> That's MC34978 and I commented on MC33978.
> >>
> >> What is the primary function of MC33978 being described here as the base?  
> > 
> > The MC34978 and MC33978 are the exact same part (except for the temperature
> > range). The fact that NXP has two different web-pages with two different
> > descriptions of it certainly doesn't help, but you can also check the
> > datasheet[1] description: "MC33978: 22-channel multiple switch detection
> > interface with programmable wetting current"
> > 
> > Further down in the description it says: "It also features a 24-to-1 analog
> > multiplexer for reading inputs as analog."
> > IMHO this makes it clear that this is NOT primarily a MUX.
> > 
> > Actually, I doubt many users of this chip will use the analog MUX function at
> > all since it has quite a few limitations that make it not very practical to
> > use.
> > 
> > The most fitting Linux framework for this chip's primary funtcion IMHO is
> > pinctrl/gpio, but there are some caveats unfortunately.
> > 
> > [1] https://www.nxp.com/docs/en/data-sheet/MC33978.pdf  
> 
> OK, thanks for the explanation, but then primary function is not GPIO
> either, because nothing on linked page says it is a generic purpose IO.
> It says it is switch detection. Maybe better generic name is then
> "pinctrl", thus also "pinctrl" child should be folded into the parent...
> but switch detection is also not a pinctrl. :/

I agree. This chip is indeed not very clear-cut with respect to the correct
Linux subsystem. It could also be an input device if you view it strictly from
the "switches" standpoint. I thought about this also, but figured that it
would be more flexible to just view it as a pinctrl device, which could always
be used in combination with something like gpio-keys.c if one really wanted
the input functionality. For context, our use-case is primarily for industrial
control reading digital sensors such as mechanical switches or industrial
optical sensors, and that is AFAIK the main application for this chip anyway.
For this the gpio UAPI is a good match.

Best regards,

-- 
David Jander

On Wed, Mar 4, 2026 at 1:18 PM David Jander <david@protonic.nl> wrote:

> > OK, thanks for the explanation, but then primary function is not GPIO
> > either, because nothing on linked page says it is a generic purpose IO.
> > It says it is switch detection. Maybe better generic name is then
> > "pinctrl", thus also "pinctrl" child should be folded into the parent...
> > but switch detection is also not a pinctrl. :/
>
> I agree. This chip is indeed not very clear-cut with respect to the correct
> Linux subsystem. It could also be an input device if you view it strictly from
> the "switches" standpoint. I thought about this also, but figured that it
> would be more flexible to just view it as a pinctrl device, which could always
> be used in combination with something like gpio-keys.c if one really wanted
> the input functionality. For context, our use-case is primarily for industrial
> control reading digital sensors such as mechanical switches or industrial
> optical sensors, and that is AFAIK the main application for this chip anyway.
> For this the gpio UAPI is a good match.

I have read the datasheets and GPIO+pinctrl is the best fit in my opinion,
mostly because there are a lot of electric properties involved and there
are industrial use cases, which is a good fit for the GPIO character
device and the pinctrl+GPIO generic pin config options, some which
are already identical.

The alternative would be to create something new in drivers/iio
which I think is overkill.

Yours,
Linus Walleij

On Thu, 5 Mar 2026 13:54:20 +0100
Linus Walleij <linusw@kernel.org> wrote:

> On Wed, Mar 4, 2026 at 1:18 PM David Jander <david@protonic.nl> wrote:
> 
> > > OK, thanks for the explanation, but then primary function is not GPIO
> > > either, because nothing on linked page says it is a generic purpose IO.
> > > It says it is switch detection. Maybe better generic name is then
> > > "pinctrl", thus also "pinctrl" child should be folded into the parent...
> > > but switch detection is also not a pinctrl. :/  
> >
> > I agree. This chip is indeed not very clear-cut with respect to the correct
> > Linux subsystem. It could also be an input device if you view it strictly from
> > the "switches" standpoint. I thought about this also, but figured that it
> > would be more flexible to just view it as a pinctrl device, which could always
> > be used in combination with something like gpio-keys.c if one really wanted
> > the input functionality. For context, our use-case is primarily for industrial
> > control reading digital sensors such as mechanical switches or industrial
> > optical sensors, and that is AFAIK the main application for this chip anyway.
> > For this the gpio UAPI is a good match.  
> 
> I have read the datasheets and GPIO+pinctrl is the best fit in my opinion,
> mostly because there are a lot of electric properties involved and there
> are industrial use cases, which is a good fit for the GPIO character
> device and the pinctrl+GPIO generic pin config options, some which
> are already identical.

Ack.

Sorry for this following long question to Linus. TL;DR: switch vs voltage
semantics for logical input state.

Taking the opportunity that you read the datasheet and put some thought
into this (thank you!), I'd like to know your opinion on a specific friction
point where this chip doesn't quite fit the GPIO framework exactly (or maybe
it does?):

Looking at the description of the "switch status" register (chapter 7.20.27),
it says "A Logic [1] means the switch is closed while a Logic [0] is an open
switch". This reflects the semantics of the switches being the inputs.
Nevertheless, if a switch is in SG mode (switch to ground with positive
wetting current), this means that the voltage level at the chip input pin is 0V
when the switch is closed. If the switch is in SB mode (switch to battery),
then the voltage at the chip pin is positive when the switch is closed.

In other words: the chip reports logic 1 or logic 0 in its input register
according to the state of the switch, and NOT according to the voltage at the
input pin.

The question I have is thus: Should the GPIO driver of this particular chip
report the state of the switch or should it report the state corresponding to
voltage at the input pin?

The former would mean 1:1 reporting of the "switch-state" register bits. The
latter would imply having to invert all the bits that correspond to inputs
that are in SG mode, while leaving bits corresponding to inputs in SB mode
without inverting.

I am tempted to think that hardware developers that use this chip might expect
the GPIO driver to report the state as it is read from the register. But I
suspect that the Linux kernel GPIO framework might enforce strictly the
logical state to be equal to the voltage at the pin (i.e. logic 0 == zero volt,
and logic 1 == positive non-zero voltage), but is this true?

Right now the driver inverts the "switch state" register bits accordingly if
SG mode is selected for a particular input, but maybe it is better not to do
this, since it introduces more complexity and replaces the semantics of the
chip with some (mandatory?) semantics of the Linux kernel.

Please advice.

> The alternative would be to create something new in drivers/iio
> which I think is overkill.

I agree.
OT: I think "Industrial IO" is a bit of a misnomer, as this subsystem mainly
focuses on analog IO. If we were to extend "IIO" to also digital industrial
IO, then not only would it collide with GPIO, but probably the upcoming second
iteration of the "Linux Motion Control" subsystem would also need to move
there... which is definitely overkill IMHO.

Best regards,

-- 
David Jander

On Thu, Mar 5, 2026 at 4:10 PM David Jander <david@protonic.nl> wrote:

> I am tempted to think that hardware developers that use this chip might expect
> the GPIO driver to report the state as it is read from the register. But I
> suspect that the Linux kernel GPIO framework might enforce strictly the
> logical state to be equal to the voltage at the pin (i.e. logic 0 == zero volt,
> and logic 1 == positive non-zero voltage), but is this true?

GPIO assumes all values are expressing the (raw) voltage on the pin
clamped to [0,1] logic level.

It can further invert the meaning of this using GPIO_ACTIVE_LOW,
ACTIVE LOW means the same as  "overstrike"  or #VAL in schematic
so if a signal is active low and low voltage on the board it is
presented as active (1) to the consumers in the kernel or
userspace.

If it represents anything else than the raw logic voltage on the line,
the semantics of GPIO_ACTIVE_LOW would be completely
confusing.

To represent switch states, I think using drivers or userspace code
should interpret this.

You can also add a custom debugfs file to your driver to help
users by providing the actual switch state and more.

Yours,
Linus Walleij

On Fri, 6 Mar 2026 00:40:16 +0100
Linus Walleij <linusw@kernel.org> wrote:

> On Thu, Mar 5, 2026 at 4:10 PM David Jander <david@protonic.nl> wrote:
> 
> > I am tempted to think that hardware developers that use this chip might expect
> > the GPIO driver to report the state as it is read from the register. But I
> > suspect that the Linux kernel GPIO framework might enforce strictly the
> > logical state to be equal to the voltage at the pin (i.e. logic 0 == zero volt,
> > and logic 1 == positive non-zero voltage), but is this true?  
> 
> GPIO assumes all values are expressing the (raw) voltage on the pin
> clamped to [0,1] logic level.

This sounds like a good, usable definition. I like it, but I can't find it in
the documentation. To make it more complete, I'd add one more clarification in
case we deal with negative voltage levels (0 and -5V for example), but it is
usable for this case. Where can I find it? Or.. should we add it to the
documentation if it isn't documented this way yet?

> It can further invert the meaning of this using GPIO_ACTIVE_LOW,
> ACTIVE LOW means the same as  "overstrike"  or #VAL in schematic
> so if a signal is active low and low voltage on the board it is
> presented as active (1) to the consumers in the kernel or
> userspace.
> 
> If it represents anything else than the raw logic voltage on the line,
> the semantics of GPIO_ACTIVE_LOW would be completely
> confusing.
> 
> To represent switch states, I think using drivers or userspace code
> should interpret this.
> 
> You can also add a custom debugfs file to your driver to help
> users by providing the actual switch state and more.

Thanks for clarifying. This makes sense taking into account the above
definition of raw logic-level == raw voltage on pin clamped to [0,1].
But for the future users of this driver I would need this officially defined
somewhere, so I can point there to avoid confusion.

Best regards,

-- 
David Jander

On Fri, Mar 6, 2026 at 9:44 AM David Jander <david@protonic.nl> wrote:

> > GPIO assumes all values are expressing the (raw) voltage on the pin
> > clamped to [0,1] logic level.
>
> This sounds like a good, usable definition. I like it, but I can't find it in
> the documentation.

I sent a patch, thanks for noting that.

> To make it more complete, I'd add one more clarification in
> case we deal with negative voltage levels (0 and -5V for example), but it is
> usable for this case. Where can I find it? Or.. should we add it to the
> documentation if it isn't documented this way yet?

We don't really do upfront design, we deal with this case the day
we have a driver that needs it.

> Thanks for clarifying. This makes sense taking into account the above
> definition of raw logic-level == raw voltage on pin clamped to [0,1].
> But for the future users of this driver I would need this officially defined
> somewhere, so I can point there to avoid confusion.

See proposed patch, it may need some debate but it's in there.

Yours,
Linus Walleij