linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
To: Marc Zyngier <maz@kernel.org>
Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Frank Rowand <frowand.list@gmail.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	kernel-team@android.com
Subject: Re: [PATCH v2] of: address: Work around missing device_type property in pcie nodes
Date: Wed, 30 Sep 2020 18:27:22 +0200	[thread overview]
Message-ID: <20200930162722.GF1516931@oden.dyn.berto.se> (raw)
In-Reply-To: <20200819094255.474565-1-maz@kernel.org>

Hi Marc,

I'm afraid this commit breaks booting my rk3399 device.

I bisected the problem to this patch merged as [1]. I'm testing on a 
Scarlet device and I'm using the unmodified upstream  
rk3399-gru-scarlet-inx.dtb for my tests.

The problem I'm experience is a black screen after the bootloader and 
the device is none responsive over the network. I have no serial console 
to this device so I'm afraid I can't tell you if there is anything 
useful on to aid debugging there.

If I try to test one commit earlier [2] the system boots as expected and 
everything works as it did for me in v5.8 and earlier. I have worked 
little with this device and have no clue about what is really on the PCI 
buss. But running from [2] I have this info about PCI if it's helpful, 
please ask if somethings missing.

# dmesg | grep -i pci
[    0.003943] PCI/MSI: /interrupt-controller@fee00000/interrupt-controller@fee20000 domain created
[    0.922022] PCI: CLS 0 bytes, default 64
[    0.941517] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[    0.941577] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbefffff -> 0x00fa000000
[    0.941962] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
[    0.941981] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
[    0.942018] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
[    0.942255] rockchip-pcie f8000000.pcie: no vpcie12v regulator found
[    4.196248] ehci-pci: EHCI PCI platform driver
[    4.214639] ohci-pci: OHCI PCI platform driver


# ls /sys/bus/{pci,pci_express}/devices
/sys/bus/pci/devices:

/sys/bus/pci_express/devices:


# ls /sys/bus/{pci,pci_express}/drivers
/sys/bus/pci/drivers:
cavium_rng_pf  cavium_rng_vf  dwc3-haps  ehci-pci  exar_serial  ohci-pci  pcieport  serial  xhci_hcd

/sys/bus/pci_express/drivers:
pcie_pme


# ls /sys/bus/platform/drivers/rockchip-{pcie,pcie-phy}
/sys/bus/platform/drivers/rockchip-pcie:
bind  uevent  unbind

/sys/bus/platform/drivers/rockchip-pcie-phy:
bind  ff770000.syscon:pcie-phy  uevent  unbind

1. d1ac0002dd297069 ("of: address: Work around missing device_type property in pcie nodes")
2. 43647929175e2cd3 ("dt: writing-schema: Miscellaneous grammar fixes")

On 2020-08-19 10:42:55 +0100, Marc Zyngier wrote:
> Recent changes to the DT PCI bus parsing made it mandatory for
> device tree nodes describing a PCI controller to have the
> 'device_type = "pci"' property for the node to be matched.
> 
> Although this follows the letter of the specification, it
> breaks existing device-trees that have been working fine
> for years.  Rockchip rk3399-based systems are a prime example
> of such collateral damage, and have stopped discovering their
> PCI bus.
> 
> In order to paper over it, let's add a workaround to the code
> matching the device type, and accept as PCI any node that is
> named "pcie",
> 
> A warning will hopefully nudge the user into updating their
> DT to a fixed version if they can, but the incentive is
> obviously pretty small.
> 
> Fixes: 2f96593ecc37 ("of_address: Add bus type match for pci ranges parser")
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/of/address.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 590493e04b01..b37bd9cc2810 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -128,15 +128,29 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
>   * PCI bus specific translator
>   */
>  
> +static bool of_node_is_pcie(struct device_node *np)
> +{
> +	bool is_pcie = of_node_name_eq(np, "pcie");
> +
> +	if (is_pcie)
> +		pr_warn_once("%pOF: Missing device_type\n", np);
> +
> +	return is_pcie;
> +}
> +
>  static int of_bus_pci_match(struct device_node *np)
>  {
>  	/*
>   	 * "pciex" is PCI Express
>  	 * "vci" is for the /chaos bridge on 1st-gen PCI powermacs
>  	 * "ht" is hypertransport
> +	 *
> +	 * If none of the device_type match, and that the node name is
> +	 * "pcie", accept the device as PCI (with a warning).
>  	 */
>  	return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
> -		of_node_is_type(np, "vci") || of_node_is_type(np, "ht");
> +		of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
> +		of_node_is_pcie(np);
>  }
>  
>  static void of_bus_pci_count_cells(struct device_node *np,
> -- 
> 2.27.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Niklas Söderlund

  parent reply	other threads:[~2020-09-30 16:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19  9:42 [PATCH v2] of: address: Work around missing device_type property in pcie nodes Marc Zyngier
2020-08-19 22:30 ` Rob Herring
2020-09-30 16:27 ` Niklas Söderlund [this message]
2020-09-30 17:23   ` Marc Zyngier
2020-09-30 17:37     ` Niklas Söderlund
2020-09-30 20:34       ` Rob Herring
2020-09-30 22:51         ` Bjorn Helgaas
2020-09-30 23:48           ` Niklas Söderlund

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=20200930162722.GF1516931@oden.dyn.berto.se \
    --to=niklas.soderlund@ragnatech.se \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=heiko@sntech.de \
    --cc=jiaxun.yang@flygoat.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.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 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).