Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4626432iob; Sun, 8 May 2022 19:43:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrNfyXNKuLLygvioA8+FumNJgC5mnUp87LP/Ic8Ssw1kPSMXq8kAFDl0VcE2S+89xbdoXu X-Received: by 2002:a17:902:d48c:b0:15e:9f45:c1dd with SMTP id c12-20020a170902d48c00b0015e9f45c1ddmr14186668plg.144.1652064220566; Sun, 08 May 2022 19:43:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652064220; cv=none; d=google.com; s=arc-20160816; b=llM26u3La4b3rHwOLnNC5FTeLik01jhviYTh3/doNNaUnriLpryZ2imE1iHTz/pHV8 82CdyeYhzpIwyemWliVS+5vjo0bADBd8eh/IrA7GVu/jKWUF4PNyqFlYs+KVpJ0JN7r4 KXW3Xff0a1eZSrT9ZxPhguT6HdCEv3NlJHSSyeMDJthhvgX2Tmcs2MnhpWNBJNLjC6OB 0bDFmDkBBrCgB04MuX6bJD5RCaE8nuWJy5KRpj5NAQ/BLMqoZu6cHoN4sOLsr1n3TboG ol9QihbgQimhf/cwjL+rAjOvOwKBEZcPB+m3PLLMXJODfqf3Z49oXr1Vp1FbGGFuMl7F jfhw== 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:subject:cc:to:from:dkim-signature; bh=aRh++ld2M9pM8E9b66cm5fENh7kaTsPFLLWrH3XGTWw=; b=Gz9OFhKldcx/F4891mal1R0gwmpFb+xqOnzOSUrC17GUv78OhV8/HvhDXWcVwNjE3g fA9Lv5REqM/rzTwv4is6Xbv816dGdaz1yIKAKZhyAwViz9JpLjxmqWSsyMWVnheRPGg/ OzapCyDaLaMNWaUjdgut6AwRYt1OMzDQm9ptLYhwqBDLwW80ksE5h9M8c2VVVWSwGNWS Mb3qqa8ueLR5dVNKTwj0biO9l4lQWZso5fZWB7rm07TdM+u/zpHM41CWzOxtyqc6+H0r LTgZXaDoFAHqv6JdJxjL5EjHiWdi5t35PXNfsbwX5xKKaXXm2Jrk8/UmHBbrZuwajgzP w8WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hG+nzQoX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id i132-20020a636d8a000000b003c64ad569fdsi10151165pgc.674.2022.05.08.19.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 19:43:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hG+nzQoX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A2BE82252F; Sun, 8 May 2022 19:43:29 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343510AbiEDS2f (ORCPT + 99 others); Wed, 4 May 2022 14:28:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376740AbiEDS2T (ORCPT ); Wed, 4 May 2022 14:28:19 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D49012BF1 for ; Wed, 4 May 2022 10:58:04 -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 ams.source.kernel.org (Postfix) with ESMTPS id 89D4EB82753 for ; Wed, 4 May 2022 17:58:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 004B7C385A4; Wed, 4 May 2022 17:58:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651687082; bh=wzXnasZ78VhWcyWzDggxLS2kE3GV40WE6obISeL6wYw=; h=From:To:Cc:Subject:Date:From; b=hG+nzQoXWc8YFm5HbNPZHG2c540IC6LcNVKSfVTopvlcryvURcgSido6nfjjgJFYg rz5cOJ/h0cwMlrJXXf2pM1j4PqUD7goQnnu59fBHwwTPF+cv3OQBvbtGg4x12cDgKJ qgaiiOdQHBXBYltqiekwvzctrNcGf2x/lOzD72smxbKJYH9F8hsPcE6QNbfaQNfYQA AdbuCfPQn1rN/8IB+70Qqag+/mIYM2ZX1bs4oyAhgwav8ZdJ2GW58e+YFdPxm5wP8r sZnzqIsiUWWTpJm2W6NV8AznHaV3oK4dhlmpADAHol+sd/OlR5xYb+2PZlmN8Z1pzs iAU6MkBMt4WsQ== Received: by pali.im (Postfix) id 10AEA96D; Wed, 4 May 2022 19:57:59 +0200 (CEST) From: =?UTF-8?q?Pali=20Roh=C3=A1r?= To: Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Bjorn Helgaas Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: [PATCH] powerpc/pci: Add config option for using OF 'reg' for PCI domain Date: Wed, 4 May 2022 19:57:18 +0200 Message-Id: <20220504175718.29011-1-pali@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Since commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties"), powerpc kernel always fallback to PCI domain assignment from OF / Device Tree 'reg' property of the PCI controller. PCI code for other Linux architectures use increasing assignment of the PCI domain for individual controllers (assign the first free number), like it was also for powerpc prior mentioned commit. Upgrading powerpc kernels from LTS 4.4 version (which does not contain mentioned commit) to new LTS versions brings a regression in domain assignment. Fix this issue by introducing a new option CONFIG_PPC_PCI_DOMAIN_FROM_OF_REG When this options is disabled then powerpc kernel would assign PCI domains in the similar way like it is doing kernel for other architectures and also how it was done prior that commit. Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties") Signed-off-by: Pali Rohár --- arch/powerpc/Kconfig | 10 ++++++++++ arch/powerpc/kernel/pci-common.c | 4 ++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 174edabb74fa..4dd3e3acddda 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -375,6 +375,16 @@ config PPC_OF_PLATFORM_PCI depends on PCI depends on PPC64 # not supported on 32 bits yet +config PPC_PCI_DOMAIN_FROM_OF_REG + bool "Use OF reg property for PCI domain" + depends on PCI + help + By default PCI domain for host bridge during its registration is + chosen as the lowest unused PCI domain number. + + When this option is enabled then PCI domain is determined from + the OF / Device Tree 'reg' property. + config ARCH_SUPPORTS_UPROBES def_bool y diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 8bc9cf62cd93..8cb6fc5302ae 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -74,7 +74,6 @@ void __init set_pci_dma_ops(const struct dma_map_ops *dma_ops) static int get_phb_number(struct device_node *dn) { int ret, phb_id = -1; - u32 prop_32; u64 prop; /* @@ -83,7 +82,8 @@ static int get_phb_number(struct device_node *dn) * reading "ibm,opal-phbid", only present in OPAL environment. */ ret = of_property_read_u64(dn, "ibm,opal-phbid", &prop); - if (ret) { + if (ret && IS_ENABLED(CONFIG_PPC_PCI_DOMAIN_FROM_OF_REG)) { + u32 prop_32; ret = of_property_read_u32_index(dn, "reg", 1, &prop_32); prop = prop_32; } -- 2.20.1