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  linux-cve-announce  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:   Fri, 22 Oct 2021 17:16:24 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>, linuxarm@...wei.com,
        mauro.chehab@...wei.com,
        Krzysztof Wilczyński <kw@...ux.com>,
        Songxiaowei <songxiaowei@...ilicon.com>,
        Binghui Wang <wangbinghui@...ilicon.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh@...nel.org>, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org
Subject: Re: [PATCH v14 05/11] PCI: kirin: give more time for PERST# reset to
 finish

On Tuesday 19 October 2021 07:06:42 Mauro Carvalho Chehab wrote:
> Before code refactor, the PERST# signals were sent at the
> end of the power_on logic. Then, the PCI core would probe for
> the buses and add them.
> 
> The new logic changed it to send PERST# signals during
> add_bus operation. That altered the timings.
> 
> Also, HiKey 970 require a little more waiting time for
> the PCI bridge - which is outside the SoC - to finish
> the PERST# reset, and then initialize the eye diagram.

Hello! Which PCIe port do you mean by PCI bridge device? Do you mean
PCIe Root Port? Or upstream port on some external PCIe switch connected
via PCIe bus to the PCIe Root Port? Because all of these (virtual) PCIe
devices are presented as PCI bridge devices, so it is not clear to which
device it refers.

Normally PERST# signal is used to reset endpoint card, other end of PCIe
link and so PERST# signal should not affect PCIe Root Port at all.

> So, increase the waiting time for the PERST# signals to
> what's required for it to also work with HiKey 970.

Because PERST# signal resets endpoint card, this reset timeout should
not be driver or controller specific.

Mauro, if you understand this issue more deeply, could you look at my
email? https://lore.kernel.org/linux-pci/20210310110535.zh4pnn4vpmvzwl5q@pali/

I think that kernel PCI subsystem does not properly handle PCIe Warm
Reset and correct initialization of endpoint cards. Because similar
"random PERST# timeout patches" were applied to lot of native controller
drivers.

PS: I'm not opposing this patch, I'm just trying to understand what is
happening here and why particular number "21000" was chosen. It is
defined in some standard? Or was it just randomly chosen and measures
that with this number is initialization working fine?

> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
> ---
> 
> See [PATCH v14 00/11] at: https://lore.kernel.org/all/cover.1634622716.git.mchehab+huawei@kernel.org/
> 
>  drivers/pci/controller/dwc/pcie-kirin.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-kirin.c b/drivers/pci/controller/dwc/pcie-kirin.c
> index de375795a3b8..bc329673632a 100644
> --- a/drivers/pci/controller/dwc/pcie-kirin.c
> +++ b/drivers/pci/controller/dwc/pcie-kirin.c
> @@ -113,7 +113,7 @@ struct kirin_pcie {
>  #define CRGCTRL_PCIE_ASSERT_BIT		0x8c000000
>  
>  /* Time for delay */
> -#define REF_2_PERST_MIN		20000
> +#define REF_2_PERST_MIN		21000
>  #define REF_2_PERST_MAX		25000
>  #define PERST_2_ACCESS_MIN	10000
>  #define PERST_2_ACCESS_MAX	12000
> -- 
> 2.31.1
> 

Powered by blists - more mailing lists