On 2/7/22 4:39 PM, Mark Brown wrote:
On Mon, Feb 07, 2022 at 04:08:01PM +0200, Vladimir Zapolskiy wrote:
On 2/4/22 9:32 PM, Mark Brown wrote:
Oh, good. I forsee no problems here. Probably this is something that
should be in the I2C core if it's going to be dynamically managed,
though just setting the supply as always on is probably more expedient.
vbus-supply property has been added recently to another I2C master controller,
see commit c021087c43c8 ("dt-binding: i2c: mt65xx: add vbus-supply property").
Note that some devices do have supplies that I/O is referenced against
and it's not clear that this isn't what's goin on here.
It serves right the same purpose, and its handling is going to be done in i2c
core, however since the latter is not yet completed, I would propose to add
the property to i2c-bus subnodes of QCOM CCI and its support in the driver,
later on both the property and its generic support would be better to see in
i2c core.
The bindings are ABI, it doesn't seem like a good idea to add new ABI as
a temporary bodge.
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,
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.
My assumption is that a decision should be generic for all similar cases,
Wolfram, could you share your point of view on the subject?
--
Best wishes,
Vladimir
