Re: [PATCH v12 02/11] dt-bindings: power: supply: max17042: split on 2 files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 18, 2024 at 02:25:31PM +0300, Dzmitry Sankouski wrote:
> ср, 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.

OK, good point, assuming that this is the input not for example the
charge on battery. But even if the diagram is correct, we represent here
programming model exposed by device, not physical components of entire
PMIC. Therefore you could have more components there yet still it is
one device: fuel gauge with its I2C addres.


> 
> 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

There is no such thing as "MFD" device in terms of hardware. MFD is a
Linux construct.

> 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.

Which still makes it one device, unless you are capable of re-using this
other sensor-part on its own or in other devices.

Best regards,
Krzysztof






[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux