On Tue, Nov 16, 2021 at 4:19 PM Vaittinen, Matti
[off-list ref] wrote:

[Me]

quoted

here I add a table to interpolate the temperature from an NTC
resistance to struct power_supply_battery_info.

Yep. Thanks for sharing this. I'd just hoped there was Kelvins used
instead of Celsius. Would also allow using negative temperatures as
errors in functions like the *resist2temp*().

It's not really an issue with these functions since they can't fail
and never return errors anyway.

It'd be a bit thick to start to using Kelvin somewhere in the kernel
when everyone and it's dog is using Celsius, including the
sysfs ABI to IIO. Also the datasheets I've seen are using Celsius
for operating conditions.

If we need an error code it is better to pass the temperature
out in a *pointer argument and add a proper return code.

quoted

Apart from this I want to add:
maintainance charging A and B so essentially two voltage+current
levels after CV charging has finished, each with a safety timer so
2 * 3 new properties to struct power_supply_battery_info.
But I haven't coded it yet.

Ok. This does not sound like a complete rework :) I'll keep on eye what
you cook up here ;)

Nah. I was thinking of breaking out all the CC/CV charging params
to its own struct, but it is better to do that when someone needs
it. I.e. the day someone wants to charge something else than
a Li-ion type battery, because e.g. a NiCd cell does not use CC/CV
charging IIUC.

I have two overlapping changes methinks. One is switch to fw_node - API
(not sure if it is useful), the other is not requiing the power_supply
to be registered prior parsing the battery info. That way the drivers
can truly use batinfo independently from (before registering to)
power-supply class.

Sounds harmless, just keep them coming.

Thanks :) I did re-spin the RFC - and already got reply from Rob's bots
:| It's odd how I _never_ get the bindings right...

Nobody does. ;)

Yours,
Linus Walleij