From: David Jander <david@protonic.nl>
To: Linus Walleij <linusw@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Oleksij Rempel <o.rempel@pengutronix.de>,
"Rob Herring (Arm)" <robh@kernel.org>,
devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Peter Rosin <peda@axentia.se>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, Lee Jones <lee@kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2 1/6] dt-bindings: mfd: add NXP MC33978/MC34978 MSDI
Date: Fri, 6 Mar 2026 09:44:06 +0100 [thread overview]
Message-ID: <20260306094406.6cafaeea@erd003.prtnl> (raw)
In-Reply-To: <CAD++jL=Gaaq0_20wDjjPkYwpyL6HWx7bmKqBmy_tieYu4scB6Q@mail.gmail.com>
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
next prev parent reply other threads:[~2026-03-06 8:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 13:39 [PATCH v2 0/8] mfd: Add support for NXP MC33978/MC34978 MSDI Oleksij Rempel
2026-03-03 13:39 ` [PATCH v2 1/6] dt-bindings: mfd: add " Oleksij Rempel
2026-03-03 14:40 ` Rob Herring (Arm)
2026-03-03 16:10 ` Oleksij Rempel
2026-03-04 8:05 ` Krzysztof Kozlowski
2026-03-04 9:06 ` David Jander
2026-03-04 9:49 ` Krzysztof Kozlowski
2026-03-04 10:25 ` David Jander
2026-03-04 11:41 ` Krzysztof Kozlowski
2026-03-04 12:17 ` David Jander
2026-03-05 12:54 ` Linus Walleij
2026-03-05 15:10 ` David Jander
2026-03-05 23:40 ` Linus Walleij
2026-03-06 8:44 ` David Jander [this message]
2026-03-06 13:24 ` Linus Walleij
2026-03-04 18:26 ` Rob Herring
2026-03-04 18:33 ` Conor Dooley
2026-03-05 2:38 ` Rob Herring
2026-03-04 7:59 ` Krzysztof Kozlowski
2026-03-03 13:39 ` [PATCH v2 2/6] mfd: add NXP MC33978/MC34978 core driver Oleksij Rempel
2026-03-03 13:39 ` [PATCH v2 3/6] pinctrl: core: Make pin group callbacks optional Oleksij Rempel
2026-03-03 13:39 ` [PATCH v2 4/6] pinctrl: add NXP MC33978/MC34978 pinctrl driver Oleksij Rempel
2026-03-05 13:41 ` Linus Walleij
2026-03-03 13:39 ` [PATCH v2 5/6] hwmon: add NXP MC33978/MC34978 driver Oleksij Rempel
2026-03-03 13:39 ` [PATCH v2 6/6] mux: add NXP MC33978/MC34978 AMUX driver Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260306094406.6cafaeea@erd003.prtnl \
--to=david@protonic.nl \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lee@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=o.rempel@pengutronix.de \
--cc=peda@axentia.se \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox