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:   Mon, 28 Sep 2020 15:06:18 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     JC Kuo <jckuo@...dia.com>
Cc:     gregkh@...uxfoundation.org, robh@...nel.org, jonathanh@...dia.com,
        kishon@...com, linux-tegra@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, nkristam@...dia.com
Subject: Re: [PATCH v3 04/15] phy: tegra: xusb: tegra210: Do not reset UPHY
 PLL

On Wed, Sep 09, 2020 at 04:10:30PM +0800, JC Kuo wrote:
> Once UPHY PLL hardware power sequencer is enabled, do not assert
> reset to PEX/SATA PLLs, otherwise UPHY PLL operation will be broken.
> This commit removes reset_control_assert(pcie->rst) and
> reset_control_assert(sata->rst) from PEX/SATA UPHY disable procedure.
> 
> Signed-off-by: JC Kuo <jckuo@...dia.com>
> ---
> v3:
>    new, was a part of "phy: tegra: xusb: Rearrange UPHY init on Tegra210"
> 
>  drivers/phy/tegra/xusb-tegra210.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/xusb-tegra210.c
> index f06e7bc7a51b..ef4bbcbed60b 100644
> --- a/drivers/phy/tegra/xusb-tegra210.c
> +++ b/drivers/phy/tegra/xusb-tegra210.c
> @@ -504,7 +504,6 @@ static void tegra210_pex_uphy_disable(struct tegra_xusb_padctl *padctl)
>  	if (--pcie->enable > 0)
>  		goto unlock;
>  
> -	reset_control_assert(pcie->rst);
>  	clk_disable_unprepare(pcie->pll);
>  
>  unlock:
> @@ -746,7 +745,6 @@ static void tegra210_sata_uphy_disable(struct tegra_xusb_padctl *padctl)
>  	if (--sata->enable > 0)
>  		goto unlock;
>  
> -	reset_control_assert(sata->rst);
>  	clk_disable_unprepare(sata->pll);
>  
>  unlock:

Does this mean that we can no longer reset these PLLs anymore? Is that
safe? Would we ever need to reset them for recovery or similar? For
power saving, is disabling the clock enough, or could we save some extra
power by putting the PLLs into reset?

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists