From patchwork Mon Mar 18 02:14:36 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 10856755 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4558B139A for ; Mon, 18 Mar 2019 02:15:00 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2AFDF2912F for ; Mon, 18 Mar 2019 02:15:00 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1F7CE29165; Mon, 18 Mar 2019 02:15:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C43D02912F for ; Mon, 18 Mar 2019 02:14:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727738AbfCRCO7 (ORCPT ); Sun, 17 Mar 2019 22:14:59 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:49198 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727474AbfCRCO7 (ORCPT ); Sun, 17 Mar 2019 22:14:59 -0400 X-UUID: 35fded445a3546f1a07166d53f35ab7f-20190318 X-UUID: 35fded445a3546f1a07166d53f35ab7f-20190318 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 434926655; Mon, 18 Mar 2019 10:14:43 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 10:14:41 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 18 Mar 2019 10:14:41 +0800 From: Stanley Chu To: , , , , CC: , , , , , , Stanley Chu Subject: [PATCH v3 1/5] scsi: ufs: Remove unused min_uA field in struct ufs_vreg Date: Mon, 18 Mar 2019 10:14:36 +0800 Message-ID: <1552875280-16196-3-git-send-email-stanley.chu@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> References: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> MIME-Version: 1.0 X-TM-SNTS-SMTP: B546F1AB01B3ABECA95C871AFDFB3ED752E31F17E53A498CD90DA6C9244F562A2000:8 X-MTK: N Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There are two fields related to regulator current limit in struct ufs_vreg: "min_uA" and "max_uA". "max_uA" is probed by "-max-microamp" property from device tree and used for - regulator_set_load operations, and - icc_level configuration in device. However "min_uA" field is not used anywhere, thus we can remove it. Signed-off-by: Stanley Chu Reviewed-by: Marc Gonzalez Acked-by: Alim Akhtar --- drivers/scsi/ufs/ufs.h | 1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index 7da7318eb6a6..0f23ac80bacd 100644 --- a/drivers/scsi/ufs/ufs.h +++ b/drivers/scsi/ufs/ufs.h @@ -516,7 +516,6 @@ struct ufs_vreg { bool enabled; int min_uV; int max_uV; - int min_uA; int max_uA; }; diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index 895a9b5ac989..588079286e8a 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -164,7 +164,6 @@ static int ufshcd_populate_vreg(struct device *dev, const char *name, goto out; } - vreg->min_uA = 0; if (!strcmp(name, "vcc")) { if (of_property_read_bool(np, "vcc-supply-1p8")) { vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV; From patchwork Mon Mar 18 02:14:37 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 10856747 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 16FFC139A for ; Mon, 18 Mar 2019 02:14:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EF03C29156 for ; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E2BD82916A; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8E0EF29170 for ; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726798AbfCRCOy (ORCPT ); Sun, 17 Mar 2019 22:14:54 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:31518 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727474AbfCRCOy (ORCPT ); Sun, 17 Mar 2019 22:14:54 -0400 X-UUID: 5809a213f9304a3a994df5b95c10c045-20190318 X-UUID: 5809a213f9304a3a994df5b95c10c045-20190318 Received: from mtkmrs01.mediatek.inc [(172.21.131.159)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 490356626; Mon, 18 Mar 2019 10:14:43 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 10:14:42 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 18 Mar 2019 10:14:42 +0800 From: Stanley Chu To: , , , , CC: , , , , , , Stanley Chu Subject: [PATCH v3 2/5] scsi: ufs: Avoid configuring undefined voltage range on a regulator Date: Mon, 18 Mar 2019 10:14:37 +0800 Message-ID: <1552875280-16196-4-git-send-email-stanley.chu@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> References: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> MIME-Version: 1.0 X-TM-SNTS-SMTP: B0DEE1B4AF8A58A1DE3B86956FB7F4B408D3D3C37C838A5659717AA9D18A449A2000:8 X-MTK: N Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP For regulators used by UFS, vcc, vccq and vccq2 will have voltage range initialized by ufshcd_populate_vreg(), however other regulators may not have voltage range settings if undefined in dt-bindings. In this case, both "min_uV" and "max_uV" fields in ufs_vreg struct will be zero values and used as new voltage range for voltage configuration in different power modes. Currently this may have no harm because if both "min_uV" and "max_uV" always keep "zero value", regulator_set_voltage() will always bypass such invalid values and return "good" results. However improper values shall be fixed to avoid future potential bug. Simply bypass voltage configuration if voltage range is not defined. Signed-off-by: Stanley Chu --- 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 8b9a01073d62..4e41fdfd0e53 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -7024,12 +7024,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; From patchwork Mon Mar 18 02:14:38 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 10856751 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9D284186D for ; Mon, 18 Mar 2019 02:14:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 83D5F2912F for ; Mon, 18 Mar 2019 02:14:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 77FF529165; Mon, 18 Mar 2019 02:14:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B05932912F for ; Mon, 18 Mar 2019 02:14:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727513AbfCRCOx (ORCPT ); Sun, 17 Mar 2019 22:14:53 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:31518 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726906AbfCRCOx (ORCPT ); Sun, 17 Mar 2019 22:14:53 -0400 X-UUID: 25046e49474d4cc7a7d578ed204d997d-20190318 X-UUID: 25046e49474d4cc7a7d578ed204d997d-20190318 Received: from mtkmrs01.mediatek.inc [(172.21.131.159)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1766971848; Mon, 18 Mar 2019 10:14:43 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 10:14:41 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 18 Mar 2019 10:14:42 +0800 From: Stanley Chu To: , , , , CC: , , , , , , Stanley Chu Subject: [PATCH v3 3/5] scsi: ufs: Fix regulator load and icc-level configuration Date: Mon, 18 Mar 2019 10:14:38 +0800 Message-ID: <1552875280-16196-5-git-send-email-stanley.chu@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> References: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> MIME-Version: 1.0 X-MTK: N Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently if a regulator has "-fixed-regulator" property in device tree, it will skip current limit configuration. This lead to a zero "max_uA" value in struct ufs_vreg. However, "regulator_set_load" operation shall be required on those regulators which specifically configured current limit, otherwise a zero max_uA value may cause unexpected behavior when this regulator is enabled or set as high power mode. Similarly, in icc_level configuration flow, icc_level shall be updated if specified regulator has also configured current limit, otherwise a zero max_uA will lead to wrong icc_level which may cause unexpected results after written to device. Signed-off-by: Stanley Chu --- 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 4e41fdfd0e53..9ae3256a705b 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -6279,19 +6279,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, @@ -6989,6 +6989,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", From patchwork Mon Mar 18 02:14:39 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 10856745 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A80E41823 for ; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8DAE329156 for ; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 80D2B2916A; Mon, 18 Mar 2019 02:14:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6798629171 for ; Mon, 18 Mar 2019 02:14:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727535AbfCRCOy (ORCPT ); Sun, 17 Mar 2019 22:14:54 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:60715 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727159AbfCRCOx (ORCPT ); Sun, 17 Mar 2019 22:14:53 -0400 X-UUID: a5730eb5e730458b9f146d2ee72ebe42-20190318 X-UUID: a5730eb5e730458b9f146d2ee72ebe42-20190318 Received: from mtkmrs01.mediatek.inc [(172.21.131.159)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 117445368; Mon, 18 Mar 2019 10:14:43 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 10:14:42 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 18 Mar 2019 10:14:42 +0800 From: Stanley Chu To: , , , , CC: , , , , , , Stanley Chu Subject: [PATCH v3 4/5] scsi: ufs: Change "-max-microamp" to non-mandatory property Date: Mon, 18 Mar 2019 10:14:39 +0800 Message-ID: <1552875280-16196-6-git-send-email-stanley.chu@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> References: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> MIME-Version: 1.0 X-TM-SNTS-SMTP: D744F9529ABB2417F6584E1606E039FFBABD64B8578243896E38D9706BD55A702000:8 X-MTK: N Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In dt-bindings for ufs, "-max-microamp" property indicates current limit and is mandatory if "-fixed-regulator" is not defined on a specified regulator. However, in some platforms, regulators without "-fixed-regulator" deifned may not need to define their current limit. They may only want to define voltage range for proper voltage switching in different power modes, especially for vcc, vccq or vccq2. However, missing "-max-microamp" property in device tree will lead to initialization fail, thus above limitation shall be resolved to tolerate such kind of regulators. After resolving this, these regulators without "-max-microamp" 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 --- 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 588079286e8a..2f244d388ca8 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")) { From patchwork Mon Mar 18 02:14:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 10856753 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 693101575 for ; Mon, 18 Mar 2019 02:14:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4E63A2912F for ; Mon, 18 Mar 2019 02:14:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 42ADC29165; Mon, 18 Mar 2019 02:14:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8FCE2912F for ; Mon, 18 Mar 2019 02:14:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727737AbfCRCO6 (ORCPT ); Sun, 17 Mar 2019 22:14:58 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:11327 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727571AbfCRCO6 (ORCPT ); Sun, 17 Mar 2019 22:14:58 -0400 X-UUID: 0d739476ab8b495a8959947ca4b5a35c-20190318 X-UUID: 0d739476ab8b495a8959947ca4b5a35c-20190318 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 885584143; Mon, 18 Mar 2019 10:14:43 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 10:14:42 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 18 Mar 2019 10:14:42 +0800 From: Stanley Chu To: , , , , CC: , , , , , , Stanley Chu Subject: [PATCH v3 5/5] scsi: ufs: Remove "-fixed-regulator" device tree property Date: Mon, 18 Mar 2019 10:14:40 +0800 Message-ID: <1552875280-16196-7-git-send-email-stanley.chu@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> References: <1552875280-16196-1-git-send-email-stanley.chu@mediatek.com> MIME-Version: 1.0 X-MTK: N Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP "-fixed-regulator" device tree property can be safely removed because below things are fixed or resolved, 1. "-max-microamp" becomes optional property: Undefined "-max-microamp" will not cause initialization fail if "-fixed-regulator" is not defined. 2. Current switching operation (by regulator_set_load) now has rules: Regulators will have undefined current limit if "-fixed-regulator" is not defined. But this is safe because only regulator which has configured current limit from "-max-microamp" property is allowed to change its load. Although "-fixed-regulator" is not used in any dt-bindings in tree, this patch is still safe for regulators already defined "-fixed-regulator", the reason is described as below. If a regulator defined "-fixed-regulator" before, the behavior after this patch is described as below, 1. "-max-microamp": If a regulator defined "-fixed-regulator", it is not necessary to define "-max-microamp" property in device tree and it is expected to have an undefined current limit, i.e., "max_uA" field is zero in struct ufs_vreg. This is exactly the same as patched. 2. "vcc-supply-1p8" or volatge range settings: * For vcc, vccq or vccq2, these three regulators shall not define "-fixed-regulator" because defining it will lead to undefined voltage range and thus voltage switching will be unexpected. * For other regulators with undefined voltage range, voltage range will be still undefined after patched. Therefore this patch is safe for all existed regulators with "-fixed-regulator" property already defined. Signed-off-by: Stanley Chu --- drivers/scsi/ufs/ufshcd-pltfrm.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index 2f244d388ca8..a667e7ba1c8b 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -151,11 +151,6 @@ static int ufshcd_populate_vreg(struct device *dev, const char *name, vreg->name = kstrdup(name, GFP_KERNEL); - /* if fixed regulator no need further initialization */ - snprintf(prop_name, MAX_PROP_SIZE, "%s-fixed-regulator", name); - if (of_property_read_bool(np, prop_name)) - goto out; - snprintf(prop_name, MAX_PROP_SIZE, "%s-max-microamp", name); if (of_property_read_u32(np, prop_name, &vreg->max_uA)) { dev_info(dev, "%s: unable to find %s\n", __func__, prop_name);