On Tue, 8 Feb 2022 at 16:16, Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Mon, Feb 07, 2022 at 08:31:30PM +0200, Vladimir Zapolskiy wrote: > > On 2/7/22 4:39 PM, Mark Brown wrote: > > > > The bindings are ABI, it doesn't seem like a good idea to add new ABI as > > > a temporary bodge. It's not a temporary bodge. The i2c-core piece was reverted, but not the mediatek driver code/bindings. Vladimir has provided a replacement for the i2c-core code handling the vbus-regulator. When thee code will be back, the code from i2c-cci can be removed. The bindings will be the same. > > > The bindings are supposed to describe hardware, thus it's natural to extend > > them, I believe there is a trilemma in this particular case: > > 1) add optional vbus-supply property to all I2C master controllers or I2C > > busses in case of multiple I2C busses managed by a single controller, > > 2) add optional vbus-supply property to all I2C slave devices, > > If you add a named supply to all I2C controllers or devices then if any > of them have an actual vbus supply there will be a namespace collision. > > > 3) ignore peculiarities of particular (multiple in fact) PCB designs and > > a necessity of adding a regulator finely described as a pull-up for I2C > > bus lines. > > There's also the option of representing this as a separate thing on or > part of the bus. 4) (which you have implemented in your patch). Add support for the vbus-supplies property for the I2C CCI controllers. This is the option I'd vote for. -- With best wishes Dmitry
