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]
Message-ID: <158475150943.125146.7023938982989289695@swboyd.mtv.corp.google.com>
Date:   Fri, 20 Mar 2020 17:45:09 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Wesley Cheng <wcheng@...eaurora.org>, agross@...nel.org,
        bjorn.andersson@...aro.org, mark.rutland@....com,
        mturquette@...libre.com, robh+dt@...nel.org
Cc:     linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] clk: qcom: gcc: Add USB3 PIPE clock and GDSC for SM8150

Quoting Wesley Cheng (2020-03-20 17:25:37)
> 
> 
> On 3/20/2020 4:34 PM, Stephen Boyd wrote:
> > Quoting Wesley Cheng (2020-03-17 13:53:31)
> >> diff --git a/include/dt-bindings/clock/qcom,gcc-sm8150.h b/include/dt-bindings/clock/qcom,gcc-sm8150.h
> >> index 90d60ef..3e1a918 100644
> >> --- a/include/dt-bindings/clock/qcom,gcc-sm8150.h
> >> +++ b/include/dt-bindings/clock/qcom,gcc-sm8150.h
> >> @@ -240,4 +240,8 @@
> >>  #define GCC_USB30_SEC_BCR                                      27
> >>  #define GCC_USB_PHY_CFG_AHB2PHY_BCR                            28
> >>  
> >> +/* GCC GDSCRs */
> >> +#define USB30_PRIM_GDSC                     4
> >> +#define USB30_SEC_GDSC                                         5
> > 
> > BTW, should we expect more GDSCs at 0,1,2,3 here? Why wasn't that done
> > initially?
> > 
> 
> Hi Stephen,
> 
> Yes, I assume there should be more GDSCs being introduced, and I have
> notified Taniya (our GCC POC) to upload the rest of the GDSC changes.  I
> decided to keep it with values 4 and 5 in order to be consistent with
> previous chipsets, but if you feel we should shuffle these values, then
> I am OK with that as well.
> 

If there are more GDSCs to come and fill the earlier numbers I'm OK to
wait. Consistency between different SoCs is not important.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ