From: Rob Herring <robh+dt@kernel.org> To: "Marek Behun" <marek.behun@nic.cz>, "Pali Rohár" <pali@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, PCI <linux-pci@vger.kernel.org> Subject: Re: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain to zero Date: Thu, 15 Apr 2021 10:13:17 -0500 [thread overview] Message-ID: <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com> (raw) In-Reply-To: <20210415104537.403de52e@thinkpad> On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun@nic.cz> wrote: > > On Thu, 15 Apr 2021 10:36:40 +0200 > Pali Rohár <pali@kernel.org> wrote: > > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote: > > > On Mon, Apr 12, 2021 at 7:41 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove' > > > > function and allow to build it as module") PCIe controller driver for > > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver > > > > allows dynamic binding and unbinding of PCIe controller device. > > > > > > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain > > > > number (starting from zero) for this PCIe controller every time when device > > > > is bound. So PCI domain changes after every unbind / bind operation. > > > > > > PCI host bridges as a module are relatively new, so seems likely a bug to me. > > > > Why a bug? It is there since 5.10 and it is working. I mean historically, the PCI subsystem didn't even support host bridges as a module. They weren't even proper drivers and it was all arch specific code. Most of the host bridge drivers are still built-in only. This seems like a small detail that was easily overlooked. unbind is not a well tested path. > > > > Alternative way for assigning PCI domain number is to use static allocated > > > > numbers defined in Device Tree. This option has requirement that every PCI > > > > controller in system must have defined PCI bus number in Device Tree. > > > > > > That seems entirely pointless from a DT point of view with a single PCI bridge. > > > > If domain id is not specified in DT then kernel uses counter and assigns > > counter++. So it is not pointless if we want to have stable domain id. > > What Rob is trying to say is that > - the bug is that kernel assigns counter++ > - device-tree should not be used to fix problems with how kernel does > things > - if a device has only one PCIe controller, it is pointless to define > it's pci-domain. If there were multiple controllers, then it would > make sense, but there is only one Yes. I think what we want here is a domain bitmap rather than a counter and we assign the lowest free bit. That could also allow for handling a mixture of fixed domain numbers and dynamically assigned ones. You could create scenarios where the numbers change on you, but it wouldn't be any different than say plugging in USB serial adapters. You get the same ttyUSBx device when you re-attach unless there's been other ttyUSBx devices attached/detached. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: "Marek Behun" <marek.behun@nic.cz>, "Pali Rohár" <pali@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, PCI <linux-pci@vger.kernel.org> Subject: Re: [PATCH] arm64: dts: marvell: armada-37xx: Set linux, pci-domain to zero Date: Thu, 15 Apr 2021 10:13:17 -0500 [thread overview] Message-ID: <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com> (raw) In-Reply-To: <20210415104537.403de52e@thinkpad> On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun@nic.cz> wrote: > > On Thu, 15 Apr 2021 10:36:40 +0200 > Pali Rohár <pali@kernel.org> wrote: > > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote: > > > On Mon, Apr 12, 2021 at 7:41 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove' > > > > function and allow to build it as module") PCIe controller driver for > > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver > > > > allows dynamic binding and unbinding of PCIe controller device. > > > > > > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain > > > > number (starting from zero) for this PCIe controller every time when device > > > > is bound. So PCI domain changes after every unbind / bind operation. > > > > > > PCI host bridges as a module are relatively new, so seems likely a bug to me. > > > > Why a bug? It is there since 5.10 and it is working. I mean historically, the PCI subsystem didn't even support host bridges as a module. They weren't even proper drivers and it was all arch specific code. Most of the host bridge drivers are still built-in only. This seems like a small detail that was easily overlooked. unbind is not a well tested path. > > > > Alternative way for assigning PCI domain number is to use static allocated > > > > numbers defined in Device Tree. This option has requirement that every PCI > > > > controller in system must have defined PCI bus number in Device Tree. > > > > > > That seems entirely pointless from a DT point of view with a single PCI bridge. > > > > If domain id is not specified in DT then kernel uses counter and assigns > > counter++. So it is not pointless if we want to have stable domain id. > > What Rob is trying to say is that > - the bug is that kernel assigns counter++ > - device-tree should not be used to fix problems with how kernel does > things > - if a device has only one PCIe controller, it is pointless to define > it's pci-domain. If there were multiple controllers, then it would > make sense, but there is only one Yes. I think what we want here is a domain bitmap rather than a counter and we assign the lowest free bit. That could also allow for handling a mixture of fixed domain numbers and dynamically assigned ones. You could create scenarios where the numbers change on you, but it wouldn't be any different than say plugging in USB serial adapters. You get the same ttyUSBx device when you re-attach unless there's been other ttyUSBx devices attached/detached. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-15 15:17 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-12 12:39 [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain to zero Pali Rohár 2021-04-12 12:39 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux, pci-domain " Pali Rohár 2021-04-13 18:17 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain " Rob Herring 2021-04-13 18:17 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux, pci-domain " Rob Herring 2021-04-15 8:36 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain " Pali Rohár 2021-04-15 8:36 ` Pali Rohár 2021-04-15 8:45 ` Marek Behun 2021-04-15 8:45 ` Marek Behun 2021-04-15 15:13 ` Rob Herring [this message] 2021-04-15 15:13 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux, pci-domain " Rob Herring 2021-04-17 14:49 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain " Pali Rohár 2021-04-17 14:49 ` Pali Rohár 2021-04-17 15:19 ` Andrew Lunn 2021-04-17 15:19 ` Andrew Lunn 2021-04-17 19:42 ` Pali Rohár 2021-04-17 19:42 ` Pali Rohár 2021-04-23 15:33 ` Rob Herring 2021-04-23 15:33 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux, pci-domain " Rob Herring 2021-04-25 15:21 ` [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain " Pali Rohár 2021-04-25 15:21 ` Pali Rohár
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=CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com \ --to=robh+dt@kernel.org \ --cc=andrew@lunn.ch \ --cc=devicetree@vger.kernel.org \ --cc=gregory.clement@bootlin.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=marek.behun@nic.cz \ --cc=pali@kernel.org \ --cc=sebastian.hesselbarth@gmail.com \ /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: linkBe 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.