linux-kernel - Re: [PATCH v5 1/2] phy: core: Use runtime pm during configure too

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: <3ae6e6413901cbc9e432c7057db8fb9e81e56f39.camel@nxp.com>
Date:   Mon, 12 Apr 2021 16:40:56 +0800
From:   Liu Ying <victor.liu@....com>
To:     Guido Günther <agx@...xcpu.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Robert Chiras <robert.chiras@....com>,
        Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 1/2] phy: core: Use runtime pm during configure too

Hi Guido,

On Fri, 2021-04-09 at 13:40 +0200, Guido Günther wrote:
> The phy's configure phase usually needs register access so taking the
> device out of pm_runtime suspend looks useful.
> 
> There's currently two in tree drivers using runtime pm and .configure
> (qualcomm/phy-qcom-qmp.c, rockchip/phy-rockchip-inno-dsidphy.c) but both
> don't use the phy layers 'transparent' runtime phy_pm_runtime handling
> but manage it manually so this will for now only affect the
> phy-fsl-imx8-mipi-dphy driver.

IIUC, the qualcomm one's runtime PM is managed by the phy core when
users enable it using power/control in sysfs(see comment just before
pm_runtime_forbid() in that driver).
I'm assuming it's affected and it would be good to test it.

I'm not pretty sure if the rockchip one is affected or not, because I'm
assuming the power/control nodes of phy->dev and phy->parent.dev in
sysfs are both 'auto' after the driver probes.

> 
> Signed-off-by: Guido Günther <agx@...xcpu.org>
> ---
>  drivers/phy/phy-core.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index ccb575b13777..256a964d52d3 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -470,10 +470,16 @@ int phy_configure(struct phy *phy, union phy_configure_opts *opts)
>  	if (!phy->ops->configure)
>  		return -EOPNOTSUPP;
>  
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +	ret = 0; /* Override possible ret == -ENOTSUPP */

This override is not needed, because 'ret' will be the return value of
phy->ops->configure() right below.

Regards,
Liu Ying

> +
>  	mutex_lock(&phy->mutex);
>  	ret = phy->ops->configure(phy, opts);
>  	mutex_unlock(&phy->mutex);
>  
> +	phy_pm_runtime_put(phy);
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(phy_configure);