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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRMN=ecP3aJSEwSWrmBDH+dP0F9kQLAjESBswfDu4HBJh-Jhw@mail.gmail.com>
Date: Sun, 11 Jan 2026 18:32:43 -0800
From: Saravana Kannan <saravanak@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Daniel Palmer <daniel@...ngy.jp>, linusw@...nel.org, brgl@...nel.org, 
	saravanak@...nel.org, linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] of: Add a variant of of_device_is_compatible()
 that can be build time culled

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

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