linux-kernel - Re: [PATCH v2] PCI: dra7xx: Fix reset behaviour

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]

Message-ID: <20210531162242.jm73yzntzmilsvbg@pali>
Date:   Mon, 31 May 2021 18:22:42 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Kishon Vijay Abraham I <kishon@...com>
Cc:     Luca Ceresoli <luca@...aceresoli.net>, linux-pci@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v2] PCI: dra7xx: Fix reset behaviour

Hello Kishon!

On Monday 31 May 2021 21:30:30 Kishon Vijay Abraham I wrote:
> I had given the timing mentioned in the specification here
> https://lore.kernel.org/r/023c9b59-70bb-ed8d-a4c0-76eae726b574@ti.com
> 
> The PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION defines the Power
> Sequencing and Reset Signal Timings in Table 2-4. Please also refer Figure
> 2-10: Power Up of the CEM.
> 
> ╔═════════════╤══════════════════════════════════════╤═════╤═════╤═══════╗
> ║ Symbol      │ Parameter                            │ Min │ Max │ Units ║
> ╠═════════════╪══════════════════════════════════════╪═════╪═════╪═══════╣
> ║ T PVPERL    │ Power stable to PERST# inactive      │ 100 │     │ ms    ║
> ╟─────────────┼──────────────────────────────────────┼─────┼─────┼───────╢
> ║ T PERST-CLK │ REFCLK stable before PERST# inactive │ 100 │     │ μs    ║
> ╟─────────────┼──────────────────────────────────────┼─────┼─────┼───────╢
> ║ T PERST     │ PERST# active time                   │ 100 │     │ μs    ║
> ╟─────────────┼──────────────────────────────────────┼─────┼─────┼───────╢
> ║ T FAIL      │ Power level invalid to PERST# active │     │ 500 │ ns    ║
> ╟─────────────┼──────────────────────────────────────┼─────┼─────┼───────╢
> ║ T WKRF      │ WAKE# rise – fall time               │     │ 100 │ ns    ║
> ╚═════════════╧══════════════════════════════════════╧═════╧═════╧═══════╝
> 
> The de-assertion of #PERST is w.r.t both power stable and refclk stable.

I think this does not fully answer this problematic question. One thing
is initial power on and second thing is warm reset (when both power and
clock is stable).

On more ARM boards, power is not SW controllable and is automatically
enabled when powering board on. So Tₚᵥₚₑᵣₗ is calculated since
bootloader and therefore not needed to take into account in kernel.

Tₚₑᵣₛₜ₋cₗₖ is only 100 µs and experiments proved that 100 µs not enough
for toggling PERST# GPIO. At least one 1 ms is needed and for some cards
at least 10 ms. Otherwise cards are not detected.

So when you have both power and clock stable and you want to reset card
via PERST# signal, above table does not say how long it is needed to
have PERST# in reset state.

> I'm yet to validate this patch, but IIRC devm_gpiod_get_optional(dev,
> NULL, GPIOD_OUT_HIGH) will already de-assert the PERST line. Please note
> the board here can have various combinations of NOT gate before the gpio
> line is actually connected to the connector.
> 
> Thanks
> Kishon