From: nguyenb@codeaurora.org
To: Avri Altman <Avri.Altman@wdc.com>
Cc: cang@codeaurora.org, asutoshd@codeaurora.org,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
Alim Akhtar <alim.akhtar@samsung.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
YueHaibing <yuehaibing@huawei.com>, Bean Huo <beanhuo@micron.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] scsi: ufs: Support reading UFS's Vcc voltage from device tree
Date: Mon, 14 Sep 2020 11:43:12 -0700 [thread overview]
Message-ID: <170592eceb26da041f276cf4ca33aaf2@codeaurora.org> (raw)
In-Reply-To: <BY5PR04MB67051C08A73119B554E4F352FC220@BY5PR04MB6705.namprd04.prod.outlook.com>
On 2020-09-13 02:37, Avri Altman wrote:
>>
>> The UFS specifications supports a range of Vcc operating voltage
>> from 2.4-3.6V depending on the device and manufacturers.
>> Allows selecting the UFS Vcc voltage level by setting the
>> UFS's entry vcc-voltage-level in the device tree. If UFS's
>> vcc-voltage-level setting is not found in the device tree,
>> use default values provided by the driver.
>>
>> Signed-off-by: Can Guo <cang@codeaurora.org>
>> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
>> Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
>> ---
>> drivers/scsi/ufs/ufshcd-pltfrm.c | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
>> b/drivers/scsi/ufs/ufshcd-pltfrm.c
>> index 3db0af6..48f429c 100644
>> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
>> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
>> @@ -104,10 +104,11 @@ static int ufshcd_parse_clock_info(struct
>> ufs_hba
>> *hba)
>> static int ufshcd_populate_vreg(struct device *dev, const char *name,
>> struct ufs_vreg **out_vreg)
>> {
>> - int ret = 0;
>> + int len, ret = 0;
>> char prop_name[MAX_PROP_SIZE];
>> struct ufs_vreg *vreg = NULL;
>> struct device_node *np = dev->of_node;
>> + const __be32 *prop;
>>
>> if (!np) {
>> dev_err(dev, "%s: non DT initialization\n", __func__);
>> @@ -138,8 +139,16 @@ static int ufshcd_populate_vreg(struct device
>> *dev,
>> const char *name,
>> vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
>> vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
>> } else {
>> - vreg->min_uV = UFS_VREG_VCC_MIN_UV;
>> - vreg->max_uV = UFS_VREG_VCC_MAX_UV;
>> + prop = of_get_property(np,
>> "vcc-voltage-level", &len);
>> + if (!prop || (len != (2 * sizeof(__be32)))) {
>> + dev_warn(dev, "%s vcc-voltage-level
>> property.\n",
>> + prop ? "invalid format" :
>> "no");
>> + vreg->min_uV = UFS_VREG_VCC_MIN_UV;
>> + vreg->max_uV = UFS_VREG_VCC_MAX_UV;
>> + } else {
>> + vreg->min_uV = be32_to_cpup(&prop[0]);
>> + vreg->max_uV = be32_to_cpup(&prop[1]);
>> + }
>> }
>> } else if (!strcmp(name, "vccq")) {
>> vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
>> --
> Maybe instead call ufshcd_populate_vreg with the new name,
> To not break the function flow, and just add another else if ?
Could you please clarify your comments? Are you suggesting to create a
new function?
Thank you.
next prev parent reply other threads:[~2020-09-14 18:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 6:00 [PATCH v1 0/2] Supports Reading UFS's Vcc Voltage Levels from DT Bao D. Nguyen
2020-09-01 6:00 ` [PATCH v1 1/2] scsi: dt-bindings: ufs: Add vcc-voltage-level for UFS Bao D. Nguyen
2020-09-13 9:35 ` Avri Altman
2020-09-14 16:19 ` nguyenb
2020-09-14 18:35 ` Rob Herring
2020-09-15 8:10 ` nguyenb
2020-09-18 19:01 ` Rob Herring
2020-09-22 0:22 ` nguyenb
2020-09-22 0:36 ` Bjorn Andersson
2020-09-23 17:32 ` nguyenb
2020-09-15 4:41 ` Bjorn Andersson
2020-09-15 8:14 ` nguyenb
2020-09-15 13:43 ` Bjorn Andersson
2020-09-15 16:47 ` nguyenb
2020-09-15 18:36 ` Bjorn Andersson
2020-09-01 6:00 ` [PATCH v1 2/2] scsi: ufs: Support reading UFS's Vcc voltage from device tree Bao D. Nguyen
2020-09-13 9:37 ` Avri Altman
2020-09-14 18:43 ` nguyenb [this message]
2020-09-15 6:51 ` Avri Altman
2020-09-15 13:46 ` Bjorn Andersson
2020-09-10 1:29 ` [PATCH v1 0/2] Supports Reading UFS's Vcc Voltage Levels from DT nguyenb
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=170592eceb26da041f276cf4ca33aaf2@codeaurora.org \
--to=nguyenb@codeaurora.org \
--cc=Avri.Altman@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=beanhuo@micron.com \
--cc=cang@codeaurora.org \
--cc=jejb@linux.ibm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=yuehaibing@huawei.com \
/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.