| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f88d2318-38fa-1db2-37c8-39693b321306@quicinc.com>
Date: Fri, 25 Mar 2022 12:52:23 +0530
From: "Sajida Bhanu (Temp)" <quic_c_sbhanu@...cinc.com>
To: "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>
CC: "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"agross@...nel.org" <agross@...nel.org>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"chris@...ntf.net" <chris@...ntf.net>,
"gdjakov@...sol.com" <gdjakov@...sol.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Asutosh Das (QUIC)" <quic_asutoshd@...cinc.com>,
"Ram Prakash Gupta (QUIC)" <quic_rampraka@...cinc.com>,
"Pradeep Pragallapati (QUIC)" <quic_pragalla@...cinc.com>,
"Sarthak Garg (QUIC)" <quic_sartgarg@...cinc.com>,
"Nitin Rawat (QUIC)" <quic_nitirawa@...cinc.com>,
"Sayali Lokhande (QUIC)" <quic_sayalil@...cinc.com>
Subject: Re: [PATCH V2] mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
On 3/15/2022 2:47 PM, Sajida Bhanu (Temp) (QUIC) wrote:
> Hi,
>
> Thanks for the review.
>
> Please find the inline comments.
>
> Thanks,
> Sajida
>> -----Original Message-----
>> From: Bjorn Andersson <bjorn.andersson@...aro.org>
>> Sent: Friday, March 11, 2022 5:10 AM
>> To: Sajida Bhanu (Temp) (QUIC) <quic_c_sbhanu@...cinc.com>
>> Cc: adrian.hunter@...el.com; agross@...nel.org; ulf.hansson@...aro.org;
>> p.zabel@...gutronix.de; chris@...ntf.net; gdjakov@...sol.com; linux-
>> mmc@...r.kernel.org; linux-arm-msm@...r.kernel.org; linux-
>> kernel@...r.kernel.org; Asutosh Das (QUIC) <quic_asutoshd@...cinc.com>;
>> Ram Prakash Gupta (QUIC) <quic_rampraka@...cinc.com>; Pradeep
>> Pragallapati (QUIC) <quic_pragalla@...cinc.com>; Sarthak Garg (QUIC)
>> <quic_sartgarg@...cinc.com>; Nitin Rawat (QUIC)
>> <quic_nitirawa@...cinc.com>; Sayali Lokhande (QUIC)
>> <quic_sayalil@...cinc.com>
>> Subject: Re: [PATCH V2] mmc: sdhci-msm: Reset GCC_SDCC_BCR register for
>> SDHC
>>
>> On Thu 10 Mar 07:40 PST 2022, Shaik Sajida Bhanu wrote:
>>
>>> Reset GCC_SDCC_BCR register before every fresh initilazation. This
>>> will reset whole SDHC-msm controller, clears the previous power
>>> control states and avoids, software reset timeout issues as below.
>>>
>> Nice, we've gotten reports about this from time to time.
>>
>>> [ 5.458061][ T262] mmc1: Reset 0x1 never completed.
>>> [ 5.462454][ T262] mmc1: sdhci: ============ SDHCI REGISTER DUMP
>>> =========== [ 5.469065][ T262] mmc1: sdhci: Sys addr: 0x00000000 |
>>> Version:
>>> 0x00007202
>>> [ 5.475688][ T262] mmc1: sdhci: Blk size: 0x00000000 | Blk cnt:
>>> 0x00000000
>>> [ 5.482315][ T262] mmc1: sdhci: Argument: 0x00000000 | Trn mode:
>>> 0x00000000
>>> [ 5.488927][ T262] mmc1: sdhci: Present: 0x01f800f0 | Host ctl:
>>> 0x00000000
>>> [ 5.495539][ T262] mmc1: sdhci: Power: 0x00000000 | Blk gap:
>>> 0x00000000 [ 5.502162][ T262] mmc1: sdhci: Wake-up: 0x00000000 |
>>> Clock: 0x00000003 [ 5.508768][ T262] mmc1: sdhci: Timeout: 0x00000000 |
>> Int stat:
>>> 0x00000000
>>> [ 5.515381][ T262] mmc1: sdhci: Int enab: 0x00000000 | Sig enab:
>>> 0x00000000
>>> [ 5.521996][ T262] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int:
>>> 0x00000000
>>> [ 5.528607][ T262] mmc1: sdhci: Caps: 0x362dc8b2 | Caps_1: 0x0000808f
>>> [ 5.535227][ T262] mmc1: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
>>> [ 5.541841][ T262] mmc1: sdhci: Resp[0]: 0x00000000 | Resp[1]:
>>> 0x00000000
>>> [ 5.548454][ T262] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]:
>>> 0x00000000
>>> [ 5.555079][ T262] mmc1: sdhci: Host ctl2: 0x00000000 [ 5.559651][
>>> T262] mmc1: sdhci_msm: ----------- VENDOR REGISTER
>>> DUMP-----------
>>> [ 5.566621][ T262] mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg:
>>> 0x6000642c |
>>> DLL cfg2: 0x0020a000
>>> [ 5.575465][ T262] mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl:
>>> 0x00010800 | DDR cfg: 0x80040873
>>> [ 5.584658][ T262] mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 :
>>> 0xf88218a8 Vndr func3: 0x02626040
>> Please ignore the line length "limit" and leave these unwrapped.
>>
> Sure
>>> Fixes: 0eb0d9f4de34 ("mmc: sdhci-msm: Initial support for Qualcomm
>>> chipsets")
>> This as well, and please drop the empty line between Fixes: and Signed-off-
>> by:.
>>
> Sure
>>> Signed-off-by: Shaik Sajida Bhanu <quic_c_sbhanu@...cinc.com>
>>> ---
>>>
>>> Changes since V1:
>>> - Added fixes tag as suggested by Ulf Hansson.
>>> - Replaced devm_reset_control_get() with
>>> devm_reset_control_get_optional_exclusive() as suggested by
>>> Ulf Hansson.
>>> ---
>>> drivers/mmc/host/sdhci-msm.c | 48
>>> ++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 48 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-msm.c
>>> b/drivers/mmc/host/sdhci-msm.c index 50c71e0..cb33c9a 100644
>>> --- a/drivers/mmc/host/sdhci-msm.c
>>> +++ b/drivers/mmc/host/sdhci-msm.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/regulator/consumer.h> #include
>>> <linux/interconnect.h> #include <linux/pinctrl/consumer.h>
>>> +#include <linux/reset.h>
>>>
>>> #include "sdhci-pltfm.h"
>>> #include "cqhci.h"
>>> @@ -284,6 +285,7 @@ struct sdhci_msm_host {
>>> bool uses_tassadar_dll;
>>> u32 dll_config;
>>> u32 ddr_config;
>>> + struct reset_control *core_reset;
>> As you only reset the controller once, during probe, this can be a local
>> variable in sdhci_msm_gcc_reset().
> Hi,
>
> In future if any requirement to reset gcc , for example if we want to reset gcc as a part of hardware reset then we can use this core_reset right.
>
> Thanks,
> Sajida
>>> bool vqmmc_enabled;
>>> };
>>>
>>> @@ -2482,6 +2484,45 @@ static inline void
>> sdhci_msm_get_of_property(struct platform_device *pdev,
>>> of_property_read_u32(node, "qcom,dll-config",
>>> &msm_host->dll_config); }
>>>
>>> +static int sdhci_msm_gcc_reset(struct platform_device *pdev,
>> You don't need pdev here, take a struct deivce * in and pass &pdev->dev.
> Ok
>>> + struct sdhci_host *host)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
>>> + int ret = 0;
>>> +
>>> + msm_host->core_reset =
>>> +devm_reset_control_get_optional_exclusive(&pdev->dev,
>> "core_reset");
>>
>> No need to hold onto that, so use the non-devm variant and free the reset at
>> the end of the function.
> Sorry didn't get this.
> Can you please point me any reference for this.
Hi,
Can you please help with comment on this.
Thanks,
Sajida
>>> + if (IS_ERR(msm_host->core_reset)) {
>>> + ret = PTR_ERR(msm_host->core_reset);
>>> + dev_err(&pdev->dev, "core_reset unavailable (%d)\n", ret);
>>> + msm_host->core_reset = NULL;
>> return dev_err_probe(&pdev->dev, PTR_ERR(msm_host->core_reset),
>> "unable to acquire core_reset\n");
>>
>>> + }
>>> + if (msm_host->core_reset) {
>> If you flip this around as:
>>
>> if (!msm_host->core_reset)
>> return 0;
>>
>> You don't need to zero-initialize ret, use goto and indent this block.
> Sure
>>> + ret = reset_control_assert(msm_host->core_reset);
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "core_reset assert failed
>> (%d)\n",
>>> + ret);
>>> + goto out;
>> return dev_err_probe();
>>
> Sure
>>> + }
>>> + /*
>>> + * The hardware requirement for delay between
>> assert/deassert
>>> + * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
>>> + * ~125us (4/32768). To be on the safe side add 200us delay.
>>> + */
>>> + usleep_range(200, 210);
>>> +
>>> + ret = reset_control_deassert(msm_host->core_reset);
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "core_reset deassert failed
>> (%d)\n",
>>> + ret);
>>> + goto out;
>> return dev_err_probe()
> Sure
>>> + }
>>> + usleep_range(200, 210);
>> The comment above says that we need to hold reset for 125us, is this delay
>> in here in error or should the comment above mention that this needs to be
>> done after deasserting the reset as well?
> Yes we need delay after deasserting the reset as well.
>>> + }
>>> +
>>> +out:
>>> + return ret;
>> With above, you can return 0 here.
>>
>>> +}
>>>
>>> static int sdhci_msm_probe(struct platform_device *pdev) { @@
>>> -2529,6 +2570,13 @@ static int sdhci_msm_probe(struct platform_device
>>> *pdev)
>>>
>>> msm_host->saved_tuning_phase = INVALID_TUNING_PHASE;
>>>
>>> + ret = sdhci_msm_gcc_reset(pdev, host);
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "core_reset assert/deassert failed
>> (%d)\n",
>>> + ret);
>> You just printed in sdhci_msm_gcc_reset(), no need to print again.
>>
>> Regards,
>> Bjorn
>>
> Okay Sure
>>> + goto pltfm_free;
>>> + }
>>> +
>>> /* Setup SDCC bus voter clock. */
>>> msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus");
>>> if (!IS_ERR(msm_host->bus_clk)) {
>>> --
>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>>> member of Code Aurora Forum, hosted by The Linux Foundation
>>>
Powered by blists - more mailing lists