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@4000 { reg = <0x4000>; regulator-name = "pm8008_l1"; }; pm8008_l2: ldo2@4100 { reg = <0x4100>; regulator-name = "pm8008_l2"; }; pm8008_l3: ldo3@4200 { reg = <0x4200>; regulator-name = "pm8008_l3"; }; pm8008_l4: ldo4@4300 { reg = <0x4300>; regulator-name = "pm8008_l4"; }; pm8008_l5: ldo5@4400 { reg = <0x4400>; regulator-name = "pm8008_l5"; }; pm8008_l6: ldo6@4500 { reg = <0x4500>; regulator-name = "pm8008_l6"; }; pm8008_l7: ldo7@4600 { reg = <0x4600>; regulator-name = "pm8008_l7"; }; }; }; Stephen/Mark, Please do let me know if you are OK with this design.