Re: [RFC PATCH 1/2] of: Add a variant of of_device_is_compatible() that can be build time culled

[Saravana Kannan]

On Fri, Jan 9, 2026 at 6:29 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxx> 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.

For the 10 or so instances in the core, I'm not sure the macro is even
worth it. It's just hiding the IS_ENABLED() and obscuring the intent
for not much of a reduction in code size. Not going to Nack it if Rob
agrees, but I don't see the point of the macro. I see the point behind
the idea though.

Also, if we do land it, maybe call it "enabled" instead of "possible"?
That lines up better with IS_ENABLED.

-Saravana

>
> Rob