From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D00B6C7EE2E for ; Thu, 25 May 2023 09:09:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240585AbjEYJJY (ORCPT ); Thu, 25 May 2023 05:09:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240568AbjEYJJJ (ORCPT ); Thu, 25 May 2023 05:09:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6F911BD; Thu, 25 May 2023 02:09:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3E27663EA9; Thu, 25 May 2023 09:09:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AE82C433D2; Thu, 25 May 2023 09:09:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685005741; bh=Pr1Z7hahvR2wlxLXPqicbt5H+1yJnuTZUwPfbmuuluc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QP7gZmWqe3/px6ncAg2fvmUlfqchyLPGgdt9IKsWG32yeMXwcQ81xdXLej5hOcYJy fiPck0i8KZX7OmzMb7h60mWM9fadgAAQ5CRd/7RWVoCDWzF3DwHfAJyszx4ntorE7t T0morEGtnG5o9rZnPLNiMDCE63q3PlGk8PyRMMWfJQLtBnGsImM3VkWnAkv/gyXLgo TYodG8ZWbl9XxFdcSsIhPmvs+dsf41c6Vu59TihailvF3IaMG7bm6Z5ZAKGv7rt1hj pYi56BXXgXrhcWFF/FrAUNqeAjknprqHu2Gx0yFUk13U/x5f2N/fyJ38n17IEqcAsF IWT2q5rngPB8Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1q26xt-000G5l-V2; Thu, 25 May 2023 10:08:59 +0100 Date: Thu, 25 May 2023 10:08:57 +0100 Message-ID: <86o7m8dbh2.wl-maz@kernel.org> From: Marc Zyngier To: Bjorn Helgaas Cc: Huacai Chen , Bjorn Helgaas , Thomas Gleixner , "Ahmed S . Darwish" , Jason Gunthorpe , Kevin Tian , linux-pci@vger.kernel.org, Jianmin Lv , Huacai Chen , Jiaxun Yang , loongson-kernel@lists.loongnix.cn, Juxin Gao , linux-kernel@vger.kernel.org Subject: Re: [PATCH] pci: irq: Add an early parameter to limit pci irq numbers In-Reply-To: References: <20230524093623.3698134-1-chenhuacai@loongson.cn> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: helgaas@kernel.org, chenhuacai@loongson.cn, bhelgaas@google.com, tglx@linutronix.de, darwi@linutronix.de, jgg@ziepe.ca, kevin.tian@intel.com, linux-pci@vger.kernel.org, lvjianmin@loongson.cn, chenhuacai@gmail.com, jiaxun.yang@flygoat.com, loongson-kernel@lists.loongnix.cn, gaojuxin@loongson.cn, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 May 2023 16:21:09 +0100, Bjorn Helgaas wrote: > > [+cc Marc, LKML] > > On Wed, May 24, 2023 at 05:36:23PM +0800, Huacai Chen wrote: > > Some platforms (such as LoongArch) cannot provide enough irq numbers as > > many as logical cpu numbers. So we should limit pci irq numbers when > > allocate msi/msix vectors, otherwise some device drivers may fail at > > initialization. This patch add a cmdline parameter "pci_irq_limit=xxxx" > > to control the limit. > > > > The default pci msi/msix number limit is defined 32 for LoongArch and > > NR_IRQS for other platforms. > > The IRQ experts can chime in on this, but this doesn't feel right to > me. I assume arch code should set things up so only valid IRQ numbers > can be allocated. This doesn't seem necessarily PCI-specific, I'd > prefer to avoid an arch #ifdef here, and I'd also prefer to avoid a > command-line parameter that users have to discover and supply. I'd tend to agree. The irqchip driver that provides the interrupt numbers should perform the capping, not the core PCI code. Furthermore, MSI allocation is never guaranteed anyway, and drivers shouldn't expect to get all the interrupts they request. If they do, they need fixing. Overall, interrupt architectures that provide as few as 32 possible interrupts for MSIs will be crippled, and there isn't much we can do about it. This also applies to a large number of ARM systems that use the Designware IP. M. -- Without deviation from the norm, progress is not possible.