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: <4fdb2ab5-1dca-c44c-b647-3388a8ecea81@codeaurora.org> Date: Wed, 27 Dec 2017 15:50:52 +0530 From: Sricharan R <sricharan@...eaurora.org> To: Rob Herring <robh@...nel.org> Cc: Mark Rutland <mark.rutland@....com>, "Rafael J. Wysocki" <rjw@...ysocki.net>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, Viresh Kumar <viresh.kumar@...aro.org>, Michael Turquette <mturquette@...libre.com>, linux-pm@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>, Russell King <linux@...linux.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, David Brown <david.brown@...aro.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, Andy Gross <andy.gross@...aro.org>, "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>, linux-clk <linux-clk@...r.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs Hi Rob, On 12/26/2017 11:06 PM, Rob Herring wrote: > On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R <sricharan@...eaurora.org> wrote: >> Hi Rob, >> >> On 12/21/2017 2:48 AM, Rob Herring wrote: >>> On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote: >>>> Hi Viresh, >>>> >>>> On 12/20/2017 8:56 AM, Viresh Kumar wrote: >>>>> On 19-12-17, 21:25, Sricharan R wrote: >>>>>> + cpu@0 { >>>>>> + compatible = "qcom,krait"; >>>>>> + enable-method = "qcom,kpss-acc-v1"; >>>>>> + device_type = "cpu"; >>>>>> + reg = <0>; >>>>>> + qcom,acc = <&acc0>; >>>>>> + qcom,saw = <&saw0>; >>>>>> + clocks = <&kraitcc 0>; >>>>>> + clock-names = "cpu"; >>>>>> + cpu-supply = <&smb208_s2a>; >>>>>> + operating-points-v2 = <&cpu_opp_table>; >>>>>> + }; >>>>>> + >>>>>> + qcom,pvs { >>>>>> + qcom,pvs-format-a; >>>>>> + }; >>>>> >>>>> Not sure what Rob is going to say on that :) >>>>> >>>> >>>> Yes. Would be good to know the best way. >>> >>> Seems like this should be a property of an efuse node either implied by >>> the compatible or a separate property. What determines format A vs. B? >>> >> >> Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc. >> So this property (details like bitfields and register offsets that it represents) >> can be put soc specific and nvmem apis can be used to read >> the registers. Does something like below look ok ? >> >> qcom,pvs { >> compatible = "qcom,pvs-ipq8064"; >> nvmem-cells = <&pvs_efuse>; >> } > > Why do you need this node? It doesn't look like it corresponds to a > h/w block. It looks like you are just creating it to instantiate a > driver. > >> qfprom: qfprom@...000 { >> compatible = "qcom,qfprom"; > > Either this or... > >> reg = <0x00700000 0x1000>; >> #address-cells = <1>; >> #size-cells = <1>; >> ranges; >> pvs_efuse: pvs { > > a compatible here should be specific enough so the OS can know what > the bits are. Infact the above "qcom,pvs" node is required mainly to act as a consumer for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = <&pvs_efuse>) Then "qfprom" can be made to contain a "format_a" or "format_b" specific cell. So all that is needed is, nvmem-cells = <&pvs_efuse_phandle> needs to be available somewhere. The requirement is similar what is now done by "operating-points-v2-ti-cpu" and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the syscon register to read the efuse values. Similarly does defining a new "operating-points-v2-krait-cpu" which would contain the nvmem-cells property look ok ? This would avoid defining a new qcom,pvs node. cpu@0 { compatible = "qcom,krait"; enable-method = "qcom,kpss-acc-v1"; device_type = "cpu"; reg = <0>; qcom,acc = <&acc0>; qcom,saw = <&saw0>; clocks = <&kraitcc 0>; clock-names = "cpu"; cpu-supply = <&smb208_s2a>; operating-points-v2 = <&cpu_opp_table>; }; cpu_opp_table: opp_table { compatible = "operating-points-v2-krait-cpu"; nvmem-cells = <&pvs_efuse_format_a>; /* * Missing opp-shared property means CPUs switch DVFS states * independently. */ opp-1400000000 { opp-hz = /bits/ 64 <1400000000>; opp-microvolt-speed0-pvs0-v0 = <1250000>; opp-microvolt-speed0-pvs1-v0 = <1175000>; opp-microvolt-speed0-pvs2-v0 = <1125000>; opp-microvolt-speed0-pvs3-v0 = <1050000>; }; ... } qfprom: qfprom@...000 { compatible = "qcom,qfprom"; reg = <0x00700000 0x1000>; #address-cells = <1>; #size-cells = <1>; ranges; pvs_efuse_format_a: pvs { reg = <0xc0 0x8>; }; } Regards, Sricharan -- "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