All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Dionne-Riel <samuel@dionne-riel.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Boot failure on gru-scarlet-inx with 5.9-rc2
Date: Mon, 31 Aug 2020 23:45:42 -0400	[thread overview]
Message-ID: <20200831234542.295b1275@DUFFMAN> (raw)
In-Reply-To: <90731ebb54fe03003dce03bc7ec4872e@kernel.org>

On Mon, 31 Aug 2020 10:27:37 +0100
Marc Zyngier <maz@kernel.org> wrote:
> 
> Ah, so actually anything that *enables pcie* kills your system.
> Great investigative work!
> 
> > 
> > And backed by a further bisection with this that points to
> > d84c572de1a360501d2e439ac632126f5facf59d being the actual change
> > that causes the tablet to fail to boot, as long as the pcie0 node is
> > identified as pci properly.
> > 
> > I am unsure if I should add as a Cc everyone involved in that change
> > set, though the author (coincidentally) is already in the original
> > list of recipients.
> 
> I've deliberately moved Rob from Cc to To... ;-)

Thanks, I don't actually know who to write to exactly.

> > Any additional thoughts from this additional information?  
> 
> What you could do is to start looking at which of the
> pci_is_root_bus() changes breaks PCIe on this system.  The fact that
> it breaks on your system and not on mine is a bit puzzling.

Let me show you, on top of v5.9-rc3 I can successfully boot using this
partial revert / adaptation of d84c572d. In addition, it also allows
the Wi-Fi to work again, compared to how it didn't in 5.9-rc1 or
5.9-rc[23] with the dumb revert of your fix.

So, if we number each pci_is_root_bus by order appearance, it is only
the second use, in rockchip_pcie_valid_device, which seem to cause
scarlet not to boot.

The patch (not actually a patch submission) reverts only that instance
of pci_is_root_bus, while also doing some leg work to put back some
functionally equivalent code that was refactored away since.

If there's anything else you want me to try, don't hesitate.

---
 drivers/pci/controller/pcie-rockchip-host.c | 8 +++++++-
 drivers/pci/controller/pcie-rockchip.h      | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index 0bb2fb3e8a0b..5a27fa833fbd 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -79,7 +79,7 @@ static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
 	 * do not read more than one device on the bus directly attached
 	 * to RC's downstream side.
 	 */
-	if (pci_is_root_bus(bus->parent) && dev > 0)
+	if (bus->primary == rockchip->root_bus_nr && dev > 0)
 		return 0;
 
 	return 1;
@@ -944,6 +944,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 	struct rockchip_pcie *rockchip;
 	struct device *dev = &pdev->dev;
 	struct pci_host_bridge *bridge;
+	struct resource *bus_res;
 	int err;
 
 	if (!dev->of_node)
@@ -983,6 +984,11 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 	if (err < 0)
 		goto err_deinit_port;
 
+	/* HACK; ~equiv to last param of pci_parse_request_of_pci_ranges */
+	bus_res = (resource_list_first_type(&bridge->windows, IORESOURCE_MEM))->res;
+
+	rockchip->root_bus_nr = bus_res->start;
+
 	err = rockchip_pcie_cfg_atu(rockchip);
 	if (err)
 		goto err_remove_irq_domain;
diff --git a/drivers/pci/controller/pcie-rockchip.h b/drivers/pci/controller/pcie-rockchip.h
index c7d0178fc8c2..0952fec7e34d 100644
--- a/drivers/pci/controller/pcie-rockchip.h
+++ b/drivers/pci/controller/pcie-rockchip.h
@@ -298,6 +298,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8      lanes_map;
+	u8      root_bus_nr;
 	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
-- 
2.25.4


Thanks again!

-- 
Samuel Dionne-Riel

  reply	other threads:[~2020-09-01  3:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 20:54 Boot failure on gru-scarlet-inx with 5.9-rc2 Samuel Dionne-Riel
2020-08-30  9:41 ` Marc Zyngier
2020-08-30 20:19   ` Samuel Dionne-Riel
2020-08-31  7:18   ` Samuel Dionne-Riel
2020-08-31  9:27     ` Marc Zyngier
2020-09-01  3:45       ` Samuel Dionne-Riel [this message]
2020-09-01 15:37         ` Marc Zyngier
2020-09-01 16:42           ` Lorenzo Pieralisi
2020-09-01 18:33             ` Samuel Dionne-Riel
2020-09-02 16:01               ` Lorenzo Pieralisi
2020-09-03  3:47                 ` Samuel Dionne-Riel
2020-09-03  9:19                   ` Lorenzo Pieralisi
2020-09-03 14:35                     ` Rob Herring
2020-09-03 15:59                       ` Marc Zyngier
2020-09-03 19:21                         ` Samuel Dionne-Riel

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=20200831234542.295b1275@DUFFMAN \
    --to=samuel@dionne-riel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.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: 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.