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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 9 Mar 2022 16:25:22 +0000
From:   "Sajida Bhanu (Temp) (QUIC)" <quic_c_sbhanu@...cinc.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        "Sajida Bhanu (Temp) (QUIC)" <quic_c_sbhanu@...cinc.com>
CC:     "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "stummala@...eaurora.org" <stummala@...eaurora.org>,
        "sayalil@...eaurora.org" <sayalil@...eaurora.org>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "rampraka@...eaurora.org" <rampraka@...eaurora.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>
Subject: RE: [PATCH V1] mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC

Hi,

Thanks for the review.

Please find the inline comments.

Thanks,
Sajida
> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@...aro.org>
> Sent: Wednesday, March 2, 2022 5:16 PM
> To: Sajida Bhanu (Temp) (QUIC) <quic_c_sbhanu@...cinc.com>
> Cc: adrian.hunter@...el.com; asutoshd@...eaurora.org;
> stummala@...eaurora.org; sayalil@...eaurora.org; cang@...eaurora.org;
> rampraka@...eaurora.org; linux-mmc@...r.kernel.org; linux-
> kernel@...r.kernel.org; linux-arm-msm@...r.kernel.org
> Subject: Re: [PATCH V1] mmc: sdhci-msm: Reset GCC_SDCC_BCR register for
> SDHC
> 
> On Tue, 1 Mar 2022 at 07:55, Shaik Sajida Bhanu
> <quic_c_sbhanu@...cinc.com> 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.
> >
> > [ 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
> >
> > Signed-off-by: Shaik Sajida Bhanu <quic_c_sbhanu@...cinc.com>
> 
> If this is this a regression, then please try to add a fixes tag too.
> 
Yes, we have buganizer for this, will add in next patchset.
> I assume we should tag this for stable kernels?
> 
> > ---
> >  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..f10b3c7 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;
> >         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,
> > +              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(&pdev->dev,
> "core_reset");
> > +       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;
> 
> Looks like we should use devm_reset_control_get_optional_exclusive()
> instead.
Sure I will incorporate the changes in next patch set.
> 
> > +       }
> > +       if (msm_host->core_reset) {
> > +               ret = reset_control_assert(msm_host->core_reset);
> > +               if (ret) {
> > +                       dev_err(&pdev->dev, "core_reset assert failed (%d)\n",
> > +                                               ret);
> > +                       goto out;
> > +               }
> > +               /*
> > +                * 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);
> 
> Isn't this supposed to be taken care of by the reset driver?
> 
> Or is this more an mmc controller specific thing? In that case, could this delay
> vary, depending on the variant of the controller?
Yes, it is specific to QCOM SDHC controller.
> 
> > +
> > +               ret = reset_control_deassert(msm_host->core_reset);
> > +               if (ret) {
> > +                       dev_err(&pdev->dev, "core_reset deassert failed (%d)\n",
> > +                                               ret);
> > +                       goto out;
> > +               }
> > +               usleep_range(200, 210);
> 
> Ditto?
Same as above
> 
> > +       }
> > +
> > +out:
> > +       return ret;
> > +}
> >
> >  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);
> > +               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)) {
> 
> Kind regards
> Uffe

Powered by blists - more mailing lists