From: Andrew Murray <andrew.murray@arm.com> To: Rob Herring <robh@kernel.org> Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Ley Foon Tan <lftan@altera.com>, rfi@lists.rocketboards.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 02/11] PCI: altera: Use pci_parse_request_of_pci_ranges() Date: Mon, 30 Sep 2019 16:13:47 +0100 [thread overview] Message-ID: <20190930151346.GD42880@e119886-lin.cambridge.arm.com> (raw) In-Reply-To: <CAL_JsqKN709cOLtDLdKXmDzeNLYtGekMT2BiZic4x45UopenwA@mail.gmail.com> On Wed, Sep 25, 2019 at 07:33:35AM -0500, Rob Herring wrote: > On Wed, Sep 25, 2019 at 5:24 AM Andrew Murray <andrew.murray@arm.com> wrote: > > > > On Tue, Sep 24, 2019 at 04:46:21PM -0500, Rob Herring wrote: > > > Convert altera host bridge to use the common > > > pci_parse_request_of_pci_ranges(). > > > > > > Cc: Ley Foon Tan <lftan@altera.com> > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > > > Cc: Bjorn Helgaas <bhelgaas@google.com> > > > Cc: rfi@lists.rocketboards.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > > @@ -833,9 +800,8 @@ static int altera_pcie_probe(struct platform_device *pdev) > > > return ret; > > > } > > > > > > - INIT_LIST_HEAD(&pcie->resources); > > > - > > > - ret = altera_pcie_parse_request_of_pci_ranges(pcie); > > > + ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources, > > > > Does it matter that we now map any given IO ranges whereas we didn't > > previously? > > > > As far as I can tell there are no users that pass an IO range, if they > > did then with the existing code the probe would fail and they'd get > > a "I/O range found for %pOF. Please provide an io_base pointer...". > > However with the new code if any IO range was given (which would > > probably represent a misconfiguration), then we'd proceed to map the > > IO range. When that IO is used, who knows what would happen. > > Yeah, I'm assuming that the DT doesn't have an IO range if IO is not > supported. IMO, it is not the kernel's job to validate the DT. Sure. Is it worth mentioning in the commit message this subtle change in behaviour? > > > I wonder if there is a better way for a host driver to indicate that > > it doesn't support IO? > > We can probably test for this in the schema. > > ranges: > items: > minItems: 7 > items: > - not: { const: 0x01000000 } > > Or "- enum: [ 0x42000000, 0x02000000 ]" > > Of course, in theory, the bus, dev, fn fields could be non-zero and we > could use minium/maximum to handle those, but in practice I think they > are rarely used for FDT. Many controllers also appear to set the top bit (relocatable), e.g. 0x82000000... At present there are no PCI bindings that use the YAML schema, if I've understood correctly. Thanks, Andrew Murray > > Rob
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Murray <andrew.murray@arm.com> To: Rob Herring <robh@kernel.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, linux-pci@vger.kernel.org, rfi@lists.rocketboards.org, Bjorn Helgaas <bhelgaas@google.com>, Ley Foon Tan <lftan@altera.com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 02/11] PCI: altera: Use pci_parse_request_of_pci_ranges() Date: Mon, 30 Sep 2019 16:13:47 +0100 [thread overview] Message-ID: <20190930151346.GD42880@e119886-lin.cambridge.arm.com> (raw) In-Reply-To: <CAL_JsqKN709cOLtDLdKXmDzeNLYtGekMT2BiZic4x45UopenwA@mail.gmail.com> On Wed, Sep 25, 2019 at 07:33:35AM -0500, Rob Herring wrote: > On Wed, Sep 25, 2019 at 5:24 AM Andrew Murray <andrew.murray@arm.com> wrote: > > > > On Tue, Sep 24, 2019 at 04:46:21PM -0500, Rob Herring wrote: > > > Convert altera host bridge to use the common > > > pci_parse_request_of_pci_ranges(). > > > > > > Cc: Ley Foon Tan <lftan@altera.com> > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > > > Cc: Bjorn Helgaas <bhelgaas@google.com> > > > Cc: rfi@lists.rocketboards.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > > @@ -833,9 +800,8 @@ static int altera_pcie_probe(struct platform_device *pdev) > > > return ret; > > > } > > > > > > - INIT_LIST_HEAD(&pcie->resources); > > > - > > > - ret = altera_pcie_parse_request_of_pci_ranges(pcie); > > > + ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources, > > > > Does it matter that we now map any given IO ranges whereas we didn't > > previously? > > > > As far as I can tell there are no users that pass an IO range, if they > > did then with the existing code the probe would fail and they'd get > > a "I/O range found for %pOF. Please provide an io_base pointer...". > > However with the new code if any IO range was given (which would > > probably represent a misconfiguration), then we'd proceed to map the > > IO range. When that IO is used, who knows what would happen. > > Yeah, I'm assuming that the DT doesn't have an IO range if IO is not > supported. IMO, it is not the kernel's job to validate the DT. Sure. Is it worth mentioning in the commit message this subtle change in behaviour? > > > I wonder if there is a better way for a host driver to indicate that > > it doesn't support IO? > > We can probably test for this in the schema. > > ranges: > items: > minItems: 7 > items: > - not: { const: 0x01000000 } > > Or "- enum: [ 0x42000000, 0x02000000 ]" > > Of course, in theory, the bus, dev, fn fields could be non-zero and we > could use minium/maximum to handle those, but in practice I think they > are rarely used for FDT. Many controllers also appear to set the top bit (relocatable), e.g. 0x82000000... At present there are no PCI bindings that use the YAML schema, if I've understood correctly. Thanks, Andrew Murray > > 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:[~2019-09-30 15:13 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-24 21:46 [PATCH 00/11] PCI dma-ranges parsing consolidation Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-24 21:46 ` [PATCH 01/11] PCI: aardvark: Use pci_parse_request_of_pci_ranges() Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-25 8:59 ` Thomas Petazzoni 2019-09-25 8:59 ` Thomas Petazzoni 2019-09-25 9:04 ` Andrew Murray 2019-09-25 9:04 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 02/11] PCI: altera: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-25 10:24 ` Andrew Murray 2019-09-25 10:24 ` Andrew Murray 2019-09-25 12:33 ` Rob Herring 2019-09-25 12:33 ` Rob Herring 2019-09-30 15:13 ` Andrew Murray [this message] 2019-09-30 15:13 ` Andrew Murray 2019-09-30 17:36 ` Rob Herring 2019-09-30 17:36 ` Rob Herring 2019-10-15 11:02 ` Lorenzo Pieralisi 2019-10-15 11:02 ` Lorenzo Pieralisi 2019-10-15 11:17 ` Rob Herring 2019-10-15 11:17 ` Rob Herring 2019-09-24 21:46 ` [PATCH 03/11] PCI: mediatek: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-25 11:34 ` Andrew Murray 2019-09-25 11:34 ` Andrew Murray 2019-09-25 11:34 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 04/11] PCI: versatile: Enable COMPILE_TEST Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:12 ` Andrew Murray 2019-09-26 8:12 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 05/11] PCI: versatile: Use pci_parse_request_of_pci_ranges() Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-25 10:37 ` Andrew Murray 2019-09-25 10:37 ` Andrew Murray 2019-09-26 21:44 ` Rob Herring 2019-09-26 21:44 ` Rob Herring 2019-09-30 15:16 ` Andrew Murray 2019-09-30 15:16 ` Andrew Murray 2019-09-30 16:56 ` Peter Maydell 2019-09-30 16:56 ` Peter Maydell 2019-09-30 19:36 ` Andrew Murray 2019-09-30 19:36 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 06/11] PCI: of: Add inbound resource parsing to helpers Rob Herring 2020-01-13 9:56 ` Bharat Kumar Gogada 2020-01-13 9:56 ` Bharat Kumar Gogada 2019-09-24 21:46 ` Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-25 9:00 ` Thomas Petazzoni 2019-09-25 9:00 ` Thomas Petazzoni 2019-09-25 9:00 ` Thomas Petazzoni 2019-09-26 8:29 ` Andrew Murray 2019-09-26 8:29 ` Andrew Murray 2019-09-26 8:29 ` Andrew Murray 2019-09-26 10:43 ` Gustavo Pimentel 2019-09-26 10:43 ` Gustavo Pimentel 2019-09-26 10:43 ` Gustavo Pimentel 2019-09-27 16:12 ` Jingoo Han 2019-09-27 16:12 ` Jingoo Han 2019-09-27 16:12 ` Jingoo Han 2019-09-27 16:12 ` Jingoo Han 2019-09-27 16:12 ` Jingoo Han 2019-09-27 16:12 ` Jingoo Han 2019-09-24 21:46 ` [PATCH 07/11] PCI: ftpci100: Use inbound resources for setup Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:39 ` Andrew Murray 2019-09-26 8:39 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 08/11] PCI: v3-semi: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:39 ` Andrew Murray 2019-09-26 8:39 ` Andrew Murray 2019-09-30 22:00 ` Linus Walleij 2019-09-30 22:00 ` Linus Walleij 2019-09-24 21:46 ` [PATCH 09/11] PCI: xgene: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:39 ` Andrew Murray 2019-09-26 8:39 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 10/11] PCI: iproc: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:39 ` Andrew Murray 2019-09-26 8:39 ` Andrew Murray 2019-09-24 21:46 ` [PATCH 11/11] PCI: rcar: " Rob Herring 2019-09-24 21:46 ` Rob Herring 2019-09-26 8:47 ` Andrew Murray 2019-09-26 8:47 ` Andrew Murray 2019-09-26 12:53 ` Rob Herring 2019-09-26 12:53 ` Rob Herring 2019-09-26 13:32 ` Andrew Murray 2019-09-26 13:32 ` Andrew Murray 2019-09-26 8:49 ` [PATCH 00/11] PCI dma-ranges parsing consolidation Andrew Murray 2019-09-26 8:49 ` Andrew Murray 2019-09-26 8:49 ` Andrew Murray 2019-09-26 11:20 ` Marc Gonzalez 2019-09-26 11:20 ` Marc Gonzalez 2019-09-26 13:11 ` Rob Herring 2019-09-26 13:11 ` Rob Herring 2019-09-26 13:38 ` Andrew Murray 2019-09-26 13:38 ` Andrew Murray 2019-09-26 14:09 ` Marc Gonzalez 2019-09-26 14:09 ` Marc Gonzalez
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=20190930151346.GD42880@e119886-lin.cambridge.arm.com \ --to=andrew.murray@arm.com \ --cc=bhelgaas@google.com \ --cc=lftan@altera.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=rfi@lists.rocketboards.org \ --cc=robh@kernel.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: 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.