From: Robin Murphy <robin.murphy@arm.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH] pinctrl: Remove hole in pinctrl_gpio_range
Date: Thu, 5 Nov 2020 14:54:21 +0000 [thread overview]
Message-ID: <77bc14cd-7e47-6972-ee0b-fa72bb9e9fad@arm.com> (raw)
In-Reply-To: <CACRpkdayhrcfyXEB4P+apjOyF=8DZgmu=_H8+aQEr4XEbB0NeQ@mail.gmail.com>
On 2020-11-05 13:57, Linus Walleij wrote:
> On Wed, Oct 28, 2020 at 3:51 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>
>> On 64-bit platforms, pointer size and alignment are 64-bit, hence two
>> 4-byte holes are present before the pins and gc members of the
>> pinctrl_gpio_range structure. Get rid of these holes by moving the
>> pins pointer.
>>
>> This reduces kernel size of an arm64 Rockchip kernel by ca. 512 bytes.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Compile-tested only (arm/multi_v7_defconfig and arm64/defconfig).
>
> Patch applied.
>
> Do you think it'd be worth it to add a check to checkpatch to suggest
> to move pointers toward the end of any struct?
For a general rule, I thought that ordering struct members largest-first
was the conventional wisdom, since that way no sensible compiler would
add padding between any members, only at the end?
That said, the trouble with any checkpatch rule is that people will
inevitably try to apply it indiscriminately. With structure layout, that
could often end up hurting readability and/or performance (via cache
effects), while in many cases making no actual difference to the overall
size anyway.
Robin.
prev parent reply other threads:[~2020-11-05 14:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 14:51 Geert Uytterhoeven
2020-11-05 13:57 ` Linus Walleij
2020-11-05 14:54 ` Robin Murphy [this message]
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=77bc14cd-7e47-6972-ee0b-fa72bb9e9fad@arm.com \
--to=robin.murphy@arm.com \
--cc=geert+renesas@glider.be \
--cc=heiko@sntech.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.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
all inboxes | Powered by JetHome®