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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8821CC6FA8B for ; Fri, 23 Sep 2022 03:24:33 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MYcvg56kyz3cf5 for ; Fri, 23 Sep 2022 13:24:31 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=benh@kernel.crashing.org; receiver=) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 4MYcvC3Lnxz3bSS for ; Fri, 23 Sep 2022 13:24:05 +1000 (AEST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 28N3LWpA028633; Thu, 22 Sep 2022 22:21:33 -0500 Message-ID: <14c592e1d0a6126a66cfab1851d52d097023b74f.camel@kernel.crashing.org> Subject: Re: [PATCH v2 2/2] powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias From: Benjamin Herrenschmidt To: Michael Ellerman , Guenter Roeck , Pali =?ISO-8859-1?Q?Roh=E1r?= Date: Fri, 23 Sep 2022 13:21:30 +1000 In-Reply-To: <874jyevz2g.fsf@mpe.ellerman.id.au> References: <20220706102148.5060-1-pali@kernel.org> <20220706102148.5060-2-pali@kernel.org> <20220813135735.GA3413265@roeck-us.net> <874jyevz2g.fsf@mpe.ellerman.id.au> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tyrel Datwyler , Guowen Shan , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, "Guilherme G. Piccoli" , Bjorn Helgaas , Paul Mackerras , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, 2022-08-15 at 15:46 +1000, Michael Ellerman wrote: > Guenter Roeck writes: > > On Wed, Jul 06, 2022 at 12:21:48PM +0200, Pali Roh=C3=A1r wrote: > > > Other Linux architectures use DT property 'linux,pci-domain' for spec= ifying > > > fixed PCI domain of PCI controller specified in Device-Tree. > > >=20 > > > And lot of Freescale powerpc boards have defined numbered pci alias i= n > > > Device-Tree for every PCIe controller which number specify preferred = PCI > > > domain. > > >=20 > > > So prefer usage of DT property 'linux,pci-domain' (via function > > > of_get_pci_domain_nr()) and DT pci alias (via function of_alias_get_i= d()) > > > on powerpc architecture for assigning PCI domain to PCI controller. > > >=20 > > > Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on d= evice-tree properties") > > > Signed-off-by: Pali Roh=C3=A1r > >=20 > > This patch results in a number of boot warnings with various qemu > > boot tests. >=20 > Thanks for the report. >=20 > I have automated qemu boot tests to catch things like this, they even > have DEBUG_ATOMIC_SLEEP enabled ... but I inadvertantly broke my script > that checks for "BUG:" in the console log. Sometimes you just can't > win. So the problem is spin_lock(&hose_spinlock); get_phb_number() relies on it for the phb_bitmap allocation. You can move it out of the lock but you'll have to either: - Take the lock inside it to protect the allocation - Turn find_first_zero_bit/set_bit into a loop of find_first_zero_bit+test_and_set_bit() which wouldn't require a lock. Note about the other "reg" numbering conversation ... I'm pretty sure that breaks some old PowerMac crap which shows nobody really uses these things considering how long the patch has been there :-) I'm pretty sure something somewhere assumes the primary bus is 0. Some old userspace definitely does though that might no longer be relevant. The whole business with "domain 0" being special and avoiding domain numbers in /proc relies on this too... Cheers, Ben.