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] [day] [month] [year] [list]

Message-ID: <20251125-depravity-proofs-17b8d5dba748@spud>
Date: Tue, 25 Nov 2025 01:03:02 +0000
From: Conor Dooley <conor@...nel.org>
To: Linus Walleij <linusw@...nel.org>
Cc: Linus Walleij <linus.walleij@...aro.org>,
	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 Tue, Nov 25, 2025 at 01:31:49AM +0100, Linus Walleij wrote:
> On Mon, Nov 24, 2025 at 6:16 PM Conor Dooley <conor@...nel.org> wrote:
> 
> > I was looking at the kernel part of this today, trying to figure out
> > where it would make sense to actually check this, but I'm not super keen
> > on what has to be done. I think doing it in parse_dt_cfg() makes the
> > most sense, setting flags if the property is one we care about during
> > the loop and then checking mutual exclusion at the end based on the
> > flags? The gpio example you gave has it easy, since they already appear
> > to have these things stored in flag properties.
> > Is there somewhere else, in addition to creating the config from dt that
> > this would have to be checked?
> 
> 
> We are right now parsing with an array of
> struct pinconf_generic_params:
> 
> static const struct pinconf_generic_params dt_params[] = {
>     { "input-disable", PIN_CONFIG_INPUT_ENABLE, 0 },
>     (...)
> };
> 
> (Sorry for not using C99 .initializers on the above array)
> 
> Struct looks like so:
> 
> struct pinconf_generic_params {
>         const char * const property;
>         enum pin_config_param param;
>         u32 default_value;
>         const char * const *values;
>         size_t num_values;
> };
> 
> Can't we add a
>     const enum pin_config_param *conflicts;
>     size_t num_conflicts;
> 
> And rewrite the parsing table to be more explicit:
> 
> static const char * const input_disable_conflicts[] = {
>     "input-enable",
> };
> 
> static const struct pinconf_generic_params dt_params[] = {
>     {
>         .property = "input-disable",
>         .param = PIN_CONFIG_INPUT_ENABLE,
>         .default_value = 0,
>         .conflicting_properties = input_disable_conflicts,
>         .num_conflicting_properties = ARRAY_SIZE(input_disable_conflicts),
>      },
>     (...)
> };
> 
> Then in the loop we can use of_property_present(np, ...) to check for
> conflicting properties when we encounter something.

ngl, I didn't consider something along these lines cos I was trying not
to disrupt how things work at the moment and slot in some non-invasive.
That's probably a bad mindset.

I'm not sure how keen I would be on this of_property_present() idea
though, feels like wasteful to search the dt for conflicting properties
when we are already going through all possible properties and can do the
check at the end, when we've got all the information? Could probably
keep a temporay bitmap, using pin_config_param as the index, and use
test_bit() using the known-incompatibles to check it somewhat neatly?

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)