linux-kernel - Re: [PATCH V3 1/2] phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHY

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <iak5s5ligdmq3ru4fkvh5a3si6nxadwouboltxxyce4x7t3l6o@eyhh7khzij7v>
Date: Fri, 22 Aug 2025 14:10:29 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Nitin Rawat <quic_nitirawa@...cinc.com>
Cc: vkoul@...nel.org, kishon@...nel.org, dmitry.baryshkov@....qualcomm.com, 
	andersson@...nel.org, konradybcio@...nel.org, linux-arm-msm@...r.kernel.org, 
	linux-phy@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 1/2] phy: qcom-qmp-ufs: Add regulator load voting for
 UFS QMP PHY

On Wed, Aug 20, 2025 at 03:58:25AM GMT, Nitin Rawat wrote:
> On certain SoCs, power regulators are shared between the QMP UFS PHY
> and other IP blocks. To ensure proper operation, the regulator
> framework must be informed of the UFS PHY's load requirements.
> This is essential because the regulator's operating mode—whether Low
> Power or High Power—depends on the maximum expected load at any given
> time, which the regulator driver needs to manage accordingly.
> 
> To support this, replace devm_regulator_bulk_get() with
> devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init()
> function.

Use of 'inline' is confusing. Please reword it to sound like you are just
getting rid of this function in favor of devm_regulator_bulk_get_const().

> additionally replace the array of regulator names with a
> bulk regulator data structure, and utilize the init_load_uA field
> provided by the regulator framework. This ensures that
> regulator_set_load() is automatically invoked before the
> first enable operation.
> 
> Signed-off-by: Nitin Rawat <quic_nitirawa@...cinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 29 +++++++------------------
>  1 file changed, 8 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index 9c69c77d10c8..aaa88ca0ef07 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -1107,7 +1107,7 @@ struct qmp_phy_cfg {
>  	const struct qmp_phy_cfg_tbls tbls_hs_overlay[NUM_OVERLAY];
> 
>  	/* regulators to be requested */
> -	const char * const *vreg_list;
> +	const struct regulator_bulk_data *vreg_list;
>  	int num_vregs;
> 
>  	/* array of registers with different offsets */
> @@ -1164,9 +1164,10 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
>  	readl(base + offset);
>  }
> 
> -/* list of regulators */
> -static const char * const qmp_phy_vreg_l[] = {
> -	"vdda-phy", "vdda-pll",
> +/* Default regulator bulk data (no load used) */
> +static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
> +	{ .supply = "vdda-phy" },
> +	{ .supply = "vdda-pll" },
>  };
> 
>  static const struct qmp_ufs_offsets qmp_ufs_offsets = {
> @@ -1890,22 +1891,6 @@ static const struct phy_ops qcom_qmp_ufs_phy_ops = {
>  	.owner		= THIS_MODULE,
>  };
> 
> -static int qmp_ufs_vreg_init(struct qmp_ufs *qmp)
> -{
> -	const struct qmp_phy_cfg *cfg = qmp->cfg;
> -	struct device *dev = qmp->dev;
> -	int num = cfg->num_vregs;
> -	int i;
> -
> -	qmp->vregs = devm_kcalloc(dev, num, sizeof(*qmp->vregs), GFP_KERNEL);
> -	if (!qmp->vregs)
> -		return -ENOMEM;
> -
> -	for (i = 0; i < num; i++)
> -		qmp->vregs[i].supply = cfg->vreg_list[i];
> -
> -	return devm_regulator_bulk_get(dev, num, qmp->vregs);
> -}
> 

Stray new line.

With above changes,

Reviewed-by: Manivannan Sadhasivam <mani@...nel.org>

- Mani

-- 
மணிவண்ணன் சதாசிவம்