On Wed, May 13, 2026 at 1:03 AM Boris Brezillon <[email protected]> wrote: > > On Tue, 12 May 2026 11:58:30 -0700 > Chia-I Wu <[email protected]> wrote: > > > On Tue, May 12, 2026 at 4:54 AM Boris Brezillon > > <[email protected]> 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 <[email protected]>
