lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 17:45:59 +0530
From:   Vidya Sagar <vidyas@...dia.com>
To:     Mian Yousaf Kaukab <ykaukab@...e.de>, <lorenzo.pieralisi@....com>,
        <robh@...nel.org>
CC:     <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: dwc: tegra194: issue with card containing a bridge

Thanks Mian for bringing it to our notice.
Have you tried removing the dw_pcie_setup_rc(pp); call from 
pcie-tegra194.c file on top of linux-next? and does that solve the issue?

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
b/drivers/pci/controller/dwc/pcie-tegra194.c
index 5597b2a49598..1c9e9c054592 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct pcie_port 
*pp)
                 dw_pcie_writel_dbi(pci, 
CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF, val);
         }

-       dw_pcie_setup_rc(pp);
+       //dw_pcie_setup_rc(pp);

         clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);

I took a quick look at the dw_pcie_setup_rc() implementation and I'm not 
sure why calling it second time should create any issue for the 
enumeration of devices behind a switch. Perhaps I need to spend more 
time to debug that part.
In any case, since dw_pcie_setup_rc() is already part of 
dw_pcie_host_init(), I think it can be removed from 
tegra_pcie_prepare_host() implemention.

Thanks,
Vidya Sagar

On 12/15/2020 3:54 PM, Mian Yousaf Kaukab wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hi,
> I am seeing an issue with next-20201211 with USB3380[1] based PCIe card
> (vid:pid 10b5:3380) on Jetson AGX Xavier. Card doesn't show up in the
> lspci output.
> 
> In non working case (next-20201211):
> # lspci
> 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
> 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
> 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)
> 
> In working case (v5.10-rc7):
> # lspci
> 0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1)
> 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
> 0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1)
> 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
> 0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
> 0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)
> # lspci -t
> -+-[0005:00]---00.0-[01-ff]----00.0-[02-03]----02.0-[03]----00.0
>   +-[0001:00]---00.0-[01-ff]----00.0
>   \-[0000:00]-
> #lspci -v
> https://paste.opensuse.org/87573209
> 
> git-bisect points to commit b9ac0f9dc8ea ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code").
> dw_pcie_setup_rc() is not removed from pcie-tegra194.c in this commit.
> 
> Could the failure be caused because dw_pcie_setup_rc() is called twice now in case of tegra194?
> 
> BR,
> Yousaf
> 
> [1]: https://www.broadcom.com/products/pcie-switches-bridges/usb-pci/usb-controllers/usb3380
> 

Powered by blists - more mailing lists