Re: [PATCH v2 03/11] drm/panthor: Replace the panthor_irq macro machinery by inline helpers

[Chia-I Wu <olvaffe@gmail.com>]

On Wed, May 13, 2026 at 1:03 AM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
>
> On Tue, 12 May 2026 11:58:30 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > On Tue, May 12, 2026 at 4:54 AM Boris Brezillon
> > <boris.brezillon@collabora.com> wrote:
> > >
> > > Now that panthor_irq contains the iomem region, there's no real need
> > > for the macro-based panthor_irq helper generation logic. We can just
> > > provide inline helpers that do the same and let the compiler optimize
> > > indirect function calls. The only extra annoyance is the fact we have
> > > to open-code the panthor_xxx_irq_threaded_handler() implementation, but
> > > those are single-line functions, so it's acceptable.
> > We might want to __always_inline panthor_irq_default_threaded_handler.
>
> Yep, I can flag it __always_inline, but I'd be surprised if the
> compiler wasn't always inlining anyway, unless you use more exotic
> optimization options, like -Os (not even sure that would be the case
> with -Os, I didn't check), at which point it becomes a user decision,
> and not inlining is probably fine.
>
> > For the rest, do we want to un-inline them?
>
> Most of them are super trivial, and I think there's benefit in having
> them inlined. Again, because it's not __always_inline, the compiler is
> still free to unline, but at least we wouldn't resort to LTO for this
> sort of inlining optimization. So I'm still tempted to keep it as
> static inline helpers defined in the header file, unless you a strong
> reason to think this is a bad idea.
No, no strong reason just that the rest are not hot enough to inline.
But there is no harm to inline so

Reviewed-by: Chia-I Wu <olvaffe@gmail.com>