From: Michael Ellerman <mpe@ellerman.id.au>
To: "Pali Rohár" <pali@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
Date: Thu, 01 Sep 2022 13:53:56 +1000 [thread overview]
Message-ID: <87wnanu4vf.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20220825083713.4glfivegmodluiun@pali>
Pali Rohár <pali@kernel.org> writes:
> On Thursday 25 August 2022 17:49:28 Michael Ellerman wrote:
>> Pali Rohár <pali@kernel.org> writes:
>> > On 32-bit powerpc systems with more PCIe controllers and more PCI domains,
>> > where on more PCI domains are same PCI numbers, when kernel is compiled
>> > with CONFIG_PROC_FS=y and CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT=y
>> > options, kernel prints "proc_dir_entry 'pci/01' already registered" error
>> > message.
>>
>> Thanks, I'll pick this up.
>>
>> > This regression started appearing after commit 566356813082 ("powerpc/pci:
>> > Add config option for using all 256 PCI buses") in case in each mPCIe slot
>> > is connected PCIe card and therefore PCI bus 1 is populated in for every
>> > PCIe controller / PCI domain.
>> >
>> > The reason is that PCI procfs code expects that when PCI bus numbers are
>> > not unique across all PCI domains, function pci_proc_domain() returns true
>> > for domain dependent buses.
>> >
>> > Fix this issue by setting PCI_ENABLE_PROC_DOMAINS and PCI_COMPAT_DOMAIN_0
>> > flags for 32-bit powerpc code when CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> > is enabled. Same approach is already implemented for 64-bit powerpc code
>> > (where PCI bus numbers are always domain dependent).
>>
>> We also have the same in ppc4xx_pci_find_bridges().
>>
>> And if we can eventually make CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> the standard behaviour on 32-bit then everything would behave the same
>> and we could simplify pci_proc_domain() to match what other arches do.
>
> I sent two patches which do another steps to achieve it:
> https://lore.kernel.org/linuxppc-dev/20220817163927.24453-1-pali@kernel.org/t/#u
>
> Main blocker is pci-OF-bus-map which is in direct conflict with
> CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT and which used on chrp and pmac.
> And I have no idea if pci-OF-bus-map is still needed or not.
Yeah thanks, I saw those patches.
I can't find any code that refers to pci-OF-bus-map, so I'm inclined to
remove it entirely.
But I'll do some more searching to see if I can find any references to
it in old code.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Pali Rohár" <pali@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
Date: Thu, 01 Sep 2022 13:53:56 +1000 [thread overview]
Message-ID: <87wnanu4vf.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20220825083713.4glfivegmodluiun@pali>
Pali Rohár <pali@kernel.org> writes:
> On Thursday 25 August 2022 17:49:28 Michael Ellerman wrote:
>> Pali Rohár <pali@kernel.org> writes:
>> > On 32-bit powerpc systems with more PCIe controllers and more PCI domains,
>> > where on more PCI domains are same PCI numbers, when kernel is compiled
>> > with CONFIG_PROC_FS=y and CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT=y
>> > options, kernel prints "proc_dir_entry 'pci/01' already registered" error
>> > message.
>>
>> Thanks, I'll pick this up.
>>
>> > This regression started appearing after commit 566356813082 ("powerpc/pci:
>> > Add config option for using all 256 PCI buses") in case in each mPCIe slot
>> > is connected PCIe card and therefore PCI bus 1 is populated in for every
>> > PCIe controller / PCI domain.
>> >
>> > The reason is that PCI procfs code expects that when PCI bus numbers are
>> > not unique across all PCI domains, function pci_proc_domain() returns true
>> > for domain dependent buses.
>> >
>> > Fix this issue by setting PCI_ENABLE_PROC_DOMAINS and PCI_COMPAT_DOMAIN_0
>> > flags for 32-bit powerpc code when CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> > is enabled. Same approach is already implemented for 64-bit powerpc code
>> > (where PCI bus numbers are always domain dependent).
>>
>> We also have the same in ppc4xx_pci_find_bridges().
>>
>> And if we can eventually make CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> the standard behaviour on 32-bit then everything would behave the same
>> and we could simplify pci_proc_domain() to match what other arches do.
>
> I sent two patches which do another steps to achieve it:
> https://lore.kernel.org/linuxppc-dev/20220817163927.24453-1-pali@kernel.org/t/#u
>
> Main blocker is pci-OF-bus-map which is in direct conflict with
> CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT and which used on chrp and pmac.
> And I have no idea if pci-OF-bus-map is still needed or not.
Yeah thanks, I saw those patches.
I can't find any code that refers to pci-OF-bus-map, so I'm inclined to
remove it entirely.
But I'll do some more searching to see if I can find any references to
it in old code.
cheers
next prev parent reply other threads:[~2022-09-01 3:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-20 11:51 [PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique Pali Rohár
2022-08-20 11:51 ` Pali Rohár
2022-08-25 7:49 ` Michael Ellerman
2022-08-25 7:49 ` Michael Ellerman
2022-08-25 8:37 ` Pali Rohár
2022-08-25 8:37 ` Pali Rohár
2022-09-01 3:53 ` Michael Ellerman [this message]
2022-09-01 3:53 ` Michael Ellerman
2022-09-01 7:24 ` Pali Rohár
2022-09-01 7:24 ` Pali Rohár
2022-09-23 2:57 ` Benjamin Herrenschmidt
2022-09-23 2:57 ` Benjamin Herrenschmidt
2022-08-31 13:12 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wnanu4vf.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=pali@kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.