On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R [off-list ref] wrote:

Hi Rob,

On 12/21/2017 2:48 AM, Rob Herring wrote:

quoted

On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:

quoted

Hi Viresh,

On 12/20/2017 8:56 AM, Viresh Kumar wrote:

quoted

On 19-12-17, 21:25, Sricharan R wrote:

quoted

+  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@700000 {
        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.

        reg = <0xc0 0x8>;
        };
 };