linux-kernel - Re: [RFC v1 2/4] pinctrl: add polarfire soc mssio pinctrl driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkda3Oz+K1t38QKgWipEseJxxneBSC11sFvzpB7ycnqsjBA@mail.gmail.com>
Date: Wed, 19 Nov 2025 22:48:07 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Conor Dooley <conor@...nel.org>
Cc: Conor Dooley <conor.dooley@...rochip.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	Valentina.FernandezAlanis@...rochip.com, Bartosz Golaszewski <brgl@...ev.pl>
Subject: Re: [RFC v1 2/4] pinctrl: add polarfire soc mssio pinctrl driver

On Wed, Nov 19, 2025 at 7:23 PM Conor Dooley <conor@...nel.org> wrote:
> On Wed, Nov 19, 2025 at 01:08:26PM +0100, Linus Walleij wrote:
> > On Wed, Nov 12, 2025 at 3:33 PM Conor Dooley <conor@...nel.org> wrote:

> > > +       //TODO @Linus, it correct to group these 3? There's no control over voltage.
> > > +       case PIN_CONFIG_INPUT_SCHMITT:
> > > +       case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> > > +       case PIN_CONFIG_INPUT_SCHMITT_UV:
> >
> > Consider not supporting some like PIN_CONFIG_INPUT_SCHMITT_UV
> > in the bindings if they don't make any sense, and let it just return error
> > if someone tries to do that.
> >
> > Isn't PIN_CONFIG_INPUT_SCHMITT_ENABLE the only one that
> > makes sense for this hardware?
>
> Yeah, I just didn't know if having the others was helpful, since they
> say things like:
>  * @PIN_CONFIG_INPUT_SCHMITT: this will configure an input pin to run in
>  *      schmitt-trigger mode. If the schmitt-trigger has adjustable hysteresis,
>  *      the threshold value is given on a custom format as argument when
>  *      setting pins to this mode.
> which implies they should be implemented for systen not permitting
> hysteresis adjustment.

I see.

I looked at the bindings that look like this and are not 1:1 to the
in-kernel configs:

  input-schmitt-enable:
    type: boolean
    description: enable schmitt-trigger mode

  input-schmitt-disable:
    type: boolean
    description: disable schmitt-trigger mode

  input-schmitt-microvolt:
    description: threshold strength for schmitt-trigger

1. input-schmitt is missing! But it is right there in
drivers/pinctrl/pinconf-generic.c ... All DTS files appear to be
using input-schmitt-enable/disable and -microvolt.

2. input-schmitt-microvolt should probably be used separately
to set the voltage threshold and can be used in conjunction
with input-schmitt-enable in the same node. In your case
you probably don't want to use it at all and disallow it.

They are all treated individually in the parser.

Maybe we could patch the docs in pinconf-generic.h to make it clear that
they are all mutually exclusive.

The DT parser is a bit primitive for these.
For example right now it is fine with the schema
to set input-schmitt-enable and input-schmitt-disable at the same time, and
the result will be enabled because of parse order :/

The real trick would be to also make the
schema in Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
make them at least mutually exclusive and deprecate the
input-schmitt that noone is using, maybe that is simpler than I think?

Yours,
Linus Walleij