From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EC3C36F8EF for ; Wed, 13 May 2026 08:03:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778659437; cv=none; b=WuWi3G//62ktQqRLar9d7M4BJ1stL4bQqEBj03+pBkIPL9oHs08j2b0aO1XAJURv+P7dXZhaIYvJE8plLy/wBRn95vdVuVs4PDmn4BBKLfwklo2OMoeAQ/0sSz6qX79hy66elwB2GhoNCYQ1Ri2bI4Ja01j6RidZ+yx5GQkTHUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778659437; c=relaxed/simple; bh=Y5n8bGSKCmrbQEOs6skOF2DzphzSJfvrX+kie9+R5ZU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TZQGPhhrVRMwlchHZbKqcANpcGbBhZFWhyvOWqwn8ulOtQbsWkml7FeOHF2duvHVwDnqtR/+tU0KrlEv7xkluywl3H+38rHRBV3Daxl2vB5RXHdobRnLGAnx8mXdqWPwBPD+bHmje8kSSBr3JCjggkwroEvHMOMymjXhxwbbB98= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=SGTp8Enc; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="SGTp8Enc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1778659434; bh=Y5n8bGSKCmrbQEOs6skOF2DzphzSJfvrX+kie9+R5ZU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SGTp8EncZ2pNhGGGSKy133R65QDloB1ezhhzPTRXS/HjXYOemr6J+luTbkiXNdZ8M 8fextZIRa568Aw967auL48jqVSrULh2jjFQ2AGOU2K1SCICNAVJOiCN8CnbsIQdRx6 7Fp0EUKhWYYqY8u+VbzTgFUtfbKfXlBQJ5Q7P9vdDOfhqZmiFN8qpI+1346IgP2AMV PqcopqIAu+FIA1z3tzqqST2gWx064sJMuxGwwLD2ss/3NDi3hhMEUsRpyNB/9CJ6pP rwQTx+MXpIBn4pfXu8XP9gnRtUtznkdMJoRSWKqF2qU6Jjmu3KFoJtWj4faPbnYOUb gUm72qPRqAz/w== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 0095617E1318; Wed, 13 May 2026 10:03:53 +0200 (CEST) Date: Wed, 13 May 2026 10:03:48 +0200 From: Boris Brezillon To: Chia-I Wu Cc: Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 03/11] drm/panthor: Replace the panthor_irq macro machinery by inline helpers Message-ID: <20260513100348.338c31d6@fedora> In-Reply-To: References: <20260512-panthor-signal-from-irq-v2-0-95c614a739cb@collabora.com> <20260512-panthor-signal-from-irq-v2-3-95c614a739cb@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 12 May 2026 11:58:30 -0700 Chia-I Wu wrote: > On Tue, May 12, 2026 at 4:54=E2=80=AFAM Boris Brezillon > 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. =20 > 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.