Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp402202ybf; Wed, 26 Feb 2020 15:26:25 -0800 (PST) X-Google-Smtp-Source: APXvYqzSZ0gfixSOOYTLN+KigOlWcGWh5pbDW1yXlURiRoCsivAxMUlIN94tfkgPhyc2pkOOhYLZ X-Received: by 2002:a9d:7a56:: with SMTP id z22mr953675otm.201.1582759585000; Wed, 26 Feb 2020 15:26:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582759584; cv=none; d=google.com; s=arc-20160816; b=ZhMTn/YtlXXYS3kuJ1d6oqz/lHRPsILCim7pUm0oyAk6a0yWyRpCJQJ5dchZCYwhTy 5YjdziUA8qwnjfk29gpXUWi+0zIYWqgfYQSFS2F/z/3+Ge4USB1NUzh/t/kfwlwC5g7p yE0LkzwLD0yYj0guZHShAy619V3aF2BZO8KBTaOtVo4g7tWhVb0CeB/qOCCkDbDRaz0O afJYiJ7+bDnX1uYrya0XYe1mhxdU/79ByHyOMtGA02oQUMW9dWW/3gcZNFs5ck3Uurad NCa0M5s+1e1XrL5ytaaWFDTXK3F4MQ0n2tU0bkdGlo7JM6WcyF5F035qZ4RZWlqx3VJ0 YV1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=nSvWtAiiACGfPZ9sGr2OQ4axBSPiAcGMHWs+gcXYt/0=; b=OnF3tGlPekRwZobsML+E8TsnqnEv3vxBW7y6QrF+r3zdT/FoZ4nOpB75I18pu0TAmz z2nYBMdLoWdxOVHkcTb6C/DaB+YmHlHGKhOTO0qZj6+aBvUhCfEZaSZoldljLhJmsyvO 0mUQm8hW0wWLMupEXeUIHe4WKMXu7OS9OoUVCqv0iRXydlbUVD/tEilN88L2zigcNB2V kJ29Ufmw6X/3hcmAzaI8mUtOMz4Sh7pNWY1dfBnqj6W+pfKBcnxRAVDrfMMYcu9aWSiZ iZfNybDvYMa66FVa7dLZS5dVn4xFttK08y2/h8+AGVXWGrAFjVrMI+QJQhmSVopgpS/2 0SIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=2LLu6Q1h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l19si347827oii.54.2020.02.26.15.26.12; Wed, 26 Feb 2020 15:26:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=2LLu6Q1h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727983AbgBZXZx (ORCPT + 99 others); Wed, 26 Feb 2020 18:25:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:53898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727910AbgBZXZx (ORCPT ); Wed, 26 Feb 2020 18:25:53 -0500 Received: from localhost (mobile-166-175-186-165.mycingular.net [166.175.186.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B20E20658; Wed, 26 Feb 2020 23:25:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582759552; bh=B+YnP0ht2MdSiz9kP73cb0eqPBYs4iIQUvvHhmQ6PYI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=2LLu6Q1haUBXAnpuUik1DxJptPj6NnQIqGRuxyVxJOgn89kTsfgNsp2/odBBdl9S4 lNcdhRTZxLrXNkoVcdursDSSIvTLCPuaki6yLV8Cb1/zXQSSij06us6VlnytOQioi9 VIIx4L4OIthJN8Css6/CMeK3lE3klewZ421wLZqI= Date: Wed, 26 Feb 2020 17:25:50 -0600 From: Bjorn Helgaas To: Fawad Lateef Cc: Linux Kernel Mailing List , linux-pci@vger.kernel.org Subject: Re: Help needed in understanding weird PCIe issue on imx6q (PCIe just goes bad) Message-ID: <20200226232550.GA191068@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 22, 2020 at 04:25:41PM +0100, Fawad Lateef wrote: > Hello, > > I am trying to figure-out an issue on our i.MX6Q platform based design > where PCIe interface goes bad. > > We have a Phytec i.MX6Q eMMC SOM, attached to our custom designed > board. PCIe root-complex from i.MX6Q is attached to PLX switch > (PEX8605). > > Linux kernel version is 4.19.9x and also 4.14.134 (from phytec's > linux-mainline repo). Kernel do not have PCIe hot-plug and PNP enabled > in config. > > PLX switch #PERST is attached to a GPIO pin and stays in disable state > until Linux is booted. So at boot time only PCIe root-complex is > initialized by kernel. > > After boot if I do "lspci -v" and see everything good from PCIe > root-complex (below): > > ~ # lspci -v > 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 > [Normal decode]) > Flags: bus master, fast devsel, latency 0, IRQ 295 > Memory at 01000000 (32-bit, non-prefetchable) [size=1M] > Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 > I/O behind bridge: None > Memory behind bridge: None > Prefetchable memory behind bridge: None > [virtual] Expansion ROM at 01100000 [disabled] [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ > Capabilities: [70] Express Root Port (Slot-), MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Virtual Channel > Kernel driver in use: pcieport > > > Then I enable the #PERST pin of PLX switch, everything is still good > (no rescan on Linux is done yet) > > ~ # echo 139 > /sys/class/gpio/export > ~ # echo out > /sys/class/gpio/gpio139/direction > ~ # echo 1 > /sys/class/gpio/gpio139/value > ~ # lspci -v > 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 > [Normal decode]) > Flags: bus master, fast devsel, latency 0, IRQ 295 > Memory at 01000000 (32-bit, non-prefetchable) [size=1M] > Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 > I/O behind bridge: None > Memory behind bridge: None > Prefetchable memory behind bridge: None > [virtual] Expansion ROM at 01100000 [disabled] [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ > Capabilities: [70] Express Root Port (Slot-), MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Virtual Channel > Kernel driver in use: pcieport > > > Now just disable/put-in-reset the PLX switch (Linux don't see the > switch yet, as no rescan on PCIe was done). Now "lspci -v" and > root-complex goes bad. > > ~ # echo 0 > /sys/class/gpio/gpio139/value > ~ # lspci -v > 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 > [Normal decode]) > Flags: fast devsel, IRQ 295 > Memory at 01000000 (64-bit, prefetchable) [disabled] [size=1M] > Bus: primary=00, secondary=00, subordinate=00, sec-latency=0 > I/O behind bridge: 00000000-00000fff [size=4K] > Memory behind bridge: 00000000-000fffff [size=1M] > Prefetchable memory behind bridge: 00000000-000fffff [size=1M] > [virtual] Expansion ROM at 01100000 [disabled] [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ > Capabilities: [70] Express Root Port (Slot-), MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Virtual Channel > Kernel driver in use: pcieport > > ~ # uname -a > Linux buildroot-2019.08-imx6 4.14.134-phy2 #1 SMP Thu Feb 20 12:13:33 > UTC 2020 armv7l GNU/Linux > ~ # > > > I am really not sure what is going wrong here. Did I am missing > something basic? I agree, it looks like something's wrong, but I really don't have any ideas. I would start by using "lspci -xxxx" to see the actual values we get from config space. It looks like we're reading zeros from at least the bus and window registers. You could also instrument the i.MX config accessors in case there's something strange going on there. Maybe try to reproduce this on a current upstream kernel? Bjorn