Re: [PATCH v4 1/6] dt-bindings: pinctrl: add NXP MC33978/MC34978 MSDI

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Fri, Mar 13, 2026 at 05:16:31PM +0000, Conor Dooley wrote:
> On Fri, Mar 13, 2026 at 03:02:12PM +0100, Oleksij Rempel wrote:
...
> > +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.
> > +
> > +  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.
> > +
> > +allOf:
> > +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - nxp,mc33978
> > +      - nxp,mc34978
> 
> What's different about these that a fallback is not suitable?

The difference are operation temperature ranges. But, it is not
detectable by software. This information can be reused for the hwmon.

> > +patternProperties:
> > +  '^.*-grp$':
> > +    type: object
> > +    $ref: /schemas/pinctrl/pincfg-node.yaml#
> > +    additionalProperties: false
> > +    description: Pin configuration subnodes.
> > +    properties:
> > +      pins: true
> 
> This seems overly permissive, think it should only allow the couple of
> options that your hardware has. Probably just make it an enum? Shouldn't
> have to check the driver to know what the acceptable pin names are.

Some thing like this?

      pins:
        items:
          enum: [ sg0, sg1, sg2, sg3, sg4, sg5, sg6, sg7, sg8, sg9,
                  sg10, sg11, sg12, sg13, sp0, sp1, sp2, sp3,
                  sp4, sp5, sp6, sp7 ]

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-5\x7f555 |