linux-kernel - Re: [PATCH] of: property: stop creating callback for each pinctrl-N property

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: <87wm2estty.fsf@prevas.dk>
Date: Mon, 22 Dec 2025 11:18:33 +0100
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Rob Herring <robh@...nel.org>
Cc: Saravana Kannan <saravanak@...gle.com>,  devicetree@...r.kernel.org,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: property: stop creating callback for each pinctrl-N
 property

On Fri, Dec 19 2025, Rob Herring <robh@...nel.org> wrote:

> On Fri, Dec 19, 2025 at 6:18 AM Rasmus Villemoes
> <linux@...musvillemoes.dk> wrote:
>>
>> While not a lot in the grand scheme of things, this eliminates 8*2
>> pointless function calls for almost every property present in the
>> device tree (the exception are the few properties that were already
>> matched). It also seems to reduce .text by about 1.5K - why gcc
>> decides to inline parse_prop_cells() in every instantiation I don't know.
>
> Presumably it is still doing that with all the other cases? Perhaps we
> should add a noinline attr.

Yes, it does, parse_prop_cells() does not exist at all in the generated
code (I've just tested with arm64 defconfig and arm
imx_v6_v7_defconfig).

Adding noinline to just parse_prop_cells (on top of current patch) does

$ size drivers/of/property.o.{old,new}
   text    data     bss     dec     hex filename
  18098     278       0   18376    47c8 drivers/of/property.o.old
  14962     278       0   15240    3b88 drivers/of/property.o.new

There are only two uses of DEFINE_SUFFIX_PROP, so giving
parse_suffix_prop_cells() the same treatment doesn't result in that much
(merely 300 bytes), but should probably be done as well for consistency.

I'll send a proper patch.

>> Supporting double-digit suffixes would still require tweaking, but it
>> does match pinctrl-9.
>
> Looks to me like double-digit suffixes would work. Even pinctrl-0foo
> would work (which is fine IMO).

Ah, yes, if matching ^pinctrl-[0-9] is sufficient and not
^pinctrl-[0-9]+$ (or something even worse to
avoid-leading-0-unless-exactly-0), it does work, and I agree that that's
unlikely to ever be a problem.

Rasmus