linux-kernel - Re: [PATCH V2 6/9] PCI: tegra194: Refactor LTSSM state polling on surprise down

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: <20220926181609.GA1612301@bhelgaas>
Date:   Mon, 26 Sep 2022 13:16:09 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Vidya Sagar <vidyas@...dia.com>
Cc:     lpieralisi@...nel.org, robh@...nel.org, kw@...ux.com,
        bhelgaas@...gle.com, thierry.reding@...il.com,
        jonathanh@...dia.com, kishon@...com, vkoul@...nel.org,
        mani@...nel.org, Sergey.Semin@...kalelectronics.ru,
        ffclaire1224@...il.com, linux-pci@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-phy@...ts.infradead.org, kthota@...dia.com,
        mmaddireddy@...dia.com, sagar.tv@...il.com
Subject: Re: [PATCH V2 6/9] PCI: tegra194: Refactor LTSSM state polling on
 surprise down

On Mon, Sep 26, 2022 at 05:20:35PM +0530, Vidya Sagar wrote:
> On surprise down LTSSM state transisition from L0 -> Recovery.RcvrLock ->
> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect.
> Recovery.RcvrLock and Recovery.RcvrSpeed time is 24 msec and 48 msec
> respectively. It takes ~96 msec to move from L0 to detect state, hence,
> increase the poll time to 120 msec. Disable the LTSSM state after it moves
> to detect to avoid LTSSM toggle between polling and detect.

s/transisition/transition/

>  		err = readl_poll_timeout_atomic(pcie->appl_base + APPL_DEBUG,
>  						data,
>  						((data &
> -						APPL_DEBUG_LTSSM_STATE_MASK) >>
> -						APPL_DEBUG_LTSSM_STATE_SHIFT) ==
> -						LTSSM_STATE_PRE_DETECT,
> -						1, LTSSM_TIMEOUT);
> +						APPL_DEBUG_LTSSM_STATE_MASK) ==
> +						LTSSM_STATE_DETECT_QUIET) ||
> +						((data &
> +						APPL_DEBUG_LTSSM_STATE_MASK) ==
> +						LTSSM_STATE_DETECT_ACT) ||
> +						((data &
> +						APPL_DEBUG_LTSSM_STATE_MASK) ==
> +						LTSSM_STATE_PRE_DETECT_QUIET) ||
> +						((data &
> +						APPL_DEBUG_LTSSM_STATE_MASK) ==
> +						LTSSM_STATE_DETECT_WAIT),
> +						LTSSM_DELAY, LTSSM_TIMEOUT);

I know we usually line up the function parameters with that opening
paren, but I think overall it would be nicer to drop a couple of the
leading tabs so these don't wrap so awkwardly.

> +	ret = readl_poll_timeout(pcie->appl_base + APPL_DEBUG, val,
> +				 ((val & APPL_DEBUG_LTSSM_STATE_MASK) ==
> +				 LTSSM_STATE_DETECT_QUIET) ||
> +				 ((val & APPL_DEBUG_LTSSM_STATE_MASK) ==
> +				 LTSSM_STATE_DETECT_ACT) ||
> +				 ((val & APPL_DEBUG_LTSSM_STATE_MASK) ==
> +				 LTSSM_STATE_PRE_DETECT_QUIET) ||
> +				 ((val & APPL_DEBUG_LTSSM_STATE_MASK) ==
> +				 LTSSM_STATE_DETECT_WAIT) ||
> +				 ((val & APPL_DEBUG_LTSSM_STATE_MASK) ==
> +				 LTSSM_STATE_L2_IDLE),
> +				 LTSSM_DELAY, LTSSM_TIMEOUT);

Ditto.