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: Fri, 9 Jan 2026 08:29:07 -0600 [thread overview]
Message-ID: <20260109142907.GA3059757-robh@kernel.org> (raw)
In-Reply-To: <CAFr9PXn2HzkSRnX4X-X1q2U+zLxwSP=TxvRwmA5eYxad7SbLzw@mail.gmail.com>
On Fri, Jan 09, 2026 at 11:51:52AM +0900, Daniel Palmer wrote:
> Hi Rob,
>
> On Fri, 9 Jan 2026 at 08:38, Rob Herring <robh@kernel.org> wrote:
> >
> > 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.
>
> In core code (like the gpio core, and not in a specific driver) there
> are only a few places. I think around 10.
> There are more when we get into drivers that handle lots of variants
> of the same hardware and check the compatible string during probe.
> (There are ~700 calls to of_device_is_compatible() in drivers/, most
> of which seems to be quirks checking during probe).
Generally in drivers, it is preferred to use match data rather than
of_device_is_compatible(). And if we're going in and touching
of_device_is_compatible() in drivers, that's what we want to do. Using
match data of course doesn't help your cause of reducing size. I suppose
you could define a macro that includes a compatible in the match table
or not. If the match data is function ptrs, then if those functions
aren't referenced, they would be dropped by the compiler.
Rob
next prev parent reply other threads:[~2026-01-09 14:29 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
2026-01-09 2:51 ` Daniel Palmer
2026-01-09 14:29 ` Rob Herring [this message]
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=20260109142907.GA3059757-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