linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2018-09-24 13:10 UTC|newest]

Thread overview: 24+ 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 18:49 ` Baruch Siach
2018-09-12 18:50   ` Thomas Petazzoni
2018-09-12 19:00     ` Jan Kundrát
2018-09-12 23:10   ` Russell King - ARM Linux
2018-09-13  3:19     ` Baruch Siach
2018-09-13  7:45     ` Thomas Petazzoni
2018-09-13  8:20       ` Jan Kundrát
2018-09-13  8:42         ` Thomas Petazzoni
2018-09-24 10:02           ` Jan Kundrát
2018-09-24 10:10             ` Thomas Petazzoni
2018-09-24 10:12           ` Russell King - ARM Linux
2018-09-24 10:26             ` Thomas Petazzoni
2018-09-24 11:13               ` Russell King - ARM Linux
2018-09-24 12:12                 ` Thomas Petazzoni
2018-09-24 12:46                   ` Lorenzo Pieralisi
2018-09-24 13:10                     ` Thomas Petazzoni [this message]
2018-09-24 14:15                       ` Lorenzo Pieralisi
2018-09-24 14:52                         ` Thomas Petazzoni
2018-09-24 16:42                           ` Lorenzo Pieralisi
2018-10-01 10:56                           ` Jan Kundrát
2018-10-01 12:51                             ` Thomas Petazzoni
2018-10-01 21:01                               ` Bjorn Helgaas
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=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).