linux-kernel - Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dc737abb-041b-491a-14f1-a584f9e64a3d@quicinc.com>
Date:   Fri, 22 Jul 2022 12:01:16 +0530
From:   "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@...cinc.com>
To:     Lee Jones <lee.jones@...aro.org>, Mark Brown <broonie@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_collinsd@...cinc.com>,
        <quic_subbaram@...cinc.com>, <quic_jprakash@...cinc.com>
Subject: Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API

Hi Lee,

> Okay, so I've taken some time to read through your previous
> submissions to see how we ended up down this rabbit hole.
>
> Essentially, it looks to me like the 2 I2C devices should be kept
> separate and the Regulator driver should be registered/probed without
> requiring this I2C dummy device hoop jumping exercise.
>
> As Stephen asked in v9 [0], why can't the regulator driver be I2C?
>
> Then it can manage its own resources and all of this craziness can be
> avoided.
>
> That's not to say that the v9 submission was the right way to go
> either.  Everything in relation to:
>
>    i2c_add_driver(&pm8008_regulators_driver);
>
> ... should be moved into the Regulator driver itself.


So, IIUC, we need to register the regulator driver as an i2c_driver and 
do all the regmap init stuff in its probe, and not touch the mfd 
driver(apart from adding reset-gpios).

Then the DT would be simply:

&pm8008_bus {
     pm8008: pm8008@8 {
         compatible = "qcom,pm8008";
         reg = <0x8>;
         #address-cells = <1>;
         #size-cells = <0>;
         #interrupt-cells = <2>;
     };

     pm8008_regulators: pm8008@9 {
         compatible = "qcom,pm8008-regulators";
         reg = <0x9>;
         #address-cells = <0>;
         #size-cells = <0>;

         pm8008_l1: ldo1@...0 {
             reg = <0x4000>;
             regulator-name = "pm8008_l1";
         };

         pm8008_l2: ldo2@...0 {
             reg = <0x4100>;
             regulator-name = "pm8008_l2";
         };

         pm8008_l3: ldo3@...0 {
             reg = <0x4200>;
             regulator-name = "pm8008_l3";
         };

         pm8008_l4: ldo4@...0 {
             reg = <0x4300>;
             regulator-name = "pm8008_l4";
         };

         pm8008_l5: ldo5@...0 {
             reg = <0x4400>;
             regulator-name = "pm8008_l5";
         };

         pm8008_l6: ldo6@...0 {
             reg = <0x4500>;
             regulator-name = "pm8008_l6";
         };

         pm8008_l7: ldo7@...0 {
             reg = <0x4600>;
             regulator-name = "pm8008_l7";
         };
     };
};


Stephen/Mark, Please do let me know if you are OK with this design.