linux-kernel - Re: [PATCH v2 1/2] clk: qcom: gcc: Add USB3 PIPE clock and GDSC for SM8150

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <83787def-4ea5-d38d-d745-ea30a914a05f@codeaurora.org>
Date:   Fri, 20 Mar 2020 17:25:37 -0700
From:   Wesley Cheng <wcheng@...eaurora.org>
To:     Stephen Boyd <sboyd@...nel.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



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.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project