ср, 18 дек. 2024 г. в 11:28, Krzysztof Kozlowski <krzk@xxxxxxxxxx>:
>
> On Tue, Dec 17, 2024 at 08:30:00PM +0300, Dzmitry Sankouski wrote:
> > Move max17042 common binding part to separate file, to
> > reuse it for MFDs with platform driver version.
> >
> > Signed-off-by: Dzmitry Sankouski <dsankouski@xxxxxxxxx>
> >
> > Changes on v12:
>
> Malformed patch.
>
> > - add addtionalProperties: true on common file
> > - rename *-base file to *-common
> > - remove compatibles from shared shema
> > - move required properties to final schema
> > - remove max77705 compatible from binding - it will be used in
> > mfd77705 binding
>
> Sorry, all this is somehow complicated effort of not calling the fuel
> gauge what it really is: separate device with its own I2C address, just
> like all previous designs in that family from Maxim.
>
> I keep repeating this and you keep going that way, maybe because it fits
> your drivers, but that's not the way.
>
> Best regards,
> Krzysztof
Fuel gauge ICs designed to sit between battery and charger, or even in the
battery pack itself, with a goal to track and protect the battery.
Given powering diagram:
---------- --------- ------------ --------------
|usb port|<--[input]--> |charger| <--> |fuel gauge| <--> |battery pack|
---------- --------- ------------ --------------
|
|
|---> [system bus]
There's no fuel gauge ICs with input and system bus measurements on the market.
This device indeed has its own I2C address, but that's not enough to
say it should be
a separate device, because we have MFD's with its goal to share
resources like a single
i2c address for devices with separate functions.
To me it's more like Maxim put its fuel gauge together with some hwmon
solution on the
single i2c client logic.
--
Best regards and thanks for review,
Dzmitry
