From: Rob Herring <robh@kernel.org>
To: Daniel Palmer <daniel@thingy.jp>
Cc: linusw@kernel.org, brgl@kernel.org, saravanak@kernel.org,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] of: Add a variant of of_device_is_compatible() that can be build time culled
Date: Thu, 8 Jan 2026 17:38:18 -0600 [thread overview]
Message-ID: <20260108233818.GA1466897-robh@kernel.org> (raw)
In-Reply-To: <20260107030731.1838823-2-daniel@thingy.jp>
On Wed, Jan 07, 2026 at 12:07:30PM +0900, Daniel Palmer wrote:
> In a lot of places we are using of_device_is_compatible() to check for quirks
I'm assuming 'a lot' is not just 3 places? Got a rough estimate?
This seems fine to me assuming there are more.
> etc that are simply not possible on some targets, i.e. a piece of hardware
> that needs special handling is only on one specific ARM machine and your
> target isn't even ARM.
>
> Add of_device_is_possible_and_compatible() that also takes a Kconfig
> symbol and checks if that is enabled before calling of_device_is_compatible().
>
> The Kconfig symbol is build time constant and the compiler should
> remove the call to of_device_is_compatible() if it is unneeded and also
> remove the data for the compatible string.
>
> Another merit of this is that in places were we are checking for quirks
> outside of drivers themselves, i.e. in the gpio and spi subsystems where
> some legacy devicetree handling is being handled for specific devices
> is in the core code, when the drivers that need the quirks are removed
> their Kconfig symbol should also be removed and it'll be easier to spot
> that the quirk handling can also go.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
> include/linux/of.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 9bbdcf25a2b4..70be20b0be22 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -358,6 +358,8 @@ extern int of_property_read_string_helper(const struct device_node *np,
> const char **out_strs, size_t sz, int index);
> extern int of_device_is_compatible(const struct device_node *device,
> const char *);
> +#define of_device_is_possible_and_compatible(symbol, device, string) \
> + (IS_ENABLED(symbol) && of_device_is_compatible(device, string))
> extern int of_device_compatible_match(const struct device_node *device,
> const char *const *compat);
> extern bool of_device_is_available(const struct device_node *device);
> --
> 2.51.0
>
next prev parent reply other threads:[~2026-01-08 23:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 3:07 [RFC PATCH 0/2] Let the compiler remove unneeded compatible checks Daniel Palmer
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 [this message]
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=20260108233818.GA1466897-robh@kernel.org \
--to=robh@kernel.org \
--cc=brgl@kernel.org \
--cc=daniel@thingy.jp \
--cc=devicetree@vger.kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.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