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

Move max17042 common binding part to separate file, to
reuse it for MFDs with platform driver version.

Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>

Changes on v12:
- 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
---
 Documentation/devicetree/bindings/power/supply/maxim,max17042-common.yaml | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml        | 43 +++----------------------------------------
 MAINTAINERS                                                               |  2 +-
 3 files changed, 58 insertions(+), 41 deletions(-)

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@gmail.com>
> 
> 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

On Wed, Dec 18, 2024 at 02:25:31PM +0300, Dzmitry Sankouski wrote:
> ср, 18 дек. 2024 г. в 11:28, Krzysztof Kozlowski <krzk@kernel.org>:
> >
> > 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@gmail.com>
> > >
> > > 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

ср, 18 дек. 2024 г. в 14:34, Krzysztof Kozlowski <krzk@kernel.org>:
>
> On Wed, Dec 18, 2024 at 02:25:31PM +0300, Dzmitry Sankouski wrote:
> > ср, 18 дек. 2024 г. в 11:28, Krzysztof Kozlowski <krzk@kernel.org>:
> > >
> > > 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@gmail.com>
> > > >
> > > > 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.

I think I get it. There's no need for an MFD device node, because it's
just empty.
So in the device tree we'll only have a max17042 fuel gauge node. It'll get
matched with simple-mfd-i2c driver, which will create 2 sub devices -
fuel gauge and hwmon. Fuel gauge platform driver version will
get matched by platform id, and will take of_node from pdev dev parent
for setup.

Is that what you are thinking of?