linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Stanley Chu <stanley.chu@mediatek.com>
To: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	avri.altman@wdc.com, alim.akhtar@samsung.com,
	pedrom.sousa@synopsys.com
Cc: marc.w.gonzalez@free.fr, chun-hung.wu@mediatek.com,
	kuohong.wang@mediatek.com, evgreen@chromium.org,
	subhashj@codeaurora.org, linux-mediatek@lists.infradead.org,
	peter.wang@mediatek.com, vivek.gautam@codeaurora.org,
	matthias.bgg@gmail.com, sayalil@codeaurora.org,
	Stanley Chu <stanley.chu@mediatek.com>,
	linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
Subject: [PATCH v4 2/5] scsi: ufs: Avoid configuring regulator with undefined voltage range
Date: Thu, 28 Mar 2019 17:16:24 +0800	[thread overview]
Message-ID: <1553764587-26357-3-git-send-email-stanley.chu@mediatek.com> (raw)
In-Reply-To: <1553764587-26357-1-git-send-email-stanley.chu@mediatek.com>

For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
initialized by ufshcd_populate_vreg(), however other regulators may
have undefined voltage range if dt-bindings have no such definition.

In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
struct will be zero values and these values will be configured on
regulators in different power modes.

Currently this may have no harm if both "min_uV" and "max_uV"
always keep "zero values" because regulator_set_voltage() will always
bypass such invalid values and return "good" results.

However improper values shall be fixed to avoid potential bugs.
Simply bypass voltage configuration if voltage range is not defined.

Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
---
 drivers/scsi/ufs/ufshcd.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e040f9dd9ff3..81d99aebb867 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7039,12 +7039,15 @@ static int ufshcd_config_vreg(struct device *dev,
 	name = vreg->name;
 
 	if (regulator_count_voltages(reg) > 0) {
-		min_uV = on ? vreg->min_uV : 0;
-		ret = regulator_set_voltage(reg, min_uV, vreg->max_uV);
-		if (ret) {
-			dev_err(dev, "%s: %s set voltage failed, err=%d\n",
+		if (vreg->min_uV && vreg->max_uV) {
+			min_uV = on ? vreg->min_uV : 0;
+			ret = regulator_set_voltage(reg, min_uV, vreg->max_uV);
+			if (ret) {
+				dev_err(dev,
+					"%s: %s set voltage failed, err=%d\n",
 					__func__, name, ret);
-			goto out;
+				goto out;
+			}
 		}
 
 		uA_load = on ? vreg->max_uA : 0;
-- 
2.18.0

  parent reply	other threads:[~2019-03-28  9:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-28  9:16 [PATCH v4 0/5] scsi: ufs: Fix regulator operations and remove "<name>-fixed-regulator" device tree property Stanley Chu
2019-03-28  9:16 ` [PATCH v4 1/5] scsi: ufs: Remove unused min_uA field in struct ufs_vreg Stanley Chu
2019-03-28  9:16 ` Stanley Chu [this message]
2019-03-28  9:16 ` [PATCH v4 3/5] scsi: ufs: Fix regulator load and icc-level configuration Stanley Chu
2019-03-28  9:16 ` [PATCH v4 4/5] scsi: ufs: Change "<name>-max-microamp" to non-mandatory property Stanley Chu
     [not found] ` <1553764587-26357-1-git-send-email-stanley.chu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-03-28  9:16   ` [PATCH v4 5/5] scsi: ufs: Remove "<name>-fixed-regulator" device tree property Stanley Chu
2019-03-29 14:21 ` [PATCH v4 0/5] scsi: ufs: Fix regulator operations and remove " Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1553764587-26357-3-git-send-email-stanley.chu@mediatek.com \
    --to=stanley.chu@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=chun-hung.wu@mediatek.com \
    --cc=evgreen@chromium.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marc.w.gonzalez@free.fr \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=pedrom.sousa@synopsys.com \
    --cc=peter.wang@mediatek.com \
    --cc=sayalil@codeaurora.org \
    --cc=subhashj@codeaurora.org \
    --cc=vivek.gautam@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).