public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Palmer <daniel@thingy.jp>
To: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
	saravanak@kernel.org, linux-gpio@vger.kernel.org,
	devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Daniel Palmer <daniel@thingy.jp>
Subject: [RFC PATCH 0/2] Let the compiler remove unneeded compatible checks.
Date: Wed,  7 Jan 2026 12:07:29 +0900	[thread overview]
Message-ID: <20260107030731.1838823-1-daniel@thingy.jp> (raw)

I like devicetree but I dislike the way it removes the compiler's ability
to remove dead code because the compiler can't know what is in the runtime
devicetree.

One common pattern is checking if a node is compatible with some compatible
string that should never happen on the target machine. i.e checking for
something that only exists on a very specific PPC platform on ARM etc.

For weird people like me that want to run Linux on FPGA softcores, processors
from 1979 etc it is better to have the most minimal kernel config possible and
for the compiler to strip out as much unneeded code and data as possible.

The following is my quick hack to add a way to hint to the compiler whether
a specific compatible check is even possible or not so it can remove deadcode
and then an example usecase.

I think this is cleaner than #ifdef..#endif all over the place but maybe
someone has a nicer way to do it.

Daniel Palmer (2):
  of: Add a variant of of_device_is_compatible() that can be build time
    culled
  gpiolib: of: Remove a bunch of compatible checks for spi controllers
    you don't have

 drivers/gpio/gpiolib-of.c | 6 +++---
 include/linux/of.h        | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.51.0


             reply	other threads:[~2026-01-07  3:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07  3:07 Daniel Palmer [this message]
2026-01-07  3:07 ` [RFC PATCH 1/2] of: Add a variant of of_device_is_compatible() that can be build time culled Daniel Palmer
2026-01-08 23:38   ` Rob Herring
2026-01-09  2:51     ` Daniel Palmer
2026-01-09 14:29       ` Rob Herring
2026-01-12  2:32         ` Saravana Kannan
2026-01-12  3:10           ` Daniel Palmer
2026-01-11 10:59       ` Linus Walleij
2026-01-07  3:07 ` [RFC PATCH 2/2] gpiolib: of: Remove a bunch of compatible checks for spi controllers you don't have Daniel Palmer
2026-01-07  8:17 ` [RFC PATCH 0/2] Let the compiler remove unneeded compatible checks Bartosz Golaszewski

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=20260107030731.1838823-1-daniel@thingy.jp \
    --to=daniel@thingy.jp \
    --cc=brgl@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=saravanak@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