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 4/5] scsi: ufs: Change "<name>-max-microamp" to non-mandatory property Date: Thu, 28 Mar 2019 17:16:26 +0800 [thread overview] Message-ID: <1553764587-26357-5-git-send-email-stanley.chu@mediatek.com> (raw) In-Reply-To: <1553764587-26357-1-git-send-email-stanley.chu@mediatek.com> In dt-bindings for ufs, "<name>-max-microamp" property indicates current limit and is mandatory if "<name>-fixed-regulator" is not defined on a specified regulator. However, in some platforms, regulators without "<name>-fixed-regulator" property may not need to define their current limit because they may want to define voltage range only for proper voltage switching in different power modes, especially for vcc, vccq or vccq2. Currently missing "<name>-max-microamp" property in device tree will lead initialization to fail, thus such limitation shall be resolved to tolerate this kind of regulators. After resolving this, regulators without "<name>-max-microamp" property will have undefined "max current" value, i.e., zero value in "max_uA" field in struct ufs_vreg. Because we do bypass current switching operation (by regulator_set_load) in case of undefined current limit, this patch shall be safe. 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-pltfrm.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index 32cf8c56f029..2420e6962219 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -157,11 +157,9 @@ static int ufshcd_populate_vreg(struct device *dev, const char *name, goto out; snprintf(prop_name, MAX_PROP_SIZE, "%s-max-microamp", name); - ret = of_property_read_u32(np, prop_name, &vreg->max_uA); - if (ret) { - dev_err(dev, "%s: unable to find %s err %d\n", - __func__, prop_name, ret); - goto out; + if (of_property_read_u32(np, prop_name, &vreg->max_uA)) { + dev_info(dev, "%s: unable to find %s\n", __func__, prop_name); + vreg->max_uA = 0; } if (!strcmp(name, "vcc")) { -- 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 4/5] scsi: ufs: Change "<name>-max-microamp" to non-mandatory property Date: Thu, 28 Mar 2019 17:16:26 +0800 [thread overview] Message-ID: <1553764587-26357-5-git-send-email-stanley.chu@mediatek.com> (raw) In-Reply-To: <1553764587-26357-1-git-send-email-stanley.chu@mediatek.com> In dt-bindings for ufs, "<name>-max-microamp" property indicates current limit and is mandatory if "<name>-fixed-regulator" is not defined on a specified regulator. However, in some platforms, regulators without "<name>-fixed-regulator" property may not need to define their current limit because they may want to define voltage range only for proper voltage switching in different power modes, especially for vcc, vccq or vccq2. Currently missing "<name>-max-microamp" property in device tree will lead initialization to fail, thus such limitation shall be resolved to tolerate this kind of regulators. After resolving this, regulators without "<name>-max-microamp" property will have undefined "max current" value, i.e., zero value in "max_uA" field in struct ufs_vreg. Because we do bypass current switching operation (by regulator_set_load) in case of undefined current limit, this patch shall be safe. 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-pltfrm.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index 32cf8c56f029..2420e6962219 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -157,11 +157,9 @@ static int ufshcd_populate_vreg(struct device *dev, const char *name, goto out; snprintf(prop_name, MAX_PROP_SIZE, "%s-max-microamp", name); - ret = of_property_read_u32(np, prop_name, &vreg->max_uA); - if (ret) { - dev_err(dev, "%s: unable to find %s err %d\n", - __func__, prop_name, ret); - goto out; + if (of_property_read_u32(np, prop_name, &vreg->max_uA)) { + dev_info(dev, "%s: unable to find %s\n", __func__, prop_name); + vreg->max_uA = 0; } if (!strcmp(name, "vcc")) { -- 2.18.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev 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 ` [PATCH v4 3/5] scsi: ufs: Fix regulator load and icc-level configuration 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 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-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-5-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: linkBe 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.