Quoting Lee Jones (2022-09-29 11:01:41) > On Wed, 28 Sep 2022, Stephen Boyd wrote: > > > Quoting Lee Jones (2022-09-28 03:20:30) > > > Wouldn't it make more sense to simply separate the instantiation of > > > the 2 I2C devices? Similar to what you suggested [0] in v9. That way > > > they can handle their own resources and we can avoid all of the I2C > > > dummy / shared Regmap passing faff. > > > > > > [0] https://lore.kernel.org/all/CAE-0n53G-atsuwqcgNvi3nvWyiO3P=pSj5zDUMYj0ELVYJE54Q@xxxxxxxxxxxxxx/ > > > > > > > You can continue reading the thread[1]. My understanding is it's one > > chip that responds on two i2c addresses, thus we don't describe that as > > two i2c device nodes in DT. Instead we describe one node and use the > > dummy API to make the second i2c device. > > > > [1] https://lore.kernel.org/all/Yk3NkNK3e+fgj4eG@xxxxxxxxxxxxx/ > > As Mark says, it's probably 2 separate dies that have been encased in > the same IC and are otherwise unconnected. Not sure I understand the > comment about not requiring another 'struct device'. It will still > require that whether it's a platform device or an I2C device, right? > Yes a 'struct device' will be required for each i2c address no matter what happens. It is also useful to describe the hardware as one device node in case there is a shared reset signal or power supply. That allows us to have one driver probe the DT node and deassert the reset/power the chip on. I think this device has one reset signal, so we really need to do this and not treat them as completely independent i2c devices (the 0x8 and 0x9 addresses). Can we move forward with my plan to have another i2c device made for 'pm8008-regulators' and have that driver be an i2c driver that probes an i2c device manually created in the pm8008 driver? I think that would handle the reset ordering problem because the pm8008 driver can deassert the reset and also handle the regmap passing stuff by letting the i2c device at 0x9 make its own regmap.
