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;
From:   Michael Ellerman <mpe@ellerman.id.au>
To:     Guenter Roeck <linux@roeck-us.net>,
        Pali =?utf-8?Q?Roh=C3=A1r?= <pali@kernel.org>
Cc:     Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
        Bjorn Helgaas <helgaas@kernel.org>,
        Guowen Shan <gshan@redhat.com>,
        Tyrel Datwyler <tyreld@linux.ibm.com>,
        linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] powerpc/pci: Prefer PCI domain assignment via DT
 'linux,pci-domain' and alias
In-Reply-To: <20220813135735.GA3413265@roeck-us.net>
References: <20220706102148.5060-1-pali@kernel.org>
 <20220706102148.5060-2-pali@kernel.org>
 <20220813135735.GA3413265@roeck-us.net>
Date:   Mon, 15 Aug 2022 15:46:31 +1000
Message-ID: <874jyevz2g.fsf@mpe.ellerman.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Guenter Roeck <linux@roeck-us.net> 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 specify=
ing
>> fixed PCI domain of PCI controller specified in Device-Tree.
>>=20
>> And lot of Freescale powerpc boards have defined numbered pci alias in
>> 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_id())
>> on powerpc architecture for assigning PCI domain to PCI controller.
>>=20
>> Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on devi=
ce-tree properties")
>> Signed-off-by: Pali Roh=C3=A1r <pali@kernel.org>
>
> This patch results in a number of boot warnings with various qemu
> boot tests.

Thanks for the report.

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.

cheers