All of lore.kernel.org
 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 3/5] scsi: ufs: Fix regulator load and icc-level configuration
Date: Thu, 28 Mar 2019 17:16:25 +0800	[thread overview]
Message-ID: <1553764587-26357-4-git-send-email-stanley.chu@mediatek.com> (raw)
In-Reply-To: <1553764587-26357-1-git-send-email-stanley.chu@mediatek.com>

Currently if a regulator has "<name>-fixed-regulator"
property in device tree, it will skip current limit initialization.
This lead to a zero "max_uA" value in struct ufs_vreg.

However, "regulator_set_load" operation shall be required
on regulators which have valid current limits, otherwise a zero
"max_uA" set by "regulator_set_load" may cause unexpected behavior
when this regulator is enabled or set as high power mode.

Similarly, in device's icc_level configuration flow, the target
icc_level shall be updated if regulator also has valid current limit,
otherwise a wrong icc_level will be calculated by zero "max_uA" and
thus causes unexpected results after it is written to device.

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 | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 81d99aebb867..5ba49c8cd2a3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6294,19 +6294,19 @@ static u32 ufshcd_find_max_sup_active_icc_level(struct ufs_hba *hba,
 		goto out;
 	}
 
-	if (hba->vreg_info.vcc)
+	if (hba->vreg_info.vcc && hba->vreg_info.vcc->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vcc->max_uA,
 				POWER_DESC_MAX_ACTV_ICC_LVLS - 1,
 				&desc_buf[PWR_DESC_ACTIVE_LVLS_VCC_0]);
 
-	if (hba->vreg_info.vccq)
+	if (hba->vreg_info.vccq && hba->vreg_info.vccq->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vccq->max_uA,
 				icc_level,
 				&desc_buf[PWR_DESC_ACTIVE_LVLS_VCCQ_0]);
 
-	if (hba->vreg_info.vccq2)
+	if (hba->vreg_info.vccq2 && hba->vreg_info.vccq2->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vccq2->max_uA,
 				icc_level,
@@ -7004,6 +7004,15 @@ static int ufshcd_config_vreg_load(struct device *dev, struct ufs_vreg *vreg,
 	if (!vreg)
 		return 0;
 
+	/*
+	 * "set_load" operation shall be required on those regulators
+	 * which specifically configured current limitation. Otherwise
+	 * zero max_uA may cause unexpected behavior when regulator is
+	 * enabled or set as high power mode.
+	 */
+	if (!vreg->max_uA)
+		return 0;
+
 	ret = regulator_set_load(vreg->reg, ua);
 	if (ret < 0) {
 		dev_err(dev, "%s: %s set load (ua=%d) failed, err=%d\n",
-- 
2.18.0

WARNING: multiple messages have this Message-ID (diff)
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 3/5] scsi: ufs: Fix regulator load and icc-level configuration
Date: Thu, 28 Mar 2019 17:16:25 +0800	[thread overview]
Message-ID: <1553764587-26357-4-git-send-email-stanley.chu@mediatek.com> (raw)
In-Reply-To: <1553764587-26357-1-git-send-email-stanley.chu@mediatek.com>

Currently if a regulator has "<name>-fixed-regulator"
property in device tree, it will skip current limit initialization.
This lead to a zero "max_uA" value in struct ufs_vreg.

However, "regulator_set_load" operation shall be required
on regulators which have valid current limits, otherwise a zero
"max_uA" set by "regulator_set_load" may cause unexpected behavior
when this regulator is enabled or set as high power mode.

Similarly, in device's icc_level configuration flow, the target
icc_level shall be updated if regulator also has valid current limit,
otherwise a wrong icc_level will be calculated by zero "max_uA" and
thus causes unexpected results after it is written to device.

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 | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 81d99aebb867..5ba49c8cd2a3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6294,19 +6294,19 @@ static u32 ufshcd_find_max_sup_active_icc_level(struct ufs_hba *hba,
 		goto out;
 	}
 
-	if (hba->vreg_info.vcc)
+	if (hba->vreg_info.vcc && hba->vreg_info.vcc->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vcc->max_uA,
 				POWER_DESC_MAX_ACTV_ICC_LVLS - 1,
 				&desc_buf[PWR_DESC_ACTIVE_LVLS_VCC_0]);
 
-	if (hba->vreg_info.vccq)
+	if (hba->vreg_info.vccq && hba->vreg_info.vccq->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vccq->max_uA,
 				icc_level,
 				&desc_buf[PWR_DESC_ACTIVE_LVLS_VCCQ_0]);
 
-	if (hba->vreg_info.vccq2)
+	if (hba->vreg_info.vccq2 && hba->vreg_info.vccq2->max_uA)
 		icc_level = ufshcd_get_max_icc_level(
 				hba->vreg_info.vccq2->max_uA,
 				icc_level,
@@ -7004,6 +7004,15 @@ static int ufshcd_config_vreg_load(struct device *dev, struct ufs_vreg *vreg,
 	if (!vreg)
 		return 0;
 
+	/*
+	 * "set_load" operation shall be required on those regulators
+	 * which specifically configured current limitation. Otherwise
+	 * zero max_uA may cause unexpected behavior when regulator is
+	 * enabled or set as high power mode.
+	 */
+	if (!vreg->max_uA)
+		return 0;
+
 	ret = regulator_set_load(vreg->reg, ua);
 	if (ret < 0) {
 		dev_err(dev, "%s: %s set load (ua=%d) failed, err=%d\n",
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Thread overview: 14+ 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 ` 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
2019-03-28  9:16 ` [PATCH v4 2/5] scsi: ufs: Avoid configuring regulator with undefined voltage range Stanley Chu
2019-03-28  9:16   ` 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
2019-03-28  9:16   ` 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-28  9:16     ` Stanley Chu
2019-03-29 14:21 ` [PATCH v4 0/5] scsi: ufs: Fix regulator operations and remove " Martin K. Petersen
2019-03-29 14:21   ` 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-4-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.