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:   Sat, 23 Oct 2021 16:55:52 +0200
From:   Pali Rohár <>
To:     Mauro Carvalho Chehab <>
Cc:     Lorenzo Pieralisi <>,,,
        Krzysztof Wilczyński <>,
        Songxiaowei <>,
        Binghui Wang <>,
        Bjorn Helgaas <>,
        Rob Herring <>,,
Subject: Re: [PATCH v14 05/11] PCI: kirin: give more time for PERST# reset to

On Saturday 23 October 2021 14:45:34 Mauro Carvalho Chehab wrote:
> Em Sat, 23 Oct 2021 12:40:11 +0200
> Pali Rohár <> escreveu:
> > It is classic setup for boards with just one PCIe port.
> > 
> > > with 3 elements connected to the bus: an Ethernet card, a M.2 slot and
> > > a mini PCIe slot. It seems HiKey 970 is unique with regards to PERST# signal,
> > > as there are 4 independent PERST# signals there:
> > > 
> > > 	- one for PEX 8606 (the PCIe root port);
> > > 	- one for Ethernet;
> > > 	- one for M.2;
> > > 	- one for mini-PCIe.  
> > 
> > This is not unique setup, its pretty normal. Every PCIe card has (own)
> > PERST# pin and obviously you want to control each pin separately via SW.
> > And because PCIe switch is also (upstream) PCIe device it has also
> > PERST# pin.
> Based on the discussions we had to add per-port DT PERST# gpios, it
> sounded to me that this is was not a typical setup ;-)
> It seems that the typical setup is to have a single PERST# connected
> to all devices inside the bus.


I'm sure it is not unique :) Just seems that these boards either do not
use device tree (x86-based) or do not have specified reset-gpios in DTS
at all.

Sometimes there is no need to touch PERST# gpio as either firmware
during boot handles it (x86 BIOS/UEFI case, or U-Boot for arm case) or
because board/cpu reset toggle PERST# in a way that is compatible for
cards init.

Looks like you have non-x86 board, which does not have PCIe init code in
firmware, needs special handling of PERST# and you are doing it with
upstream kernel :-) So maybe all these conditions are unique... But HW
design not.

As this setup with reset-gpios per card in DTS nodes is something which
I will need too, I sent email to Rob with proposal how to universally
declare it in DTS, independently of PCIe controller (you are on CC):

Due to how PCIe cards are broken, PERST# signal is sometimes the only
one option how to reset card at runtime. So requirement for separate
PERST# per card configurable at runtime by OS will be requirement for
more and more boards.

Powered by blists - more mailing lists