[PATCH 1/3] power: supply: add battery driver for netronix ec

Andreas Kemnade andreas at kemnade.info
Sat Dec 27 13:38:15 PST 2025


On Sat, 27 Dec 2025 17:28:13 +0100
Josua Mayer <josua.mayer at jm0.eu> wrote:

> Implement a simple battery driver for monitoring voltage with the
> netronix embedded controller found in certain ebook readers.
> 
> Signed-off-by: Josua Mayer <josua.mayer at jm0.eu>

This also produces a value somehow depending on battery voltage
on the Tolino vision.
[...]
> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> index 08c68de0f01bc..d5059b8862aa8 100644
> --- a/drivers/mfd/ntxec.c
> +++ b/drivers/mfd/ntxec.c
> @@ -139,6 +139,7 @@ static const struct regmap_config regmap_config = {
> static const struct mfd_cell ntxec_subdev[] = {
> 	{ .name = "ntxec-rtc" },
> 	{ .name = "ntxec-pwm" },
> +	{ .name = "ntxec-battery" },
> };
> 
> static const struct mfd_cell ntxec_subdev_pwm[] = {

I think that should be a separate patch for mfd.

[...]
> +	switch (psp) {
> +		case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> +			ret = regmap_read(priv->ec->regmap, NTXEC_REG_READ_BATTERY, &value);
> +			if (ret < 0)
> +				return ret;
> +
> +			/* ec value to microvolt conversion:
> +			 * vendor kernel source suggests linear behaviour from 3V to 4.2V
> +			 * with readings 767 to 1023; each increment represents 4687,5uV.
> +			 * adjust 3V boundary slightly to report exactly 4.2V when full.
> +			 */
> +			val->intval = 2999872 + (value - 767) * 4688;
> +			break;
I find this code both in some kobo 2.6.35.3 code and on the tolino 3.0.35:

        const unsigned short battGasgauge[] = {
        //      3.0V, 3.1V, 3.2V, 3.3V, 3.4V, 3.5V, 3.6V, 3.7V, 3.8V, 3.9V, 4.0V, 4.1V, 4.2V,
//               743,  767,  791,  812,  835,  860,  885,  909,  935,  960,  985, 1010, 1023,
                 767,  791,  812,  833,  852,  877,  903,  928,  950,  979,  993, 1019, 1023,
        };

This does not look very linear... We have offsets
24
21
21
19
25
26
25
22
29
14
26
4

Do you have something looking more sane?
No idea what should produce such flaky offsets besides of
improper measurements. At least that should be commented.
And why do these tables exist at all?

Hmm, the more weird thing is that these voltages are translated linearly
inot capacity. So maybe they are just adjusted to have the capacity look
more sane. That would explain the 4 units step between 4.1V and 4.2V.
Having linear adc result -> voltage and nonlinear voltage-> capcity would
make more sense.

looking at such code snippet like this:
case POWER_SUPPLY_PROP_CAPACITY:
                if (POWER_SUPPLY_STATUS_NOT_CHARGING == g_ntx_bat_di->battery_status) {
                        val->intval = 100;
                        return 0;
                }
                value = ntx_up_battery_vol();
[...]
                                val->intval  = 100 - ((4100000 - value)/7000);


I am wondering whether we should just return capacity that way without
calculating voltage...

Regards,
Andreas



More information about the linux-arm-kernel mailing list