From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
Jan Kundr??t <jan.kundrat@cesnet.cz>,
Baruch Siach <baruch@tkos.co.il>,
Jason Cooper <jason@lakedaemon.net>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Mon, 24 Sep 2018 15:10:40 +0200 [thread overview]
Message-ID: <20180924151040.5e57462b@windsurf> (raw)
In-Reply-To: <20180924124620.GA10322@e107981-ln.cambridge.arm.com>
Hello,
On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
> What I think you can do short term, given that AFAICS MVEBU is not
> removable, instead of using pci_host_probe() you move part of its code
> into the driver and make sure that you remap IO as last operation before
> probe completion (ie after scanning the host bridge) so that you do not
> need to unmap it on failure; write a commit log summarising/linking this
> thread please and when v4.20 lands we will give this a more thorough
> look as Russell requested.
>
> How does that sound ?
The only thing that can fail in pci_host_probe() is:
ret = pci_scan_root_bus_bridge(bridge);
if (ret < 0) {
dev_err(bridge->dev.parent, "Scanning root bridge
failed"); return ret;
}
In the pci-mvebu driver prior to the conversion to pci_host_probe(),
the code flow at the end of ->probe() was:
mvebu_pcie_enable()
pci_common_init_dev()
pcibios_init_hw()
and pcibios_init_hw() calls pci_scan_root_bus_bridge(), without doing
much about the return value other than issuing a warning:
ret = pci_scan_root_bus_bridge(bridge);
}
if (WARN(ret < 0, "PCI: unable to scan bus!")) {
pci_free_host_bridge(bridge);
break;
}
I.e, even before the conversion to pci_host_probe(), in case of
failure in pci_scan_root_bus_bridge(), we would have the I/O mapping in
place, but the PCI controller not registered.
We could keep the same (not great) behavior by doing:
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 50eb0729385b..487492f0c5f7 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1179,9 +1179,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
resource_size(&pcie->io) - 1);
pcie->realio.name = "PCI I/O";
- for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K)
- pci_ioremap_io(i, pcie->io.start + i);
-
pci_add_resource(&pcie->resources, &pcie->realio);
}
@@ -1197,7 +1194,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
struct device_node *child;
int num, i, ret;
- bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie));
+ bridge = pci_alloc_host_bridge(sizeof(struct mvebu_pcie));
if (!bridge)
return -ENOMEM;
@@ -1212,8 +1209,10 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
num = of_get_available_child_count(np);
pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
- if (!pcie->ports)
- return -ENOMEM;
+ if (!pcie->ports) {
+ ret = -ENOMEM;
+ goto free_host_bridge;
+ }
i = 0;
for_each_available_child_of_node(np, child) {
@@ -1222,7 +1221,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
ret = mvebu_pcie_parse_port(pcie, port, child);
if (ret < 0) {
of_node_put(child);
- return ret;
+ goto free_host_bridge;
} else if (ret == 0) {
continue;
}
@@ -1268,7 +1267,21 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->align_resource = mvebu_pcie_align_resource;
bridge->msi = pcie->msi;
- return pci_host_probe(bridge);
+ if (resource_size(&pcie->io) != 0) {
+ for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K)
+ pci_ioremap_io(i, pcie->io.start + i);
+ }
+
+ ret = pci_host_probe(bridge);
+ if (ret)
+ pci_free_host_bridge(bridge);
+
+ /* Yes, when pci_host_probe() returns a failure, we don't care */
+ return 0;
+
+free_host_bridge:
+ pci_free_host_bridge(bridge);
+ return ret;
}
static const struct of_device_id mvebu_pcie_of_match_table[] = {
I.e, we simply ignore the failure of pci_host_probe().
To be honest, I really prefer the option of introducing pci_unmap_io().
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@bootlin.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Mon, 24 Sep 2018 15:10:40 +0200 [thread overview]
Message-ID: <20180924151040.5e57462b@windsurf> (raw)
In-Reply-To: <20180924124620.GA10322@e107981-ln.cambridge.arm.com>
Hello,
On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
> What I think you can do short term, given that AFAICS MVEBU is not
> removable, instead of using pci_host_probe() you move part of its code
> into the driver and make sure that you remap IO as last operation before
> probe completion (ie after scanning the host bridge) so that you do not
> need to unmap it on failure; write a commit log summarising/linking this
> thread please and when v4.20 lands we will give this a more thorough
> look as Russell requested.
>
> How does that sound ?
The only thing that can fail in pci_host_probe() is:
ret = pci_scan_root_bus_bridge(bridge);
if (ret < 0) {
dev_err(bridge->dev.parent, "Scanning root bridge
failed"); return ret;
}
In the pci-mvebu driver prior to the conversion to pci_host_probe(),
the code flow at the end of ->probe() was:
mvebu_pcie_enable()
pci_common_init_dev()
pcibios_init_hw()
and pcibios_init_hw() calls pci_scan_root_bus_bridge(), without doing
much about the return value other than issuing a warning:
ret = pci_scan_root_bus_bridge(bridge);
}
if (WARN(ret < 0, "PCI: unable to scan bus!")) {
pci_free_host_bridge(bridge);
break;
}
I.e, even before the conversion to pci_host_probe(), in case of
failure in pci_scan_root_bus_bridge(), we would have the I/O mapping in
place, but the PCI controller not registered.
We could keep the same (not great) behavior by doing:
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 50eb0729385b..487492f0c5f7 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1179,9 +1179,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
resource_size(&pcie->io) - 1);
pcie->realio.name = "PCI I/O";
- for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K)
- pci_ioremap_io(i, pcie->io.start + i);
-
pci_add_resource(&pcie->resources, &pcie->realio);
}
@@ -1197,7 +1194,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
struct device_node *child;
int num, i, ret;
- bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie));
+ bridge = pci_alloc_host_bridge(sizeof(struct mvebu_pcie));
if (!bridge)
return -ENOMEM;
@@ -1212,8 +1209,10 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
num = of_get_available_child_count(np);
pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
- if (!pcie->ports)
- return -ENOMEM;
+ if (!pcie->ports) {
+ ret = -ENOMEM;
+ goto free_host_bridge;
+ }
i = 0;
for_each_available_child_of_node(np, child) {
@@ -1222,7 +1221,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
ret = mvebu_pcie_parse_port(pcie, port, child);
if (ret < 0) {
of_node_put(child);
- return ret;
+ goto free_host_bridge;
} else if (ret == 0) {
continue;
}
@@ -1268,7 +1267,21 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->align_resource = mvebu_pcie_align_resource;
bridge->msi = pcie->msi;
- return pci_host_probe(bridge);
+ if (resource_size(&pcie->io) != 0) {
+ for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K)
+ pci_ioremap_io(i, pcie->io.start + i);
+ }
+
+ ret = pci_host_probe(bridge);
+ if (ret)
+ pci_free_host_bridge(bridge);
+
+ /* Yes, when pci_host_probe() returns a failure, we don't care */
+ return 0;
+
+free_host_bridge:
+ pci_free_host_bridge(bridge);
+ return ret;
}
static const struct of_device_id mvebu_pcie_of_match_table[] = {
I.e, we simply ignore the failure of pci_host_probe().
To be honest, I really prefer the option of introducing pci_unmap_io().
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-09-24 13:10 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 16:11 [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-13 3:19 ` Baruch Siach
2018-09-13 3:19 ` Baruch Siach
2018-09-13 3:19 ` Baruch Siach
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-24 10:02 ` Jan Kundrát
2018-09-24 10:02 ` Jan Kundrát
2018-09-24 10:10 ` Thomas Petazzoni
2018-09-24 10:10 ` Thomas Petazzoni
2018-09-24 10:12 ` Russell King - ARM Linux
2018-09-24 10:12 ` Russell King - ARM Linux
2018-09-24 10:26 ` Thomas Petazzoni
2018-09-24 10:26 ` Thomas Petazzoni
2018-09-24 11:13 ` Russell King - ARM Linux
2018-09-24 11:13 ` Russell King - ARM Linux
2018-09-24 12:12 ` Thomas Petazzoni
2018-09-24 12:12 ` Thomas Petazzoni
2018-09-24 12:46 ` Lorenzo Pieralisi
2018-09-24 12:46 ` Lorenzo Pieralisi
2018-09-24 13:10 ` Thomas Petazzoni [this message]
2018-09-24 13:10 ` Thomas Petazzoni
2018-09-24 14:15 ` Lorenzo Pieralisi
2018-09-24 14:15 ` Lorenzo Pieralisi
2018-09-24 14:52 ` Thomas Petazzoni
2018-09-24 14:52 ` Thomas Petazzoni
2018-09-24 16:42 ` Lorenzo Pieralisi
2018-09-24 16:42 ` Lorenzo Pieralisi
2018-10-01 10:56 ` Jan Kundrát
2018-10-01 10:56 ` Jan Kundrát
2018-10-01 12:51 ` Thomas Petazzoni
2018-10-01 12:51 ` Thomas Petazzoni
2018-10-01 21:01 ` Bjorn Helgaas
2018-10-01 21:01 ` Bjorn Helgaas
2018-09-25 8:18 ` Andrew Murray
2018-09-25 8:18 ` Andrew Murray
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=20180924151040.5e57462b@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=baruch@tkos.co.il \
--cc=bhelgaas@google.com \
--cc=jan.kundrat@cesnet.cz \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.pieralisi@arm.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: 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.