ср, 18 дек. 2024 г. в 14:34, Krzysztof Kozlowski <krzk@xxxxxxxxxx>: > > 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. 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? -- Best regards and thanks for review, Dzmitry
