public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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

  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