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

[David Jander <david@protonic.nl>]

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