Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp591112imn; Tue, 26 Jul 2022 04:28:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t5aFWXwYdHlX2gW/mTgwZomfQ2uNpU6pbbW1FK9yOajUqEsiiorsDiv+8G841PxtY3IL3V X-Received: by 2002:a17:907:2807:b0:72b:4530:29d5 with SMTP id eb7-20020a170907280700b0072b453029d5mr14193792ejc.69.1658834891109; Tue, 26 Jul 2022 04:28:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658834891; cv=none; d=google.com; s=arc-20160816; b=kWlpEtrnvl8JDB2XXXk0CU+QFbEOmMxWU31MQ7jZVo+318Tweilc4yi1nzCmPxVf4n KithbB7S5RqXbXECHuLSbIATa5A8mjFy1HRv1nRrbtN5yuCaiTfFZDlrQhulBEtLefG5 RiwjR0V7q5VDXfROoy6emVmkU04n6yzj9dEvO47z5yVnLTBSIF3gaMY/nc+gFkLcv7z5 b4GLifLr97ZbFL7vm26lq8ZYgSvpYLvsSfEnW0xU+cus3LSVWQI0BIQpJpxeYqHxyGwG 4iBPtlafESvAmVyWJcnDYaexfu31EZAD0KohdqUnmwKYAnVMc3Jn5roXpHXG1eB8i/7H D52g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :dkim-signature; bh=Z49lCisQT1XGo/W63rwonF77hiwakcBinHGr63WmR34=; b=fH66fJzhh3uHVt/9xXkkjFY2aoIv6ec+vcDk7WCc9+P/pkPHchXAG6ztoStAoNm2SW QQfTeU/Tv0mu3XU1yQdgUDTlGwFdJsu8bTgbJIXwKEWbKYaSAgb1fKnspidGbDnyt1S6 yHFN4bVcb7jiL4liLPbWKn9bDrh/dooGwT9lhz0V884jyD/f/oTy+IbQQ3GEpdVh1MXZ qOZMZ8sP8ZTjzFaSrZV49KzjJA43XRiXNJjsfjix5aiSDmzTiFs7D6jRxvOA+mjZ7aZ4 OS5E/wReD0Ed9ka8Y8t7ojXiQ5iqaOcP5j+T+JgS0o1+i6JmVXrQ4d/E+pnMMXydIwb7 5hAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=VIqiqukv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ev7-20020a17090729c700b00726d6cb0258si12844716ejc.263.2022.07.26.04.27.45; Tue, 26 Jul 2022 04:28:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=VIqiqukv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232449AbiGZLC1 (ORCPT + 99 others); Tue, 26 Jul 2022 07:02:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231335AbiGZLC0 (ORCPT ); Tue, 26 Jul 2022 07:02:26 -0400 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 360D62DA9C; Tue, 26 Jul 2022 04:02:25 -0700 (PDT) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4LsYsC27Jjz4x1Y; Tue, 26 Jul 2022 21:02:23 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1658833343; bh=Z49lCisQT1XGo/W63rwonF77hiwakcBinHGr63WmR34=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VIqiqukvv7kNj6LxEW2+NpOztZFjRnVc1oTOXVSlIjng1+/SCGGHTSo1KD1P8NNoX g8fn0YgV4CCHgiDXxG9MPnVvkalfY/REjBuVc3HJ0QZ7PpBaMU4RPYu+c/g9iTzamS UdqWiARKxEz0VE4wITkHbNPrtxoE4e2iuYDCnOVoqj+1AWVxacZDnMRe0+T/o3tK0v uRxwkwDIHGahnKILz4upboHU+K4wSZn+le7zTf+HfilopsllFI+Cw51t80JSwKHTf6 cT9hCkygPwgV7DsLwYv/oINpPSTQZAG7D0EEdbH25mixqRv+qxulEZYHmfs0DwfGcp IgzCS3IakIyPw== From: Michael Ellerman To: Pali =?utf-8?Q?Roh=C3=A1r?= , Benjamin Herrenschmidt , Paul Mackerras , Christophe Leroy , =?utf-8?Q?C=C3=A9dric?= Le Goater , Nick Child , Bjorn Helgaas Cc: linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] powerpc/pci: Add config option for using all 256 PCI buses In-Reply-To: <20220721222145.rzgthbwoselx2l43@pali> References: <20220706104308.5390-1-pali@kernel.org> <20220706104308.5390-6-pali@kernel.org> <20220721222145.rzgthbwoselx2l43@pali> Date: Tue, 26 Jul 2022 21:02:22 +1000 Message-ID: <875yjkb0ht.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pali Roh=C3=A1r writes: > On Wednesday 06 July 2022 12:43:08 Pali Roh=C3=A1r wrote: >> By default on PPC32 are PCI bus numbers unique across all PCI domains. >> So system could have only 256 PCI buses independently of available >> PCI domains. >> >> This is due to filling DT property pci-OF-bus-map which does not reflect >> multi-domain setup. >> >> On all powerpc platforms except chrp and powermac there is no DT property >> pci-OF-bus-map anymore and therefore it is possible on non-chrp/powermac >> platforms to avoid this limitation of maximal number of 256 PCI buses in >> system even on multi-domain setup. >> >> But avoiding this limitation would mean that all PCI and PCIe devices wo= uld >> be present on completely different BDF addresses as every PCI domain sta= rts >> numbering PCI bueses from zero (instead of the last bus number of previo= us >> enumerated PCI domain). Such change could break existing software which >> expects fixed PCI bus numbers. >> >> So add a new config option CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT which >> enables this change. By default it is disabled. It cause that initial va= lue >> of hose->first_busno is zero. >> >> Signed-off-by: Pali Roh=C3=A1r >> --- >> arch/powerpc/Kconfig | 11 +++++++++++ >> arch/powerpc/kernel/pci_32.c | 6 ++++++ >> 2 files changed, 17 insertions(+) >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index be68c1f02b79..f66084bc1dfe 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -370,6 +370,17 @@ config PPC_DCR >> depends on PPC_DCR_NATIVE || PPC_DCR_MMIO >> default y >> >> +config PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT >> + depends on PPC32 >> + depends on !PPC_PMAC && !PPC_CHRP >> + bool "Assign PCI bus numbers from zero individually for each PCI domai= n" >> + help >> + By default on PPC32 were PCI bus numbers unique across all PCI domai= ns. >> + So system could have only 256 PCI buses independently of available >> + PCI domains. When this option is enabled then PCI bus numbers are >> + PCI domain dependent and each PCI controller on own domain can have >> + 256 PCI buses, like it is on other Linux architectures. >> + > > What do you think, would it be possible to set default value of this > option to enabled? My preference would be to not have the option at all, just make it the default behaviour. Every new CONFIG option adds more combinations that need testing, or more likely don't get well tested. But I don't have a good feel for what could break if we turn it on, so honestly I don't really know. Also I do most of my 32-bit testing on pmacs, which are not affected by the change. So I'll probably take the series as-is, and then we can do some more widespread testing and possibly flip the default to enabled, and then maybe remove the option entirely in future. cheers